HK1188347B - Ad hoc file sharing - Google Patents

Description

AD HOC file sharing

Technical Field

The present invention relates generally to file sharing and browsing, and more particularly, to AD HOC based file sharing and browsing.

Background

File sharing is the use of distributing and/or providing access to files stored on a computer or other device. File sharing may be accomplished by a client computer accessing a file on a central server, establishing peer-to-peer file sharing between computers through a third party service, placing the file to be shared on removable media and moving the media between computers, and so forth. One particular use of file sharing is AD HOC based sharing of files, which are shared for a specific purpose or task. For example, it may be useful to set up temporary file sharing between participants in a conference.

However, although file sharing is useful between two computers, it may be difficult for general users to properly set up AD HOC file sharing on their computers. For example, AD HOC file sharing may require participating computers on the same Wi-Fi network, individuals may need to enable file sharing, set up file permissions, and so on. The more steps are required to set up AD HOC file sharing, the less likely it will be that a computer user will utilize this type of file sharing.

Disclosure of Invention

Methods and apparatus for devices to transfer files and perform file browsing using the AD HOC file sharing service are described. In an exemplary method, a first device transmits an announcement (advertisement) of an AD HOC file sharing service to each of one or more other devices. The announcements sent each include a user identity of a user associated with the first device. Further, access rights to the AD HOC file sharing service are granted on a per user basis. The first device may establish a connection with each of the plurality of other devices and may transfer a file with each of the plurality of other devices.

In another embodiment, the device sends an announcement of the AD HOC file sharing service to each of the plurality of other devices, wherein the announcement comprises a user identity of a user associated with the first device. Further, the device grants an access right to the AD HOC file sharing service to each of the plurality of other devices, wherein the access right to the AD HOC file sharing service is granted on a per user basis. In addition, access is enabled if a user corresponding to each of the plurality of other devices does not have a file sharing account on the first device.

In an embodiment, the AD HOC file sharing process may be initiated on the first device in response to a user selecting or opening a folder or icon designated or configured for AD HOC file sharing. The act of selecting or opening the folder or icon automatically initiates an AD HOC file sharing process, which may include sending an announcement of the AD HOC file sharing service to each of one or more other devices. The announcement may include a user identity of a user associated with the first device, or an equipment identity of the first device, or both the user identity and the equipment identity. Access rights on each device may be granted on a per user basis and access may be achieved without requiring the user of another device to set up a file share before receiving the announcement.

Other methods and apparatus are also described.

Drawings

The present invention is illustrated by way of example, and not by way of limitation, in the figures of the accompanying drawings and in which like reference numerals refer to similar elements.

Fig. 1 is a block diagram of one embodiment of a plurality of devices participating in AD HOC file sharing.

Fig. 2 is a flowchart of one embodiment of a process of performing AD HOC file sharing.

Fig. 3A is a flow diagram of one embodiment of a process for enabling and announcing an AD HOC file sharing service.

Fig. 3B is a flow diagram of one embodiment of a process for receiving an announcement from the AD HOC file sharing service.

Fig. 4A and 4B are a flowchart of one embodiment of a process for transferring a file using the AD HOC file sharing service.

Fig. 5A and 5B are a flowchart of one embodiment of a process for browsing files using the AD HOC file sharing service.

Fig. 6 is a block diagram showing a file sharing user interface for file sharing and browsing by the AD HOC file sharing service.

Fig. 7 is a block diagram of an AD HOC file sharing module that performs AD HOC file sharing.

Fig. 8A is a block diagram of an AD HOC file sharing enabling module that enables and announces an AD HOC file sharing service.

Fig. 8B is a block diagram of an announcement receiving module that receives an announcement for the AD HOC file sharing service.

Fig. 9A, 9B, and 9C are block diagrams of a file transfer module that transfers a file using the AD HOC file sharing service.

Fig. 10A, 10B, and 10C are block diagrams of a file browsing module that browses files using the AD HOC file sharing service.

FIG. 11 illustrates one example of a typical computer system that may be used in connection with the embodiments described herein.

FIG. 12 illustrates an example of a data processing system that may be used with an embodiment of the present invention.

Detailed Description

Methods and apparatus for devices to transfer files and perform file browsing using the AD HOC file sharing service are described. In the following description, numerous specific details are set forth to provide a thorough explanation of embodiments of the present invention. It will be apparent, however, to one skilled in the art that embodiments of the invention may be practiced without these specific details. In other instances, well-known components, structures and techniques have not been described in detail in order not to obscure an understanding of this description.

Reference in the specification to "one embodiment" or "an embodiment" means that a particular feature, structure, or characteristic described in connection with the embodiment can be included in at least one embodiment of the invention. The appearances of the phrase "in one embodiment" in various places in the specification are not necessarily all referring to the same embodiment.

In the following description and claims, the terms "coupled" and "connected," along with their derivatives, may be used. It should be understood that these terms are not intended as synonyms for each other. "coupled" is used to indicate that two or more elements that may or may not be in direct physical or electrical contact with each other co-operate or interact with each other. "connected" is used to indicate the establishment of communication between two or more elements coupled to each other.

The processes depicted in the figures are performed by processing logic that comprises hardware (e.g., circuitry, dedicated logic, etc.), software (such as is run on a general purpose computer system or a dedicated machine), or a combination of both. Although the processes are described below in terms of some sequential operations, it should be appreciated that some of the operations described may be performed in a different order. Also, some operations may be performed in parallel rather than sequentially.

The terms "server," "client," and "device" are intended to refer broadly to data processing systems, and not to refer specifically to a particular form factor of a server, client, and/or apparatus.

Methods and apparatus for devices to transfer files and perform file browsing using the AD HOC file sharing service are described. In an exemplary method, a device transmits an announcement of an AD HOC file sharing service to each of one or more other devices. The announcements sent each include a user identity of a user associated with the first device. Further, access rights to the AD HOC file sharing service are granted on a per user basis. The device establishes a connection with each of the other devices and performs file transfer with each of the plurality of other devices.

Fig. 1 is a block diagram of an embodiment of a plurality of devices participating in AD HOC file sharing. In FIG. 1, devices 102A-C are coupled via network connections 104A-C. In an embodiment, device 102A is coupled with device 102B via network connection 104A, and device 102B is coupled with device 102C via network connection 104B. Similarly, device 102C is coupled with device 102A via network connection 104C. Although in an embodiment, the three devices are shown coupled together via network connections, in alternative embodiments, more or fewer devices may be coupled together via network connections in a fully meshed point-to-point network topology and/or fewer network connections than a fully meshed network. For example, in one embodiment, the network connection ring may be used for a group of four or more devices.

In an embodiment, the device may be a personal computer, laptop computer, notebook computer, tablet computer, smart phone, cellular phone, gaming device, media player, etc., and/or any other type of device that may have a network connection and may store and/or transfer files. In an embodiment, the network connection may be any type of network connection that can couple two different devices: wireless connections (Wi-Fi, cellular, bluetooth, infrared, etc.), wired connections (ethernet, etc.), and/or combinations thereof. In an embodiment, each device 102A-C may use the AD HOC file sharing service to transfer files and/or browse files in the file system of other devices. In an embodiment, each device 102A-C stores files available to the other devices 102A-C via the AD HOC file sharing service in a special folder, which may alleviate the need for a user to manually set permissions or mount (mount) a special file system by which files are available for sharing and/or unavailable for sharing. In this case, the user may place a file (or an alias or shortcut of a file) in a special folder and automatically allow file sharing of the file by placing the file in the special folder. This special folder may be designated or configured to receive files that the user wants to share through the AD HOC file sharing embodiments described herein. The action of selecting or opening or associating or placing a file in the folder may automatically enable AD HOC file sharing for the file and any other files placed or associated with the folder. A file or an alias or shortcut to a file may be placed in or associated with the folder to enable AD HOC file sharing for the file. This special folder may be used to limit the scope of the shared files, since in an embodiment only those files that are placed into or associated with this special folder are made available for AD HOC file sharing.

In an embodiment, the AD HOC file sharing service is a point-to-point file sharing service that may be set up for specific tasks, projects, and/or other needs. In an embodiment the AD HOC file sharing service operates by sending announcements to other devices that may participate in the AD HOC file sharing service of the device. In this embodiment, the transmitted announcement indicates to the other devices that the AD HOC file sharing service is available in one of these devices. By having a peer-to-peer service, a first user of a first device may allow access to a second user of a second device without requiring the second user to have an account on the first device for a file sharing service, or without requiring a third party server and/or service hosted on a third device (e.g., peer-to-peer file sharing, etc.). Furthermore, in an embodiment, access rights to the AD HOC file sharing service are granted on a per user basis. Thus, in this embodiment, the AD HOC file sharing service allows users who do not have account-specific access rights to the AD HOC file sharing service, which may not be granted to other users. This is in contrast to different types of file sharing services that may have guest account access rights that grant file sharing access rights to any and all remote users. In addition, access to AD HOC file sharing can be achieved without using an authentication service that grants a remote device access right to the AD HOC file sharing service.

In an embodiment, the AD HOC file sharing service operates by one device sending an announcement to the other devices via a networked connection in which each of the devices 104A-C participates announcing the presence of the file sharing service on that device. For example, in one embodiment, the device 102A sends an announcement over its network connections 104A-C. In an embodiment, one or more devices 102A-C send an announcement of the AD HOC file sharing service over the network connection in which the device participates (e.g., broadcast over a corporate Local Area Network (LAN), home network LAN, etc. (e.g., broadcast announcement to all other devices on network connections 104A-C)). In another embodiment, the devices 102A-C only send the announcement to other devices in close proximity to the devices 102A-C. In this embodiment, the devices 102A-C will send an announcement to other devices in close proximity to the sending device. For example, in one embodiment, the device 102A sends an announcement to other devices 102B-C in close proximity as measured based on Wi-Fi of the devices 102A-C, Bluetooth and/or cellular signal strength, routing hop count, physical location (global positioning system location, cell phone location, etc.), and/or the like, and/or combinations thereof. For example, in one embodiment, the signal strength of a bluetooth signal may be used to limit the number of Wi-Fi discovered devices.

In an embodiment, the AD HOC file sharing service in devices 102A-C browses and transmits files through a file sharing connection. In one embodiment, a file sharing connection means that one device can browse the files of a remote device and transfer the files to and from the remote device without granting further access rights to the AD HOC file sharing service running on the one device. In this embodiment, this means that one or more files and/or directories in the file sharing repository are visible to the remote device through the AD HOC file sharing service. In an embodiment, when a remote device initially attempts to browse and/or transfer files to a device hosting the AD HOC file sharing service, the AD HOC file sharing service grants access rights to the remote device. Granting of access rights is further described below in fig. 4A and 5A.

In one embodiment, the AD HOC file sharing service in the devices 102A-C controlled by the AD HOC file server views the sharing service modules 106A-C. In this embodiment, the AD HOC file search sharing service modules 106A-C control the enablement of the file sharing service, invoke the relevant network services and connections (e.g., invoke Wi-Fi, bluetooth, etc.) that support the AD HOC file sharing service, and control the transmission and/or browsing of files accessible to the AD HOC file sharing service. The operation of the AD HOC file sharing service module is further described below in fig. 2.

In addition, each device 102A-C includes an AD HOC file repository 108A-C. In one embodiment, file repositories 108A-C for the AD HOC file sharing service are directories, separate file systems, removable storage, internal memory, etc., and/or any component of a device that may be used to store files. It should be noted that the present invention does not need to have a separate file system supporting the AD HOC file sharing service. In one embodiment, the AD HOC file sharing service specifies a folder titled conference room as a temporary storage of files to be used for the AD HOC file sharing service.

Fig. 2 is a flowchart of one embodiment of a process of performing AD HOC file sharing. In fig. 2, process 200 begins at block 202 with enabling the AD HOC file sharing service and announcing the presence of the service. In one embodiment, the process 200 enables the AD HOC file sharing service by invoking a process of controlling the AD HOC file sharing service. In this embodiment, the AD HOC file sharing service is enabled. For example, in an embodiment, a user of a device may start the AD HOC file sharing service and may use the service to send and/or receive files with another device, and may also browse the remote device and have the remote device browse the device. In this example, the user of the device may turn on and off the service as desired. For example, in one embodiment, if a user wants to share files with others in a meeting, the user may open a service. When the conference is ended, the user may disconnect the service, thereby prohibiting sharing of files through the AD HOC file sharing service. In another embodiment, the process 200 may enable the AD HOC file sharing service for a period of time (e.g., no more than one hour or some other period of time). In this embodiment, the process 200 will disconnect the AD HOC file sharing service when the time period expires. In another embodiment, the process 200 enables the AD HOC file sharing service. In one embodiment, process 200 enables the AD HOC file sharing service when the user clicks on an icon in the UI that represents the service. For example, in one embodiment, the AD HOC file sharing service may be enabled by clicking on a meeting room icon in a file browsing user interface as described below in fig. 6. Further, the process 200 announces the presence of the AD HOC file sharing service to other devices. The announcement of the AD HOC file sharing service being enabled is further described below in fig. 3A-B.

At block 204, the process 200 transmits files between the device running the process 200 and other remote devices. For example, in one embodiment, process 200 may transmit and receive files using a protocol such as the secure hypertext transfer protocol (HTTPS). In alternative embodiments, process 200 may use other file transfer protocols known in the art to transfer files (e.g., File Transfer Protocol (FTP), hypertext transfer protocol (HTTP), Server Message Block (SMB), Apple File Protocol (AFP), etc.). The transfer of files is further described below in FIGS. 4A-B.

At block 206, the process 200 browses files available for browsing between the device running the process 200 and other remote devices. For example, in one embodiment, the process 200 may request listing files and/or directories and receive a similar such request by using the HTTPS protocol. In alternative embodiments, process 200 may use other protocols known in the art to send and receive file browsing requests (e.g., FTP, HTTP, SMB, AFP, etc.). File browsing is further described below in fig. 5A-B.

Fig. 3A is a flow diagram of one embodiment of a process 300 for enabling and announcing an AD HOC file sharing service. In fig. 3A, process 300 begins with enabling the AD HOC file sharing service at block 302. In an embodiment, the process 300 initiates a process of controlling the AD HOC file sharing service. Once activated, the device running process 300 will be able to send, receive and fulfill file transfer and file browsing requests. In one embodiment, process 300 enables the AD HOC file sharing service. In one embodiment, process 300 enables the service by clicking on an icon in the user interface representing the service (e.g., a meeting room icon described below in FIG. 6).

If desired, at block 304, the process 300 invokes the relevant networking service. In one embodiment, the process 300 may leverage Wi-Fi, bluetooth, cellular data, infrared, wired networking (ethernet, etc.), and/or combinations thereof. Although in one embodiment, the process 300 invokes all possible networked services at block 304, in an alternative embodiment, the process 300 invokes one or some of the networked services (e.g., the process 300 invokes Wi-Fi or Wi-Fi and bluetooth). In this alternative embodiment, process 300 invokes which networking services are controlled by profiles and/or parameters. In another embodiment, the process 300 invokes the process 300 to detect an immediately adjacent networked service. For example, in one embodiment, the process 300 detects a Wi-Fi network from a LAN (e.g., announcing a Wi-Fi access point available to the LAN) and invokes a Wi-Fi networking service on the device so that the device can automatically connect with the LAN. Alternatively, the process 300 may detect another device announcing a potential peer-to-peer networking service (Wi-Fi peer-to-peer or AD HOC Wi-Fi, bluetooth, infrared, etc.) and invoke the relevant networking service so that the device may automatically connect with the other device to create a peer-to-peer networking connection. For example, in one embodiment, the process 300 detects another device announcing Wi-Fi service, and the process 300 invokes the Wi-Fi service on the device performing the process 300.

At block 304, the process 300 announces the presence of the AD HOC file sharing service. In one embodiment, the process 300 sends the announcement packet on the device's configured network connection. In one embodiment, the AD HOC file sharing service uses Bonjour service discovery protocol to announce the AD HOC file sharing service to other devices over available network connections. For example, in one embodiment, device 102A uses the Bonjour service discovery protocol to announce the AD HOC file sharing service to devices 102B-C using network connections 104A and 104C, respectively. Other types of announcements known in the art may be used to announce the presence of AD HOC file sharing services (unicast, broadcast, multicast announcements, etc.).

In one embodiment, the advertisement package (advertisement packet) includes an identification of the user associated with the AD HOC file sharing service being advertised. For example, in one embodiment, process 300 includes identification of a user (such as an email address, appleID, MobileMe ID, social network identification, a hash of such an identifier (e.g., Secure Hash Algorithm (SHA) -1 or other hash algorithms known in the art, etc.)), a number used as a key, a readable name (e.g., first name, last name, and/or combinations thereof, etc.), a Universally Unique Identifier (UUID) (e.g., a number used as a globally unique key), a certificate "fingerprint" (e.g., a hash of a number associated with an X509 certificate), a telephone number, and so forth. Further, the user identification can be a list of identifiers known to the user (e.g., multiple identifiers of the same and/or different types, etc.). In one embodiment, if a hash of an identification is used, the device receiving the announcement will use a similar hash for a set of known identifications (e.g., known email addresses, social network identifications, etc.) to match the identification data stored in the announcement. This embodiment allows an announcement to be sent without sending an email address or other identification in the clear. In another embodiment, a certificate "fingerprint" is a variation of a number used as a key, with additional semantics uniquely associated with the user's certificate, which may additionally be used to encrypt secure file transmissions.

Fig. 3B is a flow diagram of an embodiment of a process 350 of receiving an AD HOC file sharing service announcement. In fig. 3B, the process 350 begins with receiving an AD HOC file sharing service announcement at block 352. In one embodiment, the AD HOC file sharing announcement is an indication of the availability of an AD HOC file sharing service from the device sending the announcement. Furthermore, in one embodiment, the announcement package includes an identification of the user associated with the AD HOC file sharing service being announced, as described above.

At block 354, the process 350 determines whether the device sending the announcement is known to the device performing the process 350. In one embodiment, the process 350 maintains a list of devices known to have available AD HOC file sharing services. If the AD HOC file sharing service is unknown, the process 350 adds the device to a list of devices known to have available AD HOC file sharing services, at block 356. In one embodiment, the presence of a remote device with an available AD HOC file sharing service does not necessarily mean that a file sharing connection has been established. In this embodiment, the file sharing connection may be established by attempting to transmit and/or browse files using the AD HOC file sharing service of the remote device. The establishment of the file sharing connection is further described below in fig. 4A and 5A. Execution of the process 350 proceeds to block 358.

If the device sending the announcement is known to the apparatus performing the process 350, the process 350 updates the display of the availability of the AD HOC file sharing service at block 358. In one embodiment, the process 350 displays the availability of the remote AD HOC file sharing service in a UI as described below in fig. 6.

As described above, the AD HOC file sharing service is used to transfer files between different devices. Fig. 4A and 4B are flowcharts of an embodiment of a process of transferring a file using the AD HOC file sharing service. In particular, fig. 4A is a flow diagram of one embodiment of a process 400 for receiving a file using the AD HOC file sharing service. Fig. 4A begins with a process 400 that receives a request to receive a file from the AD HOC file system at block 402. In one embodiment, the process 400 receives an HTTPS request to send a file to a device that is performing the process 400. Alternatively, process 400 may receive another type of file transfer request (FTP, HTTP, etc.) known in the art. For example, in one embodiment, process 400 receives an HTTPS request that determines a file and an identification of a sending device that wishes to transfer the file. As described above, the identification may be an email address, a social network identification, an external service identification (e.g., a Twitter identification, an Apple ID, a MobileMe ID, or some other known service identification, etc.), and/or a hash of such an identification, and/or the like.

At block 404, the process 400 determines whether a file sharing connection exists with the device requesting to send the file. In an embodiment the file sharing connection is an established connection, wherein the user of the first device allows another user to access the AD HOC file sharing service. By establishing the file sharing connection between the two devices, the point-to-point nature of the file sharing is established. In this embodiment, once the initial user has given permission to access the AD HOC file sharing service of the first device to another user, the other user may view, retrieve and/or send the file to the first device. Although in one embodiment access rights to AD HOC file sharing are granted unidirectionally, in an alternative embodiment access rights may be automatically granted in the reverse direction once access rights are granted in one direction (e.g., once user a grants user B permission to retrieve and/or send files to user a's device, access rights to user B's device to retrieve and/or send files are granted to user a). In one embodiment, the process 400 looks at an identification associated with the AD HOC file sharing service to determine whether a file sharing connection is established with a device associated with the identification. The identification may be an email address, a social network identification, an external service identification (e.g., a Twitter identification, an Apple ID, a MobileMe ID, or some other known service identification, etc.), and so forth. Further, in one embodiment, the identification may be a hash of the above listed identifications (e.g., Secure Hash Algorithm (SHA) -1, etc.).

If process 400 has determined that a file sharing connection has not been established with the device requesting to send the file, at block 410, process 400 presents a request to receive the file to a user of the device performing process 400. In one embodiment, process 400 presents a User Interface (UI) dialog box to the user of the device performing process 400 indicating that another device wishes to send files via the AD HOC file sharing service. In addition, in this embodiment, a file sharing connection is established between the two devices by accepting a file transfer request. For example, in one embodiment, process 400 presents a UI user interface dialog indicating the name of the file and the user associated with the device that wishes to send the file to the receiving device.

At block 412, the process 400 determines whether the request was accepted or whether the request was not accepted. If the request is not accepted, at block 414, the process 400 denies the request. In one embodiment, process 400 sends a message, return code, or other type of indicator that the file transfer request has been denied to the device that wishes to send the file. If the request is accepted at block 412, the process 400 receives the file at block 406. Execution of process 400 proceeds to block 408, described below.

If, at block 404, process 400 determines that a file sharing connection is established with the device requesting to send the file, at block 406, process 400 receives the file. At block 408, the process 400 stores the file in a file repository for the AD HOC file sharing service. For example, in one embodiment, process 400 stores the received files in AD HOC file repository 108A-C as described above in FIG. 1.

Fig. 4B is a flow diagram of one embodiment of a process 450 for sending files using the AD HOC file sharing service. In fig. 4B, the process 450 begins by sending a request to send a file to another device via the AD HOC file sharing service at block 452. In one embodiment, process 450 sends the request using an HTTPS request that includes the name of the file and the identification of the user who wishes to send the file. In one embodiment, the identification may be an email address, a social network identification, an external service identification (e.g., a Twitter identification, an Apple ID, a MobileMe ID, or some other known service identification, etc.), and so forth. Further, in one embodiment, the identification may be a hash of the above listed identifications (e.g., Secure Hash Algorithm (SHA) -1, etc.).

At block 454, the process 450 determines whether the transmission has been accepted. For example, in one embodiment, the process 450 determines whether the transmission request is accepted based on a response (e.g., a return code, a response message, etc.) from the other device. If the request is not accepted, at block 458, the process 450 does not transfer the file. If the request is accepted at block 454, then at block 456, the process 450 transfers the file.

As described above, the AD HOC file sharing service allows a user to transmit files on a remote device that are visible via the AD HOC file sharing service and to browse those files. Fig. 5A and 5B are a flow diagram of one embodiment of a process 500 for browsing files using the AD HOC file sharing service. Fig. 5A is a flow diagram of one embodiment of a process 500 for allowing browsing of files using the AD HOC file sharing service. Fig. 5A begins at process 500 with receiving a file browsing request from an AD HOC file sharing service at block 502. In one embodiment, the process 500 receives an HTTPS request to view a file for the device that is performing the process 500. Alternatively, process 500 may receive another type of request (FTP, HTTP, etc.). For example, in one embodiment, the process 500 receives an HTTPS request that includes an identification of the directory of the file to be browsed, optionally any filters that should be applied to the list of files, and/or an identification of the sending device that wishes to browse the file. As described above, the identification may be an email address, a social network identification, an external service identification (e.g., a Twitter identification, an Apple ID, a MobileMe ID, or some other known service identification, etc.), and/or a hash of such an identification, and/or the like. In one embodiment, the file filter included in the file browse request is a filter that limits the results of the returned files and/or directories to a list of files and/or directories that match the filter. For example, in one embodiment, the filter may be a filter that limits the list of files and/or directories to a list of files and/or directories that match the filter ". exe". Alternatively, there may be no file filter in the browse file request.

At block 504, the process 500 determines whether a file sharing connection exists with the device requesting to view the file. As described above, when the user of the first device allows another user of another device to send or browse files, a file sharing connection for the first device is established. By establishing the file sharing connection between the two devices, the point-to-point nature of the file sharing is established. In this embodiment, once the initial user has given permission to access the AD HOC file sharing service of the first device to another user, the other user may view, retrieve and/or send files to the first device. In one embodiment, the process 500 looks up the identity associated with the AD HOC file sharing service as described above in block 404 of fig. 4A.

If process 500 determines that a file sharing connection has not been established with the device requesting to send the file, at block 510, process 500 presents a request to receive a file browsing request to a user of the device performing process 500. In one embodiment, the process 500 presents a User Interface (UI) dialog box to a user of the device performing the process 500 indicating that another device wishes to browse the user's AD HOC file sharing repository via the AD HOC file sharing service. In addition, in this embodiment, a file sharing connection is established between the two devices by accepting a file browsing request. For example, in one embodiment, process 500 presents a UI user interface dialog indicating a user associated with a device that wishes to browse the file-shared repository of the receiving device.

At block 512, the process 500 determines whether the request was accepted or whether the request was not accepted. If the request is not accepted, at block 514, the process 500 rejects the request. In one embodiment, process 500 sends a message, return code, or other type of indicator that the file browsing request has been denied to a device that wishes to browse the file sharing repository. If the request is accepted at block 512, then at block 506, the process 500 fulfills the file browsing request. In one embodiment, the process 500 fulfills the file browse request by compiling a list of files and/or directories that meet the criteria in the file filter (if any) present in the file browse request and sending the list to the device that originally issued the file browse request.

If, at block 504, the process 500 determines that a file sharing connection is established with the device requesting to send the file, at block 506, the process 500 fulfills the file browsing request as described above.

Fig. 5B is a flow diagram of one embodiment of a process 550 for sending a file browse request using the AD HOC file sharing service. In fig. 5B, the process 550 begins at block 552 with sending a file browsing request to another device via the AD HOC file sharing service. In one embodiment, the process sends the request using an HTTPS request that includes the name of the file, the identification of the user who wishes to send the file, and an optional file filter. In one embodiment, the identification may be an email address, a social network identification, an external service identification (e.g., a Twitter identification, an Apple ID, a MobileMe ID, or some other known service identification, etc.), and so forth. Further, in one embodiment, the identification may be a hash of the above listed identifications (e.g., Secure Hash Algorithm (SHA) -1, etc.).

At block 554, the process 550 determines whether file browsing has been accepted. For example, in one embodiment, the process 550 determines whether the file browsing request is accepted based on a response (e.g., return code, response message, etc.) from the other device. If the request is not accepted, at block 560, the process 500 signals a failure (e.g., presents a user interface dialog box, etc.). If the request is accepted at block 554, then the process 500 accepts the results of the file browsing request as described with reference to FIG. 5A at block 556.

At block 558, process 500 presents the results of the file system browse. In one embodiment, process 500 updates the UI showing the contents of the AD HOC file sharing repository of another device. For example, in one embodiment, the process 550 updates a file display portion of a UI as described below in fig. 6.

Fig. 6 is a block diagram of a file sharing UI600 illustrating file sharing and browsing using the AD HOC file sharing service. In fig. 6, file sharing UI600 includes three separate portions of the UI that display different entities, namely, user configurable display 602, file display 604, and conference room display 606. User configurable portion 602 includes various UI icons representing device 608A, share 608B, place 608C, and meeting room 608D. In one embodiment, the one or more icons for device 608A may include a UI icon for a list of one or more devices (e.g., hard disk, removable storage, printer, etc., and/or other attachable devices known in the art) attached to the device displaying the UI. Further, in one embodiment, the shared display 608B may include one or more icons representing different shared devices of the device used to display the UI (e.g., other computers, network attached peripherals, and/or the like, and/or other network-enabled devices known in the art). In one embodiment, local display 608C represents a directory that is commonly used by a user of the device displaying the UI (e.g., a desktop, application, document, movie, photo, music, picture, etc., and/or other user-configurable directory).

In one embodiment, meeting room 608D is a group of one or more icons representing AD HOC file sharing services for devices that are presenting UI 600. In one embodiment, when one of the icons in meeting room 608D is clicked, the files and/or directories in the AD HOC file sharing repository are listed in file display 604. The files and/or directories may be listed in any manner known in the art, such as alphabetically, by date, by size, represented by different icons, filtered to display some of the files and/or directories, etc., and/or combinations thereof.

Further, in FIG. 6, the meeting room display 606 includes different meeting rooms 612A-C that are available to the device that is presenting the UI display 600. In one embodiment, each conference room 612A-C represents an AD HOC file sharing service on one or more devices. In one embodiment, there may be multiple concurrent AD HOC file sharing services on one device. For example, in one embodiment, there may be two graphical user sessions (e.g., by using a quick user switch available to the device), for example, and each user may be in a conference room in each session. In this case, one user may use the console at a time, so only one person may interact with the other user and accept/reject/send the file. Another embodiment with multiple users may use screen sharing through a virtual screen. In this embodiment, there may be two concurrent instances of the conference room on the device.

For example, in one embodiment, the local conference room 612 is an icon representing the AD HOC file sharing service on the device that is presenting the UI 600. Further, in this example, remote conference rooms 612B-C are icons representing AD HOC file sharing services on remote devices coupled to the device presenting UI 600. For example, in one embodiment, if device 102A is presenting UI600, local conference room 612A represents the AD HOC file sharing service on device 102A, and remote conference rooms 612B-C represent the AD HOC file sharing service on devices 612B-C, respectively.

In one embodiment, the user may add files and/or directories to the AD HOC file sharing service by dragging and dropping the files onto the file display 604 and/or icons for the local conference room 612A. Furthermore, in one embodiment, one or more files and/or directories may be transferred to the remote AD HOC file system by dragging and dropping the one or more files and/or directories onto a desired remote meeting room icon (e.g., meeting room 612B-C). In one embodiment, to browse the files in the remote AD HOC file sharing repository, the user may click on an icon (e.g., conference room 612B or 612C) representing the remote AD HOC file sharing service of interest. In this embodiment, by clicking on meeting room 612B or 612C, a list of files and/or directories in the corresponding AD HOC file repository 108B or 108C is displayed in file display 604. For example, in one embodiment, by clicking on meeting room 612B corresponding to device 102B, a list of files and/or directories in the AD HOC file repository is displayed. Although in one embodiment all files and/or directories in the AD HOC file sharing repository are listed, in an alternative embodiment some of these files and/or directories are listed (e.g., filtered using file filters known in the art, displayed organized by directory, categorized in various ways known in the art, etc.).

In one embodiment, a user of the device may cause one or more files and/or directories to arrive at the local device from the remote device by dragging and dropping the desired files from the remote AD HOC file sharing service to the local device. For example, in one embodiment, a user may drag and drop one or more files from the file display 604 that is displaying remotely available files on the AD HOC file sharing service of a remote device and drop these selected files onto the desktop of the user's local device. This has the effect of transferring these selected files from the AD HOC file sharing repository of the remote device to the desktop of the user device.

Fig. 7 is a block diagram of the AD HOC file sharing module 106 that performs AD HOC file sharing. In one embodiment, AD HOC file sharing modules 106A-C use AD HOC file sharing module 106. In fig. 7, the AD HOC file sharing module 106 includes an AD HOC file sharing service enabling module 702, a file sharing module 704, and a file browsing module 706. In one embodiment, the AD HOC file sharing service enabling module 702 enables the AD HOC file sharing service as described above in block 202 of fig. 2. The file sharing module 704 uses the AD HOC file sharing service to transfer files as described above in block 204 of fig. 2. The file browsing module 706 uses the AD HOC file sharing service to browse files and/or directories as described above in block 202 of fig. 2.

Fig. 8A is a block diagram of an AD HOC file sharing enabling module 702 that enables and announces an AD HOC file sharing service. In fig. 8A, AD HOC file sharing enabling module 702 includes an AD HOC file sharing service enabling module 802, a networking channel module 804, an announcement module 806, and a file repository enabling module 808. The AD HOC file sharing service enabling module 802 enables the AD HOC file sharing service as described above in block 302 of fig. 3A. The networking channel module 804 invokes the networking channel as needed as described above in fig. 3A block 304. The announcement module 806 announces the availability of the AD HOC file sharing service as described above in block 306 of fig. 3A. File repository enablement module 808 enables the AD HOC file sharing repository as described above in block 302 of fig. 3A.

Fig. 8B is a block diagram of the announcement receiving module 850 receiving an announcement about the AD HOC file sharing service. In fig. 8B, the announcement receiving module 850 includes an announcement receiving module 852, a device adding module 854, and an update display 856. The announcement receiving module 852 receives the AD HOC file sharing announcement as described above in fig. 3B block 352. The device addition module 854 adds a device to the list of known available AD HOC file sharing services as described above in fig. 3B block 354. Update display 856 updates the display of the availability of the AD HOC file sharing service as described above in fig. 3B block 358.

Fig. 9A, 9B, and 9C are block diagrams of a file transfer module that transfers a file using the AD HOC file sharing service. Fig. 9A is a block diagram of the file transfer module 704 that transfers a file. In fig. 9A, the file transfer module 704 includes a file receiving module 902 and a file transfer module 904. The file receiving module 902 receives a file as described above in fig. 5A. The file transfer module 904 transfers files as described above in FIG. 5B.

Fig. 9B is a block diagram of the file receiving module 902 that receives a file. In FIG. 9B, the file receiving module 902 includes a file receiving request module 910, a file sharing connection establishing module 912, a file receiving module 914, a file storing module 916, a presentation request module 918, and an error module 920. The receive file request module 910 receives a file transfer request as described above in block 402 of figure 4A. The file share connection establishment module 912 establishes a file share connection as described above in figure 4A block 416. The file receiving module 914 receives the file as described above in block 406 of fig. 4A. The store files module 916 stores the files in the AD HOC file repository as described above in fig. 4A at block 408. The render request module 918 renders the request to receive the file as described above in block 410 of FIG. 4A. The error module 920 denies the file transfer request as described above in fig. 4A, block 414.

Fig. 9C is a block diagram of the file transfer module 904 that sends a file. In FIG. 9B, the file transfer module 902 includes a transfer file request module 930, a file transfer module 932, and an error module 934. The transmit file request module 930 transmits the file transmission request as described above in block 452 of fig. 4A. The file transfer module 932 sends the file as described above in fig. 4A, block 456. The error module 934 denies the file transfer request as described above in FIG. 4A at block 468.

Fig. 10A, 10B, and 10C are block diagrams of a file browsing module that browses files using the AD HOC file sharing service. Fig. 10A is a block diagram of the file browsing module 706 that browses files using the AD HOC file sharing service. In FIG. 10A, the file browsing module 706 includes a received file browsing module 1002 and a get file browsing module 1004. The receive file view module 1002 responds to the remote view request as described above in fig. 5A. The get files view module 1004 views the remote computer as described above in FIG. 5B.

Fig. 10B is a block diagram of the received file browsing module 1002 that responds to a remote browsing request using the AD HOC file sharing service. In FIG. 10B, the receive file browse module 1002 includes a receive file browse request module 1010, a file share connection establishment module 1012, a fulfill file browse module 1014, a render file browse module 1016, and a reject request 1018. The receive file browse request module 1010 receives a file browse request as described above in block 502 of fig. 5A. The file share connection establishment module 1012 establishes the file share connection as described above in figure 5A, block 508. Fulfillment file browsing module 1014 fulfills file sharing browsed file repositories as described above in fig. 5A, block 506. The render file view module 1016 renders the file view request as described above in block 510 of fig. 5A. The rejection request 1018 rejects the file browsing request as described above in block 514 of figure 5A.

Fig. 10C is a block diagram of the get files browse module 1004 that browses a remote computer using the AD HOC file sharing service. In fig. 10C, the get file view module 1004 includes a send file view request module 1030, a receive view result module 1032, a present file view module 1034, and an error module 1036. The send file view request module 1030 sends a file view request as described above in block 552 of figure 5B. The receive browse results module 1032 sends the file browse request as described above in block 556 of fig. 5B. The render file view module 1034 renders the file view results as described above in block 558 of fig. 5B. The error module 1036 denies the file browse request as described above in block 560 of fig. 5A.

FIG. 11 shows one example of a data processing system 1100 that may be used with an embodiment of the invention. For example, system 1100 may be implemented to include a host as described in FIG. 1. It should be noted that while FIG. 11 illustrates various components of a computer system, it is not intended to represent any particular architecture or manner of interconnecting the components as such details are not germane to the present invention. It will also be appreciated that network computers and other data processing systems or other consumer electronic devices which have fewer components or perhaps more components may also be used with the present invention.

As shown in fig. 11, a computer system 1100 in the form of a data processing system includes a bus 1103, the bus 1103 coupled with one or more microprocessors 1105 and a ROM (read only memory) 1107, a volatile RAM1109, and a non-volatile memory 1111. The microprocessor 1105 may retrieve instructions from the memories 1107, 1109, 1111 and execute the instructions to perform the operations described above. The bus 1103 interconnects these various components together and also interconnects these components 1105, 1107, 1109, and 1111 to a display controller and display device 1113 and to peripheral devices such as input/output (I/O) devices which may be mice, keyboards, modems, network interfaces, printers, and other devices which are well known in the art. Typically, the input/output devices 1115 are coupled to the system through input/output controllers 1117. Volatile RAM (random access memory) 1109 is typically implemented as dynamic RAM (dram), which continuously requires power in order to refresh or maintain the data in the memory.

The mass storage 1111 is typically a magnetic hard drive, or a magnetic optical drive, or an optical drive, or a DVD RAM, or a flash memory, or other type of memory system that retains data (e.g., a large amount of data) even after power is removed from the system. Typically, the mass storage 1111 will also be a random access memory, but this is not necessary. Although FIG. 11 shows that the mass storage 1111 is a local device coupled directly to the rest of the components in the data processing system, it will be appreciated that the present invention may utilize a non-volatile memory which is remote from the system, such as a network storage device which is coupled to the data processing system through a network interface such as a modem, Ethernet interface or wireless network. The bus 1103 may include one or more buses connected to each other through various bridges, controllers and/or adapters as is well known in the art.

FIG. 12 shows an example of another data processing system 1200 that may be used with an embodiment of the invention. For example, system 1200 may be implemented as a portable storage device as shown in FIG. 1. The data processing system 1200 shown in fig. 12 includes a processing system 1211, which may be one or more microprocessors, or may be a system on a chip integrated circuit, and which further includes a memory 1201 for storing data and programs for execution by the processing system. The system 1200 also includes an audio input/output subsystem 1205, and the audio input/output subsystem 1205 may include a microphone and a speaker for, for example, playing music or providing telephony functions through the speaker and microphone.

The display controller and display device 1209 provides a virtual user interface for the user; the digital interface may comprise a graphical user interface similar to that displayed when a Macintosh computer runs OS X operating system software or when an Apple iPhone runs an iOS operating system, or the like. The system 1200 also includes one or more wireless transceivers 1203 that communicate with another data processing system, such as the system 1200 of fig. 12. The wireless transceiver may be a WLAN transceiver, an infrared transceiver, a bluetooth transceiver, and/or a wireless cellular telephone transceiver. It will be appreciated that additional components not shown may also be part of system 1200 in some embodiments, and that in some embodiments fewer components than shown in FIG. 12 may also be used in a data processing system. The system 1200 also includes one or more communication ports 1217 for communicating with another data processing system, such as the system 1500 of figure 15. The communication port may be a USB port, firewire port, bluetooth interface, or the like.

The data processing system 1200 also includes one or more input devices 1213 provided to allow a user to provide system input. These input devices may be a keypad, or a keyboard, or a touch panel, or a multi-touch panel. The data processing system 1200 also includes an optional input/output device 1215, which may be a connector for a docking station. It will be appreciated that one or more buses, not shown, may be used to interconnect the various components as is known in the art. The data processing system shown in FIG. 12 may be a handheld computer or Personal Digital Assistant (PDA), or a cellular telephone with PDA-like functionality, or a handheld computer that includes a cellular telephone, or a media player (e.g., an iPod), or a device that combines aspects or functionality of these devices (e.g., a media player combined in one device with a PDA and a cellular telephone, or an embedded device, or other consumer electronic device). In other embodiments, the data processing system 1200 may be a network computer or an embedded processing device within another device, or other types of data processing systems having fewer components than shown in FIG. 12, or possibly more components.

At least some embodiments of the invention may be part of a digital media player, such as a portable music and/or video media player, which may include a media processing system to present media, a storage device to store media, and may also include a Radio Frequency (RF) transceiver (e.g., an RF transceiver for a cellular telephone) coupled with an antenna system and the media processing system. In some embodiments, media stored on a remote storage device may be transmitted to the media player through the RF transceiver. The media may be, for example, one or more of music or other audio, still pictures, or moving pictures.

The portable media player may include a media selection device, such as that of Apple, Inc. of Cupertino, CAOr iPodA touch wheel input device, a touch screen input device, a button device, a movable pointing input device, or other input device on the media player. The media selection device may be used to select media stored on the storage device and/or the remote storage device. The portable media player, in at least some embodiments, can include a display device coupled with the media processing system to display titles or other indicators of media selected through the input device and presented through a speaker or headphones, or presented on the display device, or both the display device and the speaker or headphones. Examples of portable media players are described in published U.S. patent No. 7,345,671 and U.S. published patent No. 2004/0224638, both of which are incorporated herein by reference.

Portions of the above description may be implemented with logic circuitry (e.g., dedicated logic circuitry) or may be implemented with a microcontroller or other form of processing core that executes program code instructions. Thus, the processes taught by the discussion above may be performed with program code (e.g., machine-executable instructions) that cause a machine that executes these instructions to perform certain functions. In this context, a "machine" may be a machine that converts instructions in an intermediate form (or "abstract") into processor-specific instructions (e.g., an abstract execution environment, such as a "virtual machine" (e.g., a Java virtual machine), an interpreter, a common language runtime, a high-level language virtual machine, etc.) and/or electronic circuitry (e.g., "logic circuitry" implemented with transistors) disposed on a semiconductor chip that is designated to execute the instructions (e.g., a general-purpose processor and/or a special-purpose processor). The processes taught by the discussion above (in the alternative to a machine or in the alternative to being combined with a machine) may also be performed by electronic circuitry designed to perform the processes (or a portion thereof) without the execution of program code.

The present invention also relates to an apparatus for performing the operations described herein. This apparatus may be specially constructed for the required purposes, or it may comprise a general-purpose computer selectively activated or reconfigured by a computer program stored in the computer. Such a computer program may be stored in a computer readable storage medium, such as, but is not limited to, any type of disk including floppy disks, optical disks, CD-ROMs, and magnetic-optical disks, read-only memories (ROMs), RAMs, EPROMs, EEPROMs, magnetic or optical cards, or any type of media suitable for storing electronic instructions, and each coupled to a computer system bus.

A machine-readable medium includes any mechanism for storing or transmitting information in a form readable by a machine (e.g., a computer). For example, a machine-readable medium includes read only memory ("ROM"); random access memory ("RAM"); a magnetic disk storage medium; an optical storage medium; a flash memory device; and so on.

An article of manufacture may be used to store program code. An article of manufacture that stores program code may be embodied as, but is not limited to, one or more memories (e.g., one or more flash memories, random access memories (static, dynamic or other)), optical disks, CD-ROMs, DVD ROMs, EPROMs, EEPROMs, magnetic or optical cards, or other type of machine-readable media suitable for storing electronic instructions. Program code may also be downloaded from a remote computer (e.g., a server) to a requesting computer (e.g., a client) by way of data signals embodied in a propagation medium (e.g., via a communication link (e.g., a network connection)).

The foregoing detailed description has presented algorithms and symbolic representations of operations on data bits within a computer memory. These algorithmic descriptions and representations are the means used by those skilled in the data processing arts to most effectively convey the substance of their work to others skilled in the art. An algorithm is here, and generally, conceived to be a self-consistent sequence of operations leading to a desired result. The operations are those requiring physical manipulations of physical quantities. Usually, though not necessarily, these quantities take the form of electrical or magnetic signals capable of being stored, transferred, combined, compared, and otherwise manipulated. It has proven convenient at times, principally for reasons of common usage, to refer to these signals as bits, values, elements, symbols, characters, terms, numbers, or the like.

It should be borne in mind, however, that all of these and similar terms are to be associated with the appropriate physical quantities and are merely convenient labels applied to these quantities. Unless specifically stated otherwise as apparent from the above discussion, it is appreciated that throughout the description, discussions utilizing terms such as "computing," "selecting," "presenting," "determining," "associating," "sending," "storing," "receiving," "establishing," "transmitting," or the like, refer to the action and processes of a computer system, or similar electronic computing device, that manipulates and transforms data represented as physical (electronic) quantities within the computer system's registers and memories into other data similarly represented as physical quantities within the computer system memories or registers or other such information storage, transmission or display devices.

The processes and displays presented herein are not inherently related to any particular computer or other apparatus. Various general-purpose systems may be used with programs in accordance with the teachings herein, or it may prove convenient to construct a more specialized apparatus to perform the operations described. The required structure for a variety of these systems will appear from the description below. In addition, the present invention is not described with reference to any particular programming language. It will be appreciated that a variety of programming languages may be used to implement the teachings of the invention as described herein.

The foregoing discussion merely describes some exemplary embodiments of the present invention. One skilled in the art will readily recognize from such discussion, the accompanying drawings and the claims that various modifications can be made without departing from the spirit and scope of the invention.

Claims (21)

1. A data processing system comprising:

means for placing one or more files in one or more special purpose folders associated with an AD HOC file sharing service on a first device, wherein the ADHOC file sharing service is configured to automatically make files placed in the special purpose folders available for sharing using the AD HOC file sharing service;

means for sending, with a first device, an announcement of an AD HOC file sharing service to each of one or more other devices, wherein the announcement includes a user identity of a user associated with the first device, and access rights to the AD HOC file sharing service are granted on a per user basis;

means for establishing a connection with each of the other devices;

means for transferring files with each of the other devices, wherein the transferring comprises making files already placed in the one or more special-purpose folders available for transfer.

2. The data processing system of claim 1, wherein the established connection is a file sharing connection.

3. The data processing system of claim 1, wherein the means for establishing a connection with each of the other devices comprises:

means for presenting a user identification of a user corresponding to the other device to a user of the first device; and

means for granting access rights to the AD HOC file sharing service to the user corresponding to the other device.

4. The data processing system of claim 3, wherein access to the AD HOC file sharing service is enabled if a user corresponding to the other device does not have a file sharing account on the first device.

5. The data processing system of claim 3, wherein access to the AD HOC file sharing service is enabled without using an authentication service on another device that is not the first device nor one of the other devices.

6. The data processing system of claim 3, wherein access to the AD HOC file sharing service is enabled without a user corresponding to the other device having to log into the AD HOC file sharing service.

7. The data processing system of claim 1, further comprising:

means for establishing a file repository for the AD HOC file sharing service.

8. The data processing system of claim 7, wherein the file repository is a directory.

9. The data processing system of claim 1, further comprising:

means for fulfilling a file browsing request from one of said other devices.

10. A data processing system comprising:

means for placing one or more files in one or more special purpose folders associated with an AD HOC file sharing service on a first device, wherein the ADHOC file sharing service is configured to automatically make files placed in the special purpose folders available for sharing using the AD HOC file sharing service;

means for sending, with a first device, an announcement of an AD HOC file sharing service to each of one or more other devices, wherein the announcement includes a user identity of a user associated with the first device; and

means for granting access rights to the AD HOC file sharing service to each of the other devices, wherein the access rights to the AD HOC file sharing service are granted on a per user basis and access is enabled if a user corresponding to each of the plurality of other devices does not have a file sharing account on the first device, and wherein granting the access rights to the AD HOC file sharing service comprises allowing access to files already placed in the one or more special purpose folders.

11. The data processing system of claim 10, wherein access to the AD HOC file sharing service is enabled if a user corresponding to the other device does not have a file sharing account.

12. The data processing system of claim 10, wherein access to the AD HOC file sharing service is achieved without an authentication service using another device that is neither the first device nor one of the other devices.

13. The data processing system of claim 10, wherein access to the AD HOC file sharing service is achieved without a user corresponding to the other device having to log into the AD HOC file sharing service.

14. The data processing system of claim 10, further comprising:

means for establishing a file repository for the AD HOC file sharing service.

15. The data processing system of claim 14, wherein the file repository is a directory.

16. The data processing system of claim 10, further comprising:

means for fulfilling a file browsing request from one of said other devices.

17. A method of data processing, comprising:

placing one or more files in one or more special purpose folders associated with an AD HOC file sharing service on a first device, wherein the AD HOC file sharing service is configured to automatically make files placed in the special purpose folders available for sharing using the AD HOC file sharing service;

sending an announcement of an AD HOC file sharing service to each of one or more other devices, wherein the announcement includes a user identity of a user associated with a first device, and access rights to the AD HOC file sharing service are granted on a per user basis;

establishing a connection with each of the other devices;

transmitting a file with each of the other devices, wherein the transmitting includes making available for transmission files that have been placed in the one or more special-purpose folders.

18. The data processing method of claim 17, wherein the connection is a file sharing connection.

19. The data processing method of claim 17, wherein the step of establishing a connection with each of the other devices comprises:

presenting user identifications of users corresponding to the other devices to a user of the first device; and

granting an access right to the AD HOC file sharing service to a user corresponding to the other device.

20. The data processing method of claim 19, wherein access to the AD HOC file sharing service is enabled if a user corresponding to the other device does not have a file sharing account on the first device.

21. A data processing system comprising:

means for placing one or more files in a folder associated with an AD HOC file sharing service on a first device, wherein the AD HOC file sharing service is configured to automatically make files placed in the folder available for sharing using the AD HOC file sharing service;

means for performing the following steps in response to a user selecting the folder configured for the AD HOC file sharing process:

initiating the AD HOC file sharing procedure at the first device, and

enabling the AD HOC file sharing process by sending an announcement of the AD HOC file sharing service to each of the one or more other devices, wherein the announcement includes a user identity of a user associated with the first device, access rights to the ADHOC file sharing service are granted on a per user basis, and access is enabled if a user corresponding to each of the other devices does not have a file sharing account on the first device.