MX2012006424A - Sending files from one device to another device over a network. - Google Patents

Abstract

Techniques are provided for causing a file to be sent from a source device over a network to one or more destination devices. An intermediary receives a notification of a file and determines which destination device(s) are to retrieve the file. The intermediary may determine the destination device(s) based on one or more attributes of the file. The intermediary may cause the file to be stored in persistent storage that is maintained by a separate storage service. The intermediary may cause the file to be deleted after a particular period of time. The source device may send multiple versions of a file to the intermediary, which determines which destination device is to receive which version. The file may be a digital image and a destination device may be a device that displays a slideshow of digital images while the destination device receives the digital image over a network.

Description

SENDING FILES FROM A DEVICE TO ANOTHER DEVICE THROUGH A NETWORK SCOPE OF THE INVENTION The present invention relates to automatically sent digital elements, such as digital photos, from a computing device to another computing device through a network.

BACKGROUND It is increasingly common for a person to have multiple computing devices, such as a smartphone, a desktop computer and a laptop. Many people who have multiple devices want to have at least some of their files stored on each of their devices. One way to achieve this is. that the user by email sends a file from one of their devices (the "source" device) to an online account, such as an email account. Subsequently, the user operates another of their devices (or "recipient" device) to access the online account and start downloading that file to the recipient device. The user performs this series of steps for each of their target devices.

Another way is to physically connect two devices (for example, through a USB port on the respective devices) and instruct the recipient device to access the source device and retrieve a copy of the source device file. The user would have to carry out this series of steps for each of their target devices.

Both forms require significant and laborious user interaction. In addition, to the extent that the user wants a file to be transferred to multiple recipient devices, both forms require repetitive (or at least very similar) steps, such as accessing an online account or connecting two wired devices (for example , USB). Additionally, both forms require the user to physically manage and operate each of their target devices.

The forms described in this section are forms that can be implemented, but not necessarily forms that have been previously conceived or implemented. Therefore, unless otherwise indicated, it should not be assumed that any of the forms described in this section fit as prior art simply by virtue of its inclusion in this section.

BRIEF DESCRIPTION OF THE FIGURES In the figures: FIG. 1 is a block diagram describing an exemplary system for sending files originating in one device to another or more devices, according to one embodiment of the invention; FIG. 2 is a block diagram describing different types of data that are maintained by an intermediary that handles the storage of files received from the source devices and the notification of those files to the recipient devices, according to one embodiment of the invention; Figures 3A-B describe a process for causing a file to be sent from a source device to one or more recipient devices through a network, according to one embodiment of the invention; FIG. 4 is a block diagram describing a computer system 400 on which one embodiment of the invention can be implemented.

DETAILED DESCRIPTION OF THE INVENTION In the following description, for the purpose of explanation, numerous specific details are set forth to provide a thorough understanding of the present invention. It will be clear, however, that the present invention can be implemented without these specific details. In other cases, well-known structures and devices are shown in block diagram form to avoid unnecessarily overshadowing the understanding of the present invention.

GENERAL VIEW A user is able to make a file that is stored on a device (a "source" device) be sent to one or more devices ("recipient" devices) through a network, without having to carry out any particular operation on the recipient devices to obtain the file on the recipient devices once the file is sent from the source device. One or more intermediary devices are used to receive the file from the source device, identify one or more recipient devices that will receive the file, and send the file to or to the recipient devices. Therefore, a physical connection between the source device and the recipient device (s) is not required In a modality, after obtaining a copy of the source device file, the broker stores a temporary copy of the file. By storing a temporary copy of the file in the broker, the recipient devices do not need to be available to receive the file at the same time that the source device is available to send the file. For example, the broker can obtain a copy of the file from the source device while the recipient devices are not available to the broker, and can send the file to the recipient devices when the source device is not available to the broker. In one mode, an intermediation service is responsible for identifying and notifying the recipient devices while another intermediation service is responsible for storing the temporary copy of the file.

Thus, the file (or a copy thereof) is stored remotely from the source device and the recipient devices, at least temporarily, until each of the recipient devices retrieves the copy or some other criteria to unsubscribe the file is satisfied . For example, in one mode, the temporary copy of a file is unsubscribed or becomes inaccessible in remote storage after the temporary copy has been stored for a certain period of time, even if not all the receiving devices received it the file.

In one modality, multiple versions of a file are sent from a source device to be stored remotely. An intermediary entity determines which recipient device receives which version. Thus, a recipient device can receive a first version of a file (for example, without ever receiving a second version of the same file) and another recipient device can receive the second version of the file (for example, without ever receiving the first version of the file). ) In a modality, an attribute of a file (coming from a source device) is used to determine which recipient devices have to receive the file. For example, the identity of the person detected in a digital image can be used to determine that the digital image should be sent to a particular group of one or more recipient devices.

In one embodiment, a digital image is sent through a network, from a source device to a recipient device while the recipient device is projecting a presentation of images in progress. The digital image is added to the presentation in progress while the recipient device is projecting the presentation, without interrupting it.

PANORAMA OF THE SYSTEM FIG. 1 is a block diagram describing an exemplary system for making files that are generated from a computing device to be sent to another or other computing devices, according to one embodiment of the invention. FIG. 1 describes the following elements: source device 110, network 120, sending server 130, third-party storage service 140 and target devices 150A-C. In a related embodiment, there is no third-party storage service 140. In contrast, the functionality of the third-party storage service 140 (described below) is carried out by the sending server 130.

The source device 110 and the recipient devices 150A-C are computing devices that are capable of communicating with the sending server 130 through the network 120. Non-limiting examples of the source device 110 and the recipient devices 150A-C include desktop computers, laptops, tablet computers, smart phones (smartphones), personal digital assistants (PDA's) and other electronic handheld devices. Also, the embodiments of the invention are not limited to the particular communication protocol that is used to transfer data and messages between the source device 110 and the sending server 130 and between the sending server 130 and the recipient devices 150A-C. A non-limiting example of a communication protocol that can be employed by the entities described in FIG.l is the Hypertext Transfer Protocol (HTTP).

For simplicity, only one source device and only three recipient devices are described in FIG.l. However, there may be more or less (but at least one) recipient devices that each receive a copy of a file that the source device 110 sends through the network 120 to be stored by the third-party storage service 140 ( or by the sending server 130). In addition, the sending server 130 is configured to operate with various source devices, each of which may be associated with a different group of recipient devices.

In one embodiment, a source device (e.g., source device 110) sends a file through network 120 to be stored by a third-party storage service 140 (or by a send server 130) although the source device is not associated with any recipient device. For example, no recipient device could have been registered (e.g., with the sending server 130) to receive files transmitted from the source device or the source device might not have registered (e.g., with the sending server 130) any recipient devices as a receiver of files sent by the source device. However, after one or more files sent by the source device are stored by the third-party storage service 140 (or by the sending server 130), a recipient device becomes a registered device for receiving files from the source device. Subsequently, the sending server 130 causes one or more files (which are stored by the third-party storage service 140 or by the sending server 130) to be sent to the recipient device. In this way, one or more files can be accumulated in "the cloud" without requiring a recipient device to be registered to receive those files while those files are transmitted by the source device.

The source device 110 is configured to send messages through the network 120. At least some of the messages include files. Some of the messages may include notifications, received by the sending server 130, that one or more files must be uploaded (or sent) from the source device 110. The files may be of any type. Non-limiting examples of file types include image files, executable files, word processing files, text files, music files and video files. Furthermore, each file of each type of file can be in one of several different types of formats. For example, image file formats can include JPEG, TIFF, RA, PNG, GIF, BMP and WebP.

The recipient devices 150A-C are configured to receive and store a file that was transmitted from a source device 110. In one embodiment, the target devices 150A-C have computer programs to operate various types of files. For example, if the file is an image file, then the recipient devices 150A-C may have computer programs capable of reproducing the corresponding image on a display screen. If the file is a video file, the 150 A-C recipient devices may have computer programs to play the corresponding video.

TRANSMISSION OF MESSAGES FROM THE SOURCE DEVICE According to one embodiment, the source device 110 is configured to automatically transmit messages through the network 120 in response to detecting certain events occurring. It is said of a device that is "configured" to carry out an action if the device executes a computer program that is capable of carrying out the action. The events that cause the source device 110 to automatically send messages to the sending server 130 are referred to there as message trigger events.

Specific events that trigger messages may vary from one implementation to another. For example, in one embodiment, the generation of a new digital image in the source device 110 is a message trigger event. In such an embodiment, the source device 110 is configured to transmit a message to the sending server 130 in response to detecting that a new digital image is present in the source device 110. A new image can be detected, for example, upon detection When a camera inserted into the source device 110 has taken a picture.

In another embodiment, establishing a certain type of connection after a new file has been generated in the source device 110 may be a message trigger event. For example, assuming that the source device 110 is a cellular telephone capable of communicating over the Internet using an Edge connection, a 3G connection and a Wi-Fi connection. In such mode, establishing an i-Fi connection to the Internet after one or more images have been created in the source device 110 can automatically trigger the source device to send a message to the sending server 130 through the Wi-Fi connection. Fi. The message may indicate, for example, that one or more new files have to be uploaded, to be retransmitted to the 150A-C recipient devices.

The following is a non-limiting list of message trigger events that cause a message to be automatically sent from the source device 110 to a 130 send server: • while the source device 110 has some connection to the sending server 130, a new file of a particular type of file is created in the source device • while the source device 110 has some connection to the sending server 130, a file of a type particular is transferred to a particular directory in the source device 110; • while the source device 110 has some connection to the sending server 130, a file of a particular type is labeled with a particular tag in the source device 110; • while the source device 110 has some connection to the sending server 130, a new recipient device is designated; • while the source device 110 has a first connection type to the sending server 130, a second type of connection is established between the source device 110 and the sending server 130; • after the source device 110 has been disconnected with the sending server 130, a connection of any kind is established between the source device 110 and the sending server 130.

These are simply examples of the various message trigger events that can be used to initiate the process that causes temporary copies of files to be automatically sent from the source device 110 to the storage service 140.

NOTIFICATION TO THE RECIPIENT DEVICE According to one embodiment, the recipient devices 150A-C are notified by the sending server 130 of a file that is intended for 150A-C recipient devices. As mentioned above, such notification may occur asynchronously in connection with the transmission of the file to intermediate storage. For example, the notification may occur in response to the sending server 130 detecting that a recipient device has established a connection with the sending server, which may occur some time after a copy of the file has been transferred from the source device. 110 to the intermediary. In embodiments where the intermediary stores a temporary copy of the file, the notification may occur even during a period in which the source device 110 is disconnected. { offline).

The notification from the sending server 130 may include the file itself. Alternatively, the notification may include storage location data indicating where the file is stored. In response to receiving a notification, each of the recipient devices 150A-C send to the appropriate storage service (e.g., third-party storage service 140), a request that includes the storage location data or information identifying the file. The third-party storage service 140 uses the location data of the storage or file identifier (in the request) to locate the file and send the file to the recipient device that sent the request. Thus, a user of the recipient device may not be required to take any action (beyond having his or her recipient device turned on) to receive a file from a source device.

CODING In one embodiment, files sent from the source device 110 to be retransmitted to a recipient device 150A-C are encoded (encrypted) before being stored in the third-party storage service 140. The encoding can be carried out by the device source 110 or by the sending server 130. Any technique for encoding files can be used. In addition, any key used to carry out the encoding and decoding can be used. Non-limiting examples of an encoding key for encoding the file (s) include data about the source device 110, data about the user of the source device 110, or data about the user's password.

In order to decode the encoded file (s), the recipient devices 150A-C (or the sending server 130) will need access to the encoding key. Thus, in one embodiment, the sending server 130 sends the encryption key to the recipient devices 150A-C when the recipient devices receive the encoded files from the third-party storage service 140. Alternatively, the 150A-C recipient devices may having already had access to the encryption key, which could have been stored in the 150A-C recipient devices before the file or files are encoded. In another scenario, as long as the encoded files are stored in the third-party storage service 140, the encoded files can not be decoded by the storage service 140 or by any other entity that can gain unauthorized access to the encoded files while the files are encrypted. encoded files are stored by the storage service 140.

NET Communication between the sending server 130 and the source device 110, the third-party storage service 140 and the recipient devices 150A-C is made possible through the network 120. The network 120 can be implemented by any means or mechanism that provides the exchange of data between various computing devices. Examples of such network include, without limitation, a network such as a Local Area Network (LAN), Wide Area Network (WAN), Ethernet or the Internet, or one or more terrestrial, satellite or wireless connections. The network may include a combination of networks such as those described. The network can transmit data according to the Transmission Control Protocol (TCP), User Datagram Protocol (UDP), and / or Internet Protocol (IP).

SHIPPING SERVER AND THIRD PARTY STORAGE SERVICE The sending server 130 is responsible for ensuring that the files transmitted from the source device 110 are stored remotely (in relation to the source device 110 and the recipient devices 150A-C) and eventually sent to one or more recipient devices 150A-C. In other words, the sending server 130 (in conjunction with the third-party storage service 140) acts as a remote cache to which the files are sent from the source device 110 and from which the files are sent to the recipient devices 150A-C. For this purpose, the sending server 130 maintains certain types of data that are illustrated in FIG.2.

The sending server 130 is configured to receive notifications from the source device 110 about the fact that one or more files will be transmitted from the source device 110. In response to said notification, the sending server 130 sends, to the source device 110, storage location data that indicate where the file (s) are to be sent. The storage location data may be data associated with the third party storage service 140. The source device 110 uses the storage location data to transmit the file (s) to the third party storage service 140.

For example, the storage location data that is sent from the sending server 130 to the source device 110 may comprise a Uniform Resource Locator (URL). The URL may include one or more values, generated by the sending server 130, which are associated with the or other files that are to be sent from the source device 110. The value (s) may be identifiers of files that uniquely identify one or more. more files relative to all other files that the source device 110 (and / or other source devices) sent to the third-party storage service 140. Those values may be stored by the third-party storage service 140 in association with the or the files. Then, the third-party storage service 140 receives, from one of the recipient devices 150A-C, a request that includes the value (s). The third-party storage service 140 uses the value (s) to identify the corresponding file (s), which the third-party storage service 140 sends to the recipient device.

THIRD PARTY STORAGE SERVICE The third-party storage service 140 is a storage service that is contracted by the entity that operates the sending server 130 to provide storage of files that are sent from the source device 110 (and other source devices not illustrated in FIG. ). Thus, while the sending server 130 maintains information about the files transmitted from the source device 110 and where those files must be transmitted (or sent), the third-party storage service 140 simply stores the files. The third-party storage service40 stores the data associating an identifier for a file with a persistent storage location maintained by a third-party storage service 140. Then, when the third-party storage service 140 receives a request for a storage. file and the request includes an identifier, the third-party storage service 140 uses the identifier to determine where the file is stored. The third-party storage service 140 reads the file from the storage location and sends the file to the requester (e.g., one of the recipient devices 150A-C).

In one embodiment, where the third-party storage service 140 is not part of the system, the source device 110 sends the file to the sending server 130, which will then be responsible for storing the file. Therefore, in this mode, it is not necessary for the sending server 130 to generate and send location data of the storage to the source device 110 or to any of the recipient devices 150A-C.

DEVICE ASSOCIATION DATA According to FIG.2, the sending server 130 stores device association data 210, selection criteria of the recipient device 220 and file recovery data 230. The association data of the device 210 associates the source device 110 with the target devices 150A-C. The device association data 210 can be logically organized on a per-source device basis. For example, device association data 210 may comprise a set of inputs (e.g., in a table), where each input associates a source device with one or more recipient devices.

Each entry can comprise two fields: a source device field and a recipient device (s) field. An index can be created based on the source device field to allow relatively quick access to the appropriate inputs.

The association between two devices can be unilateral or bilateral. In a unilateral association, certain files created in a first device are automatically sent to a second device, but the same type of files created in a second device are not automatically sent to the first device. In a bilateral association, the files created in both the first and second devices are sent to the other, first or second devices. Additionally, a single source device may have unilateral associations with some devices and bilateral associations with other devices.

In one embodiment, each entry in the device association data 210 may simply indicate multiple devices. Thus, each entry may need to be examined to identify an identifier for the appropriate source device. Once the identifier for the source device is located, the or other device identifiers in the input are used to identify the corresponding recipient device.

The device association data 210 may be established by a source device user 110 or by one of the users of the 150A-C recipient devices, if the users are different. The user may operate a source device 110 or recipient devices 150A-C (or other device) to establish device association data 210 and cause the device to send device association data 210 to the sending server 130. The association data of device 210 can be updated based on the data entries made by the user at any time from any device.

Alternatively, the device association data 210 may be established by the sending server 130 when the sending server 130 detects that the source device 110 and the recipient devices 150A-C are all devices that are registered with the same user or account in. line. Thus, after a user buys a device, the user can register the device with the sending server 130 or with another entity that is associated with the sending server 130. Once determined that the same user has registered multiple devices (or that multiple devices are registered with the same account, which can be associated with multiple users), the sending server 130 stores the data associating all registered devices with each other.

Thus, a user of a source device may not be required to specify, for each file transmitted to the sending server 130, which recipient device (s) will receive the file. Instead, the sending server 130 is configured to determine which recipient device (s) will receive the file (eg, based on information previously provided by a user) and ensures that the file is sent to the recipient devices appropriate.

POST-RECORDED DESTINATION DEVICES As explained above, the files are automatically sent from the source device 110 to the recipient devices 150A-C with which the source device 110 is associated. After the files have been sent from the source device 110 to the recipient devices 150A-C, it is possible to add an additional recipient device to those with which the source device 110 is associated.

This situation may occur, for example, when a user purchases and registers another computing device with an account that is already associated with the source device 110 and the recipient devices 150A-C. Thus, a registered device for the first time can receive all files that have been uploaded by any source device 110 and recipient devices 150A-C, or all the files that have been loaded during a certain period of time (for example, the last 30 days).

This situation can also occur when the user adds a new "friend" in a social network, and the friend specifies that he / she wishes to receive files sent by the owner of the source device 110. Under these circumstances, the sending server 130 can send to the device (s) of the new friend all the files that have been sent by the source device 110, or all the files that have been sent by the sending device 110 within a particular period of time.

CRITERIA FOR SELECTION OF THE RECIPIENT DEVICE In a modality, device association data 210 indicates, for a given source device, multiple different sets of recipient devices. For example, device association data 210 indicates (1) that source device 110 is associated with recipient devices 150A-C for all image files and (2) that source device 110 is associated with recipient devices 150A and 150B (but not with the 150C recipient device) for all other file types. To identify the appropriate set of recipient devices, the sending server 130 uses selection criteria of the recipient devices 220 (or simply "selection criteria 220"). Non-limiting examples of selection criteria 220 include: • a time (such as when the source device 110 notifies the sending server 130 of a file or when the file was created) the file type the author or creator of a file content of a file, • other data, such as an explicit indication that is sent from the source device 110 and that is associated with the transmission from the source device 110 of (a) the file or (b) a notification of the file.

An example of an explicit indication is the device identification data that is included in a transmission from the source device 110, where the identification data of the device identifies (either directly or indirectly) the recipient device 150A and 150C (but not the recipient device 150B).

Thus, the time, type, author, or content of a particular file can be used to order to which set of recipient devices the particular file should be sent. As an example of this function, any file transmitted from the source device 110 after 10PM and before 5AM will be transmitted to the recipient devices 150A and 150B, while any file created by George Smith will be transmitted to the recipient device 150th at any time.

The selection criteria 220 may or may not be stored as part of the device association data 210. For example, the selection criteria 220 may be stored in another field for each entry in the device association data 210. As another example , the selection criteria 220 may be stored in the source device field of each entry in the device association data 210. Thus, since multiple entries may exist for the source device 110, each entry may include a different set of criteria of selection.

Similar to the device association data 210, the selection criteria 220 may be set by a user operating either the source device 110 or recipient devices 150A-C (or other device).

PENDING FILES The files that are stored by a third-party storage service 140 (or by the sending server 130) and that have not yet been transmitted to all their respective recipient devices will be referred to hereafter as "pending files" with respect to those devices recipients to whom they have not been sent. For example, files A and B are stored in a third-party storage service 140, the recipient device 150a has retrieved files A and B from the third-party storage service 140, the recipient device 150B has retrieved the file A but not the file B of the third-party storage service 140, and the recipient device 150C has not yet recovered either the A file or the B of the third-party storage service 140. Therefore, the A file is considered a "file" pending "with respect to the recipient device 150C and the file B is considered" pending file "with respect to the recipient devices 150B and 150C.

One reason why a recipient device may not have been notified of a pending file for a period of time is because the recipient device does not have a certain type of connection to the sending server 130. Therefore, there may be no form ( at least during that period of time) so that the sending server 130 notifies the recipient device of one or more pending files for that recipient device. Once the connection is restored between the sending server 130 and the recipient device the sending server 130 is configured to send, to the recipient device, a notification that the recipient device should ask the sending server 130 to discover one or more files that are stored remotely relative to the recipient device and intended for the recipient device.

FILE RECOVERY DATA To ensure that pending files are transmitted to the appropriate recipient devices, the sending server 130 maintains data on pending files in the file retrieval data 230, described in FIG.2. File recovery data 230, associates one or more pending files with one or more recipient devices. The file retrieval data 230 may include information on a per recipient device basis. For example, the file retrieval data 230 may include an entry that associates the recipient device 150A with the A and B files. The existence of that entry in the file retrieval data 230 indicates that the 150A recipient device has not yet been notified of (or retrieved) the files A and B. As an additional example, the file retrieval data 230 may include another entry that associates the recipient device 150B with the A and C files. The existence of that entry in the data of File retrieval 230 indicates that the 150B recipient device has not been notified of (or has not recovered) the A and C files.

The sending server 130 may create a new entry (or record) in the file retrieval data 230 in response to the sending server 130 (1) having received an indication of the source device 110 that the source device 110 stores a particular file e (2) identifying the recipient device (s) that will receive the particular file (e.g., using device association data 210). In addition to associating one or more pending files with one or more recipient devices, the sending server 130 may also associate location data of the file storage with the pending file (s). When the sending server 130 notifies the recipient or devices on the pending file (s), the notification includes the location data of the file storage, which can identify the third party storage service 140. The notification may comprise a URL which is associated with the third-party storage service 140 and that includes the file identification data that the third-party storage service 140 uses to identify the file (s). In this form, the third-party storage service 140 maintains a file location mapping with identifier (ID) for storage. The third party storage service 140 uses the file identification data to identify the appropriate mapping, retrieves the file (s) from the corresponding location and sends the file (s) to the recipient device requesting them.

Additionally or alternatively, the file retrieval data 230 may include information on a per-source basis. For example, each source device may be associated with a "source" table that has two columns: a file identifier column and a column with timestamps. The sending server 130 adds a row to the source table for each file received from the source device corresponding to the table. The sending server 130 updates the row to indicate an identifier for the received file and a time stamp (timestamp) indicating when the file was received. When a recipient device sends, to the sending server 130, a request for information about one or more files, the sending server 130 determines which source device (s) are associated with the recipient device and analyzes the request to determine the last time it was sent. the file was used (according to timestamp time stamp). The last time stamp in the "source" table is used to identify, in the source table, each file that is associated with a time stamp and which time stamp is most important with respect to the most current time stamp.

In the embodiment where the file retrieval data 230 includes information on a per-source basis, the sending server 130 can maintain a destination-to-source mapping that associates a recipient device with all possible source devices. The destination-to-source mapping is used to determine, for a particular recipient device, which source tables should be analyzed to determine which files should be sent to the particular recipient device.

A source table may also include an expiration column indicating when the corresponding file is to be deleted from the third-party storage service 140 or, at least, when a recipient device that has not yet received the corresponding file will no longer be able to receive the corresponding file. When the time indicated by an entry in the expiration column equals the current time, the source table can be updated to remove or delete the corresponding row of the source table.

In some scenarios, a recipient device may be subscribed to receive files from the source device 110 in some situations but not in others. For example, the recipient device 150B could receive all the image files of the source device 110 but not non-image files. Thus, when the source device 110 notifies the sending server 130 of a non-image file, the sending server 130 needs to ensure that the recipient device 150 does not receive the non-image file. Thus, in one embodiment, the table may include a "must receive" column for each recipient device that may receive a file from source device 110. The "must receive" column indicates whether the recipient device should receive the corresponding file. Thus, when a recipient device requests information about one or more files, the sending server 130 determines which source devices are associated with the recipient device and analyzes the "must receive" column to determine whether the recipient device should receive the corresponding file. If the "last seen" time stamp of the recipient device is less than the corresponding time stamp of the file and the "must receive" column indicates that the recipient device should receive the corresponding file, then the sending server 130 sends information about the file corresponding to the recipient device.

SHIPPING PROCESS FIGs. 3A-B illustrate a process 300 for sending a file from a source device 110 to recipient devices 150A-C using the sending server 130, according to one embodiment of the invention.

In step 305, the source device 110 stores a particular file. The source device 110 may have created the particular file. Alternatively, the source device 110 may receive the particular file of another device, such as a camera or other computing device, such as a smartphone. { smartphone), laptop or tablet. As another example, step 305 may be triggered by the user by moving the particular file from one location to another in the source device 110, or by tagging the particular file with a particular tag.

In step 310, the source device 110 sends, through the network 120 to the sending server 130, an indication that the source device 110 has a file to be automatically sent to one or more devices. The indication is sent in response to having detected the message trigger event, but may not occur immediately after the message trigger event. For example, if the source device 110 is not online when the message trigger events occur, then the step 310 may occur the next time the source device 110 connects to the network 120.

In some embodiments, the indication that is sent by the source device 110 in step 310 may include the particular file. However, the following description of the process 300 is of a mode where the particular file is not sent from the source device 110 to the sending server 130; instead, the particular file is sent from the source device 110 to the third-party storage service 140.

The indication sent in step 310 may include identification data identifying the particular file. Alternatively, the sending server 130 creates an identifier for the particular file. The identifier for the particular file may be based on one or more criteria, such as the name of the particular file, an identity (eg, name) of the source device 110, date and time the particular file was created, and / or date and time in which the notification was received on the sending server 130. The identifier for the particular file may be unique in relation to all the files transmitted from the source device 110 or in relation to all the files on which the sending server 130 is notified from all source devices.

The creation (or storage) of the particular file in the source device 110 can trigger the completion of step 310. For example, a user takes a digital image using a smartphone that includes a camera. The software running the smartphone detects that the digital image was created and causes step 310 to take place.

Another possible trigger to carry out step 310 is the establishment of a connection between the source device 110 and the sending server 130. For example, the source device 110 may be a Wi-Fi enabled smartphone that is not in the range of a Wi-Fi signal when a picture is taken with the smartphone. When the smartphone is in range and the connection is strong enough to send a message using the Wi-Fi capability, a process running on the smartphone initiates step 310. As a similar example, the smartphone can wait until the smartphone is in the range of the signal from a cellular telephone network before carrying out step 310.

Another possible trigger to carry out the step 310 is storage of the file in a particular folder, library or storage location in the source device 110. A user of the source device 110 may have designated to share all the files that are stored in a particular folder with other devices that are associated with the source device 110, such as the recipient devices 150A-C. Thus, in response to storage of a file in that folder, the source device 110 sends a notification of the file to the sending server 130.

In step 315, the sending server 130 sends to the source device 110, file location data indicating where the source device 110 should send the particular file. The file location data may be a Uniform Resource Locator (URL) that includes data that the third-party storage service 140 uses to associate the particular file with a storage location maintained by a third-party storage service. 140. Then, when the third-party storage service 140 receives, for example, the recipient device 150B, a request that includes data identifying the particular file, the third-party storage service uses that data to identify the particular file. in storage and then transmits the particular file to the recipient device 150B.

In step 320, the source device 110 sends the particular file to the location identified in the file location data. For example, if the file location data of the sending server 130 includes a URL, then the source device 110 may send an HTTP POST request that includes the URL, the particular file and identifying data identifying the particular file.

In step 325, the third-party storage service 140 stores the particular file and maintains a mapping that tracks (1) identification data (as sent in step 320) that identifies the particular file with (2) a location in persistent storage maintained by a third-party storage service 140.

In step 330, the sending server 130 determines which recipient device should be notified of a particular file. If the source device 110 is associated with multiple sets of recipient devices, then the sending server 130 analyzes the selection criteria 220 associated with the source device 110 to determine the appropriate play of one or more target devices indicated in the association data of 210 device.

In step 335, the sending server 130 stores data indicating which files need to go to which target devices. This step can be carried out by updating the file retrieval data associated with each recipient device identified in step 330 to reflect that that recipient device has not yet received (or been notified of) the particular file identified in step 310. For example, if the sending server 130 determines that the recipient devices 150A-C are to be notified of the particular file, then the sending server 130 updates (or creates a new entry in) the file recovery data associated with each one. of the recipient devices 150A-C to indicate that the recipient devices have not yet been notified of the particular file. If there is already an entry in the file retrieval data 230 for each or more of the 150A-C recipient devices, then that entry can be updated to include data about the particular file, such as an identifier that uniquely identifies the particular file. .

In step 340, the sending server 130 sends, to each recipient device identified in step 330, a notification that one or more files are ready to be retrieved by the recipient device. For example, if the recipient devices 150A-C are identified in step 330, then each of the recipient devices 150A-C receives the notification. The notification may or may not contain information about the specific file (s) to be retrieved, such as the file name, type, size, or source (s) of the file (s). ). If the notification includes data about the file (s) to be recovered (s), then the notification must include file location data indicating where the file (s) are located. The notification may include a Uniform Resource Locator (URL) containing data that identifies, to the third party storage service 140, the particular file to be retrieved. The data may comprise one or more values that uniquely identify the particular file in relation to other files stored by the third-party storage service 140.

The notification in step 340 may be sent to a recipient device only after it has been determined that a certain type of connection was established between the sending server 130 and the recipient device. For example, if there is no connection between the sending server 130 and the recipient device 150B, then the sending server 130 waits until the connection to the recipient device 150B is restored before sending the notification to the recipient device 150B. As long as there is no connection between the recipient device 150B and the sending server 130, the sending server 130 may have received numerous notifications from the source device 110 (and / or other source devices) about files that will be transmitted to the recipient device 150B . In response to these notifications, the sending server 130 updates the recovery data of the file 230 associated with the recipient device 150B to reflect that those files are destined for the recipient device 150B. For example, the sending server 130 creates numerous entries and each one identifies one or more files and associates those entries with the recipient device 150B. Another example is when the sending server 130 adds, to a single entry in the recovery data of the file 230, data identifying all those files.

Another factor in determining whether a notification should be sent to a particular recipient device may be the workload on the sending server 130. For example, the sending server 130 may be busy processing indications / notifications of source devices and communicating with others target devices. The broadband connection, current workload, and / or other factors can be considered to determine when to notify the particular recipient device. For example, if the total broadband connection of the sending server 130 falls into a particular threshold, then the sending server 130 will send a notification to the particular recipient device.

Additionally or alternatively, the users of the recipient devices may establish one or more parameters that they order when the sending server 130 is authorized to send. For example, a user can specify that all send notifications must occur at a certain time of the day (for example, between 2AM and 5A), when the use of their recipient device is under a particular threshold (for example, 50% CPU ), or when the recipient device remains without working for more than a certain period of time (for example, 30 minutes.

In step 345, if the notification sent in step 340 does not include any data that can be used to identify the particular file for the third-party storage service 140, then each recipient device notified in step 340 sends, to the server shipment 130, a request for identification of files that are to be transmitted to the recipient device.

In step 350, in response to the request received in step 345, the sending server 130 sends, to the requesting recipient device, file location data indicating where the requesting recipient device can retrieve the particular file. The file location data may include data that identifies the particular file and any other files that are to be transmitted to the requesting recipient device. The file location data may include a URL that is associated with (or identifies) the third-party storage service 140 and that the requesting recipient device uses to retrieve the particular file. Step 350 may comprise the sending server 130 using the identity of the requesting recipient device to search the appropriate entry or entries in the file retrieval data 230 to identify data identifying the particular file and any other files that are to be transmitted to the file. Applicant recipient device.

In step 355, the sending server 130 updates the file retrieval data associated with a recipient device to indicate that that receiving device has been notified of one or more files (including the particular file). This update may include deleting, in an entry associated with the recipient device, data identifying the file (s). An update of the file retrieval data 230 in this step may be carried out in response to the sending server 130 sending (a) the notification in step 340 or (b) the identification data in step 350. Alternatively, the sending server 130 updates the file retrieval data associated with a recipient device in response to having received (e.g., from the recipient device) data indicating that that receiving device actually received (a) the notification sent in step 340 or (b) the identification data in step 350. Alternatively, the sending server 130 updates the file retrieval data associated with a recipient device in response to receipt (e.g., from the third-party storage service 140). or of the recipient device) data indicating that one or more files were successfully received by the recipient device. The file recovery data associated with one or more recipient devices that have not yet received or been notified of the particular file remain unchanged, at least with respect to the particular file.

In a related embodiment, the sending server 130 updates the file retrieval data associated with a recipient device each time the sending server 130 determines that certain actions have been taken with respect to a pending file for the recipient device. For example, the sending server 130 creates an entry (or record) in the file retrieval data 230, which entry is associated with the recipient device 150B. The entry indicates that the sending server 130 has not yet notified the recipient device 150B of file A. Then the sending server 130 updates the entry to indicate that the sending server 130 has sent a notification to the recipient device 150B of file A. Then, the sending server 130 updates the entry to indicate that the receiving device 150B received the notification. Then, the sending server 130 updates the entry to indicate that the recipient device 150B sent, to the third-party storage service 140, a request for the file A. Then, the sending server 130 updates the entry to indicate that the service third party storage 140 sent the file A to the recipient device 150B. Then, the sending server 130 updates the entry to indicate that the recipient device 150B received the file A. Then, the sending server 130 may delete the entry.

In step 360, each notified recipient device uses the file location data to formulate or send, to the third-party storage service 140, a request for the file (or files). The request may be, for example, an HTTP GET request that includes a URL that includes identification data that is used by the third-party storage service 140 to identify the file (s).

In step 365, the third-party storage service 140, in response to having received the request from a recipient device, identifies one or more files (including the particular file) indicated in the request and sends the file (s) to the recipient device .

In step 370, each recipient device that receives the particular file stores the particular file, for example, in a particular library of files that are accessible to an application that is configured to process the particular file. For example, if the particular file is a digital image, the digital image can be stored in a library of images that are accessible to a photo management application that is installed on the recipient device. The photo management application may or may not be running on the recipient device when the digital image is stored in the digital image library.

In one embodiment, a process running on a recipient device that receives the particular file (for example, an application that is configured to process a particular file) may cause a message to be displayed on the recipient device indicating that a file has been recently received in the recipient device. Such a message allows the user of the recipient device to immediately know that a new file has been added to the recipient device. The message can be displayed for a short period of time, such as two seconds so as not to significantly distract the user of the device receiving the current task. The message may comprise a name of the particular file and / or an image of the particular file. For example, if the particular file is a digital image, then the message may include a 'thumbnail' image of the digital image and a name of the digital image. As another example, if the particular file is a video file, then the message may include a thumbnail image of a picture of the video file. As another example, if the particular file is a PDF file, then the message may include a thumbnail image of a page of the PDF file.

In one embodiment, a process running on a recipient device that receives the particular file from the third-party storage service 140 analyzes the particular file to determine where to store the particular file on the recipient device. The determination can be based on the type of the particular file (for example, image, video or text). For example, if the particular file is an image file, then the process stores the image in a library of digital images, to which a photo management application is configured to access. If the particular file is a video, then the process stores the video file in a library of video files, to which a video management application is configured to access.

The embodiments of the invention are not limited to the exact steps or the order of the steps illustrated in FIG. 3. For example, step 340 is optional if one or more of the recipient devices 150A-C is configured to regularly poll the sending server 130 for pending files. As another example, steps 330 and 335 may occur before step 325 or even step 320.

TEMPORARY STORAGE OF FILES In one embodiment, the files of the source device 110 are stored by the third-party storage service 140 (or the sending server 130) for a limited period of time, after which the files are deleted and, thus, cease to be accessible to the recipient devices 150A-C, even if one or more of the 150A-C recipient devices (for example, which are supposed to receive those files) have not yet received the files. In other words, after the period of time has elapsed, a recipient device that has not yet received a file will not be able to recover the file, even if the recipient device sends an appropriate request to the third-party storage service 140 (or to the sending server 130).

The period of time may vary from one file to another depending on one or more deletion criteria. For example, the time period for a file of the source device 110 may be 30 days while the period of time associated with another file (of the source device 110 or another source device) may be 10 days. Non-limiting examples of deletion criteria include the type of file, the creator of the file, the size of the file, people identified in an image of an image file, the particular source device and the devices indicated in the associated device association data with the file. For example, all pending image files transmitted from source device 110 are deleted after 30 days of storage. As another example, all pending files other than images transmitted from the source device 110 are not deleted (for example, there is no period of time after which no non-image file is deleted). In other words, non-image files are stored indefinitely, but the image files become inaccessible to the recipient devices after a certain period of time. As another example, all pending files transmitted from a source device are deleted after 20 days while all pending files transmitted from another source device are deleted after 30 days. As another example, all pending files for the recipient device 150A are deleted after 20 days while all pending files for the recipient device 150B are deleted after 5 days.

After a period of time has elapsed since a file was stored in a third-party storage service 140, the third-party storage service 140 can be configured to automatically delete the file. The period of time may be "preset" in the third-party storage service 140 (e.g., before the file is received in service 140) or can be, for example, indicated in data that accompanies the transmission of the file from the source device 110. Thus, the period of time associated with a file can be established by the server. sending 130 or the source device 110 and implemented by the third-party storage service 140. For example, the sending server 130 may send suppression time data to the third-party storage service 140, which it determines, based on the Suppression time data, when to delete the particular file. Alternatively, the sending server 130 sends an instruction to the third-party storage service 140 to indicate that the service 140 can delete the file immediately. In this way, the third-party storage service 140 does not require maintaining a record of when the files should be deleted (or otherwise inaccessible to the recipient devices).

In one embodiment, the sending server 130 stores suppression time data for one or more files that are stored by the third-party storage service 140. The suppression time data indicates, for each of the files, when the file is no longer accessible to the recipient device. The suppression time data may be stored in the file recovery data 230 that is associated with the recipient devices 150a-C. For example, each entry of one or more entries in the file recovery data 230 indicates a pending file for a particular recipient device. An entry may also include suppression time data, which may be a date, and, optionally, a time in which the corresponding file must be inaccessible (e.g., deleted).

In one embodiment, the sending server sends a notification to a source device if a recipient device has not yet received a pending file, for example, for that recipient device. For example, the sending server 130 analyzes the deletion time data in the file retrieval data 230 to determine if the time period associated with the corresponding file is about to elapse (for example, in the next 1-2 days) . If this is the case, then the sending server 130 notifies the source device 110 (the originator of the file) that the file has not been received by a recipient device. (To assist in the identification of the source device, the file retrieval data 230 may include data from the source device indicating, for a pending file, which source device transmitted the pending file.) The user of a source device 110 may determine, for example, that the user needs to turn on the recipient device or move to a Wi-Fi or cellular signal location, which can cause a connection to be established between the recipient device and the sending server 130. After the connection is established, the recipient device sends, to the sending server 130, a request for information about files that will be received. The request may be sent in response to a message from the sending server 130 to review with the sending server 130 the existence of one or more pending files for the recipient device.

As indicated above, the device association data 110 may be modified to indicate another recipient device. For example, a user having a source device 110 and recipient devices 150AC purchases another recipient device and registers the recipient device with the user's account. The registration of the new recipient device causes the device association data 110 to be updated to reflect that the source device 110, the recipient devices 150A-C, and the new recipient device are all associated with each other. If the recipient devices 150A-C have been notified by the sending server 130 about a pending file, then the new recipient device can be notified of the pending file. For example, if the pending file A is accessible to the 150AC recipient devices for 30 days and the new recipient device is added to the association on day 5 within the 30 day period, then the pending file A is accessible to the new recipient device for 25 days. The sending server 130 may notify the new recipient device of the pending file A, for example, as soon as the device association data 210 is updated to reflect the updated association.

SENDING BASED ON AN ATTRIBUTE OF THE FILE In one modality, one or more attributes of a file are used to determine to which recipient device (s) the file is to be sent. An attribute of a file is an example of the recipient device selection criteria 220. Additionally, other recipient device selection criteria 220 may be used to determine a particular set of recipient devices, while one or more attributes of a file (including the content of the file) can be used to identify a delimited sub-game of that particular set of target devices.

Non-limiting examples of attributes of a file include the type of the file, the size of the file, where the file was created (for example, the geographic location from which a photograph was taken or created), if the file contains specific data (for example , the file is a text file that includes the word "Jerónimo"), if an image of a particular person or object was detected and recognized in the file (if, for example, it is an image file).

For example, any image files sent from the source device 110 need only be sent to the recipient device 150A and the recipient device 150C, while any video files sent from the source device 110 need only be sent to the recipient device 150A. As another example, image files in which an image of "grandmother Joan" is detected are sent only to the recipient device 150B, while all other files are sent to each recipient device 150A-C.

As another example, the source device 110 obtains a first photo of the face of the person A 'and of the face of the person B. In response to being notified of the first photo, the sending server 130 makes the first photo be sent to the device of person A and the device of person B. Then, source device 110 obtains a second picture of the face of person B and of the face of person C. In response to having been notified of the second photo, the send server 130 causes the second photo to be sent to the device of person B and to the device of person C.

In one embodiment, several source devices may be configured to send certain photos to a particular storage location. For example, the cameras of the mothers of children of a baseball team are configured to automatically send photos taken at a particular baseball field to a storage location associated with the team's website. Thus, any photos taken by the cameras of the phones in the particular baseball field are sent to a third party storage service 140 and eventually sent to the storage location. In this way, any users who access the team's website after the photos were taken can see the photos.

As another example, Juan throws a party and has a reproduction of images in progress on a large display (screen) on the party site. Juan informs each attendee at the party about the identity of a particular device that is hooked above the display. All photos taken in the vicinity of the party location during the time of the party are sent to the particular device and automatically added to the playback of images in progress at the party.

The attribute (s) may be indicated in the attribution data that is sent from the source device 110 to the sending server 130, for example, as part of a notification of a file (see step 310 of FIG. 3). For example, the notification of the source device 110 to the sending server 130 may indicate the type of the file, the size of the file and / or an identity of a person whose image is detected in the file. Alternatively, if the sending server 130 receives the file, the sending server 130 may analyze the file to determine one or more attributes of the file. In any scenario, the sending server 130 uses the attribute (s) to determine a set of one or more recipient devices that are to be notified of the file.

SENDING FILE VERSIONS In one embodiment, the source device 110 sends two versions of a file to the third-party storage service 140 (or send server 130). For example, one version of an image file of source device 110 has a first resolution and another version of image file has a second resolution that is lower than the first resolution. As another example, a word processing file of source device 110 is in a first format (e.g., .doc) and a version of that file is in a second format (e.g.,. txt) that is different from the first format. The sending server 130 identifies the recipient devices 150A-C by being recipients of one or both versions. Thus, the recipient device 150A can receive a version of a file and the recipient devices 150B and 150C can receive the other version of the file.

Having one version of a file sent to a recipient device and another version of the file sent to another recipient device allows the versions to be sent to the appropriate devices, depending on, for example, the capabilities of the recipient device. For example, the recipient device 150A may be a portable computer with a relatively large display screen (eg, 18"screen) while the recipient device 150B may be a smartphone having a relatively small display screen (e.g. , 4"screen). A version of a lower resolution image is better suited to the smaller size screen of the smartphone than to the higher resolution version of the image.

In one embodiment, the source device 110 generates a second version of a file (the file being the "first version"). The source device 110 can send, through the network 200, only the first version of the file or both the second version and the first version. Alternatively, another entity, such as the sending server 130, generates the second version of the first version of the file.

In one embodiment, the sending server 130 determines which recipient device is to receive the version based on the version data associated with the recipient devices. The version data indicates, for one or more target devices, which recipient device is to receive a particular version of a file. For example, the version data associated with the recipient device 150A indicates that the recipient device 150A is to receive a high resolution image sent from the source device 110 while the version data associated with the recipient device 150B indicates that the recipient device 150B has to receive a lower resolution version of the image.

SENDING PHOTOS TO A PRESENTATION OF IMAGES IN PROGRESS In one embodiment, one of the recipient devices 150A-C is a device that reproduces an image display when that device retrieves an image file from a third-party storage service 140 (or the sending server 130). In response to receiving the image file, the recipient device updates the playback to include the image file in the playback. For example, the recipient device 150A is reproducing a different digital image from a presentation of 100 images of digital images every 3 seconds when the recipient device 150A receives a notification from the sending server 130 on one or more files.

While the presentation of images is reproduced, the recipient device 150A (1) sends, to the third-party storage service 140, a request for one or more files, (2) receives one or more files from the third-party storage device 140. , and (3) updates the presentation of images to include a digital image of the file (s). The recipient device 150A may be configured to cause the digital image to be reproduced as soon as the recipient device 150a receives the digital image. Alternatively, the recipient device 150A may be configured to include the digital image at a certain position in the order of display of the other images in the image reproduction. The display order can be based on a time record. { timestamp) associated with each digital image or some other criteria, such as the source device, or a geographic location of the content in the digital image or some other feature of the content in the digital image.

GENERALITIES OF THE HARDWARE According to one embodiment, the techniques described herein are implemented by one or more special purpose computing devices. Special lens computing devices can be hardwired to perform the techniques, or may include electronic digital devices such as one or more specific application integrated circuits (ASICs) or field programmable gate arrays (FPGAs) that are persistently programmed to perform the techniques, or may include one or more hardware processors of general objective to carry out the techniques according to the instructions of the program in firmware, memory, other storage or a combination. Such special purpose computing devices can also combine the traditional wiring system, ASICs, or FPGAs with the traditional programming to accomplish the techniques. The special purpose computing devices can be desktop computing systems, portable computer systems, handheld devices, network devices, or any other device that incorporates wiring and / or software to implement the techniques.

For example, FIG. 4 is a block diagram illustrating a computer system 400 on which one embodiment of the invention can be implemented. The computer system 400 includes a bus 402 or other communication mechanism for communicating information, and a hardware processor 404 coupled to the bus 402 for processing information. The hardware processor 404 may be, for example, a general purpose microprocessor.

The computer system 400 also includes a main memory 406, such as a random access memory (RAM) or other dynamic storage device, coupled to the bus 402 to store information and instructions to be executed by the processor 404. The memory The main 406 may also be used to store temporary variables or other intermediate information during the execution of instructions to be executed by the processor 404. Such instructions, when stored in a non-transient storage medium accessible to the processor 404, convert to the system Computation 400 on a special lens machine that is adapted / customized to perform the operations specified in the instructions.

The computer system 400 additionally includes a read-only memory (ROM) 408 or other static storage device coupled to the bus 402 for storing static information and instructions for the processor 404. A storage device 410, such as a magnetic disk or a optical disk, is provided and coupled to the bus 402 to store information and instructions.

The computer system 400 may be coupled via bus 402 to a player 412, such as a cathode ray tube (CRT), to display information to a computer user. An input device 414, including alphanumeric keys and others, is coupled to the bus 402 to communicate information and command selections to the processor 404. Another type of user input device is the cursor control 416, such as a mouse, a wheel offset or cursor address keys to communicate address information and command selections to the processor 404 and to control the movement of the cursor in the player 412. This input device typically has two degrees of freedom on two axes, a first axis (for example, example, x) and a second axis (for example, y), which allows the device to specify positions in a plane.

The computer system 400 can implement the techniques described herein using a custom hard wiring system, one or more ASICs or FPGAs, firmware and / or logic program which in combination with the computer system makes or programs the computer system 400 to make it a special purpose machine. According to one embodiment, the techniques in this document are carried out by the computer system 400 in response to the processor 404 executing one or more sequences of one or more instructions contained in the main memory 406. Such instructions can be read in the main memory 406 from another storage means, such as the storage device 410. The execution of the instruction sequences contained in the main memory 406 causes the processor 404 to perform the process steps described in this document. In alternative modes, a hard wiring circuit system may be used in place of or in combination with software instructions.

The term "storage medium" as used herein refers to any non-transient medium that stores data and / or instructions that cause a machine to operate in a specific manner. Such a storage medium may comprise non-volatile media and / or volatile media. Non-volatile media include, for example, optical or magnetic disks, such as storage device 410. Volatile media includes dynamic memory, such as the main memory 406. Common forms of storage media include, for example, floppy disk, floppy disk, hard disk, solid state drive, magnetic tape or any other magnetic data storage medium, a CD-ROM, any other means of storing optical data, any physical media with hole patterns, a RAM, a PROM Programmable Read Only Memory and a Erasable Programmable Read Only Memory EPROM, a flash-EPROM, non-volatile random access memory NVRAM, any other memory chip or cartridge.

The storage means are different from but can be used in conjunction with transmission means. The transmission means participate in transferring information between storage media. For example, the transmission means include coaxial cables, copper wire and optical fiber, including the cables comprising the bus 402. The transmission means may also take the form of acoustic waves or light waves, such as those generated during the radio wave data communications and infra-red data communications.

Various forms of means may be involved in carrying one or more sequences of one or more instructions to the processor 404 for execution. For example, the instructions can initially be carried on a magnetic disk or in a solid-state drive of a remote computer. The remote computer can load the instructions into its dynamic memory and send the instructions through a telephone line using a modem. A local modem to a computer system 400 can receive the data on the telephone line and use an infra-red transmitter to convert the data to an infra-red signal. An infra-red detector can receive the sent data carried in the infra-red signal and an appropriate circuit system can place the data in the bus 402. The bus 402 carries the data to the main memory 406, of which the processor 404 retrieve and execute the instructions. The instructions received by the main memory 406 can optionally be stored in the storage device 410 either before or after the execution by the processor 404.

The computer system 400 also includes a communication interface 418 coupled to the bus 402. The communication interface 418 provides a two-way data communication coupled to a network link 420 that is connected to a local network 422. For example, the communication interface 418 can be an integrated services digital network (ISDN) card, a cable modem, a satellite modem, or a modem to provide a data communication connection to a corresponding type of telephone line. As another example, the communication interface 418 may be a local area network (LAN) card to provide a data communication connection to a compatible LAN. Wireless links can also be implemented. In said implementation, the communication interface 418 sends and receives electrical, electromagnetic or optical signals carrying digital data streams representing various types of information.

The network link 420 typically provides data communication through one or more networks to other data devices. For example, the network link 420 can provide a connection through the local network 422 to a host computer / central computer 424 or to a data equipment operated by an Internet Service Provider (ISP) 426. ISP 426 in turn provides data communication services through the global data packet communication network now commonly referred to as the "Internet". 428. Local network 422 and Internet 428 both use electrical, electromagnetic or optical signals carrying digital data streams. The signals through the various networks and the signals on the network link 420 and through the communication interface 418, which carries the digital data to and from the computer system 400, are exemplary forms of media transmission.

The computer system 400 can send messages and receive data, including program code, through the network (s), network link 420 and communication interface 418. In the Internet example, a server 430 can transmit a requested code for an Internet application program 428, ISP 426, local network 422 and communication interface 418.

The received code can be executed by the processor 404 as received, and / or stored in the storage device 410, or other non-volatile storage for later execution.

In the foregoing specification, the embodiments of the invention have been described with reference to numerous specific details that may vary from implementation to implementation. The specification and figures must, therefore, be viewed in an illustrative rather than a restrictive sense. The only and specific indicator of the scope of the invention, and what is the intention of the applicants that is the scope of the invention, is the literal and equivalent scope of the set of claims that emanate from this application, in the specific form in the which said claims emanate, including any subsequent correction.

Claims (35)

1. A method comprising: The data storage that associates a plurality of devices, including a first device and one or more recipient devices; receiving, from a first device of the plurality of devices, through a network, an indication that a file that is stored in the first device has to be sent to one or more devices; in response to having received the indication, causing the file to be stored in persistent storage that is remote from all the plurality of devices; causing the file to be sent to the given device; and in response to the course of a particular period of time, making the file inaccessible to any device of the plurality of devices without taking into account whether a recipient device, of the recipient or devices, received the file; where the method is carried out by one or more computing devices.

2. The method of Claim 1, wherein: While the file is newly stored in the first device, a particular type of communication is not established between the first device and the server; and the indication is sent from the first device to the server automatically in response to an establishment of the particular type of communication.

3. The method of Claim 1, wherein: the indication does not include the file; making the file be stored comprises sending, to the first device, the first storage location data indicating where the first device is to send the file; making the file sent to the given device comprises sending the second storage location data indicating where the given device is to retrieve the file.

4. The method of Claim 1, wherein the file that is sent to the given device is a copy of the file or a version of the file that is in a different form than the file that is stored in the first device.

5. The method of Claim 1, further comprising: storing secondary data associating a second plurality of devices; receiving, from a particular device of the second plurality of devices, through the network, a second indication that a second file, which is different from the first file and that was not previously stored in any of the second plurality of devices, is stored in the particular device; in response to having received the second indication, causing the second file to be stored in a persistent storage that is remote from the entire second plurality of devices; in response to having detected that some given device of the second plurality of devices, other than the second device, establishes a connection to the server, causing the second file to be sent to the given device; Y in response to the course of a second period of time that is different from the particular time period, making the second file inaccessible to any device of the second plurality of devices without taking into account whether any device, of the second plurality of devices that not the particular device, received the second file.

6. The method of claim 1, wherein the particular time period is determined based on one or more of the file type, the device that sent the indication, data included in the indication, when the indication was sent, when the file was created, or an identity of who created the file.

7. The method of Claim 1, wherein the plurality of devices are associated with the same user account.

8. The method of claim 1, further comprising, after causing the file to be sent to one or more devices of the plurality of devices: modifying the data association to indicate that a particular device is associated with the plurality of devices, where the plurality of devices does not include the particular device; Y causing the file to be sent to the particular device.

9. The method of claim 1 in which an activity is triggered in response to having detected that some given device of the plurality of devices, other than the first device, establishes a connection to a server that caused the file to be stored in the persistent storage.

10. A method comprising: Storage association data associating recipient devices with an attribute; receiving, from a source device, through a network, (a) an indication that a file that is stored in the first device is to be sent to another or other devices and (b) attribution data that identifies an attribute of the archive; Y in response to having received the indication and attribution data: identify the association data based on the indication and the attribution data, identifying, on the basis of the association data, a second device of the plurality of devices that is different from the first device, and causing the file to be sent to the second device; wherein the method is carried out by one or more computing devices.

11. The method of Claim 10, wherein the attribute is one of a file type, a file size, a file creator, a file format, or an attribute of the file content.

12. The method of Claim 10, wherein the file is a digital image and the attribute is an identification of an object that is detected in the digital image.

13. The method of Claim 12, wherein the object is a face of a person.

14. The method of Claim 10, wherein making the file sent to the second device comprises sending the file to the second device.

15. The method of Claim 10, wherein making the file sent to the second device comprises: Send, to the first device, the first storage location data indicating where, through the network, the first device has to send the file; Y Send, to the second device, the second storage location data indicating where, through the network, the second device has to retrieve the file.

16. A method comprising: store data associating a plurality of devices; receiving, from a first device of the plurality of devices, through the network, an indication that a file that is stored in the first device has to be sent to another or other devices; in response to having received the indication, for each other device of the plurality of devices: determining, based on one or more criteria, a version among a plurality of versions of the file; Y originating the version to be sent to each of said devices; where the method is carried out by one or more computing devices.

17. The method of Claim 16, wherein the first device creates one or more versions of the plurality of versions.

18. The method of Claim 16, wherein: the plurality of devices includes a second device and a third device that are different from the first device; The determination includes: determining, for the second device, a first version among the plurality of versions, and determine, for the third device, a second version among the plurality of versions, where the second version is different from the first version; and this includes: make the first version be sent to the second device, and make the second version be sent to the third device.

19. The method of Claim 18, wherein the first version of the file is in a first format and the second version of the file is in a second format that is different from the first format.

20. The method of Claim 18, wherein: the file is a digital image; Y the first version of the digital image is in a first resolution and the second version of the digital image is in a second resolution that is different from the first resolution.

21. The method of Claim 16, wherein making the version sent includes sending the version to said other device.

22. The method of Claim 16, wherein to make the version to be sent comprises: send, to the first device, the first storage location data indicating where, through the network, the first device has to send the version; and sending, to said each other device, the second storage location data indicating where, through the network, said each other device has to retrieve the version.

23. A method that includes: storing association data associating a first device with another or other devices including a second device that continuously reproduces a display of images of a plurality of digital images; receiving, from a first device of a plurality of devices, through a network, an indication that a digital image that is stored in the first device has to be sent to another or other devices; Y in response to having received the indication: identify, on the basis of said association data, the second device, and make the digital image be sent to the second device while the second device reproduces the presentation of images, where the second device includes the digital image in the presentation of images in response to having received the digital image; where the method is carried out by one or more computing devices.

24. The method of Claim 23, wherein: receiving the indication comprises receiving the digital image; and causing the digital image to be sent comprises sending the digital image to the second device.

25. The method of Claim 23, wherein making the digital image sent to the second device comprises; send, to the first device, the first storage location data indicating where, through the network, the first device has to send the digital image; and sending to the second device, the second storage location data indicating where, through the network, the second device has to retrieve the digital image.

26. A method comprising: storing, by a particular entity, association data associating a plurality of devices; receiving, by the particular entity, from a first device of the plurality of devices, through a network, an indication that a file that is stored in the first device is to be sent to another or other devices; in response to having received the indication, send, by the particular entity, to the first device, the first location data, where the first device uses the first location data to send the file to a second entity that is different from the particular entity and that it stores the file in response to having received the file from the first device; based on the association data, the particular identity that identifies, from the plurality of devices, a second device that is different from the first device; Y sending, by the particular entity, to the second device, through the network, the second location data, where the second device uses the second location data to request the file of the second entity that sends the file to the second device in response to having received a request for the second device; where the method is carried out by one or more computing devices.

27. The method of Claim 26, wherein the first location data (a) includes identification data identifying the file and (b) is associated with the second entity.

28. The method of Claim 26, wherein sending the second location data is carried out in response to the particular entity having received, from the second device, a request for information about one or more files.

29. The method of Claim 28 additionally comprises sending to the second device a notification after having identified the second device, where the second device sends the request for information on one or more files in response to receiving the notification.

30. The method of Claim 26, wherein: while the particular entity identifies the second device, the second device is in a first state where the second device can not communicate with the particular entity; at the time that the particular entity sends the second location data to the second device, the second device is in a second state where the second device can communicate with the particular entity.

31. One or more storage means storing instructions which, when executed by one or more processors, causes the method described in Claim 1 to be carried out.

32. One or more storage means storing instructions which, when executed by one or more processors, causes the method described in Claim 10 to be carried out.

33. One or more storage means storing instructions which, when executed by one or more processors, causes the method described in Claim 16 to be carried out.

34. One or more storage means storing instructions which, when executed by one or more processors, causes the method described in Claim 23 to be carried out.

35. One or more storage means storing instructions which, when executed by one or more processors, causes the method described in Claim 26 to be carried out.