Patent Application
20070094334
Email services have been rapidly growing in popularity during recent years, and continue to handle ever increasing quantities of email. Such services provide users with techniques for sending email quickly and inexpensively to recipients around the world. In addition, the users of such services are often able to download their email from the service at a variety of locations, and/or using different client devices. For example, a user of an email service may check his email in the morning using a personal computer at home and then again later in the day using another computer located at the user's workplace, and then again in the evening using a mobile phone.
Although the increased flexibility and convenience provided by an email services may be appreciated by the users, the email service is faced with a difficult task of keeping multiple client devices, with which a user may access his account, synchronized (i.e., “in sync”) with the email service. For example, the email service may attempt to keep the email that the user has on his personal computer synchronized with the email that is on the email service. Additionally, the email service may also attempt to keep email on each of a variety of other client devices used by the user to access the email account synchronized with the email that is on the email service. Past efforts to achieve efficient synchronization of multiple client devices with an Internet email service have been unsatisfactory, such as through use of significant amount of client and service resources.
Email service and client synchronization is described. In one embodiment a synchronization request is received at a server from a client to synchronize the client's email account. The synchronization request includes a generation identifier (ID) that identifies a group of changes to the email account which have been processed by the client. The received generation ID is compared with a generation ID stored at the server. When the generation IDs do not match, synchronization with the client is initiated. The synchronization, for instance, may use change sequence numbers which correspond to the respective generation IDs. The change sequence numbers represent a change in state of a corresponding email in the client's email account.
This Summary is provided to introduce a selection of concepts in a simplified form that are further described below in the Detailed Description. This Summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used as an aid in determining the scope of the claimed subject matter.
The same reference numbers are utilized in instances in the discussion to reference like structures and components.
Overview
Email services have been rapidly growing in popularity during recent years, and now handle huge quantities of email. One reason for the increasing popularity of such services is convenience. For example, a user or client of an Internet email service is often able to access his account, check his email, and send and/or receive email from multiple different computers and/or other client devices. Although such email services offer increased flexibility and convenience to the user, the services are faced with the difficult task of keeping each of the multiple client devices via which a user may access his account synchronized (i.e., “in sync”) with the email service.
Internet email service and client synchronization techniques are described, in which, client devices may upload local changes and download service-side changes in an efficient manner, thereby facilitating efficient client synchronization with the email service. Furthermore, email service and client synchronization may facilitate efficient synchronization, even in cases where the client email account is to be synchronized with multiple client devices.
Aspects of the described techniques for client synchronization may be implemented in any number of different computing systems, environments, and/or configurations, embodiments of Internet email service and client synchronization are described in the context of the following exemplary system architectures. Therefore, although synchronization of email is described in the following examples, it should be apparent that these techniques are equally applicable to synchronization of other data.
In the following discussion, an exemplary environment is first described which is operable to employ synchronization techniques. Exemplary procedures are then described which may be employed in the exemplary environment, as well as in other environments.
Exemplary Environment
Additionally, although the network 104 is illustrated as the Internet, the network may assume a wide variety of configurations. For example, the network 104 may include a wide area network (WAN), a local area network (LAN), a wireless network, a public telephone network, an intranet, and so on. Further, although a single network 104 is shown, the network 104 may be configured to include multiple networks. For instance, clients 102(1), 102(N) may be communicatively coupled via a peer-to-peer network to communicate, one to another. Each of the clients 102(1), 102(N) may also be communicatively coupled to an email service provider over the Internet. A variety of other instances are also contemplated.
Each of the plurality of clients 102(1)-102(N) is illustrated as including a respective one of a plurality of communication modules 106(1), . . . , 106(N). In the illustrated implementation, each of the plurality of communication modules 106(1)-106(N) is executable on a respective one of the plurality of clients 102(1)-102(N) to send and receive email. Email employs standards and conventions for addressing and routing such that the email may be delivered across the network 104 utilizing a plurality of devices, such as routers, other computing devices (e.g., email servers), and so on. In this way, emails may be transferred within a company over an intranet, across the world using the Internet, and so on. An email, for instance, may include a header, text, and attachments, such as documents, computer-executable files, and so on. The header contains technical information about the source and oftentimes may describe the route the message took from a sender to a recipient.
The communication modules 106(1)-106(N) can communicate emails through use of an email service 108. The email service 108 includes an email manager module 110 (hereinafter “manager module”) that manages storage 112 of a plurality of email accounts 114(h), where “h” can be any integer from one to “H”. Each of the email accounts 114(h) is configured to store a plurality of emails 116(g), where “g” can be any integer from one to “G”, that are configured for communication over the network.
The email service 108, for example, may receive an email intended for the email account 114(h) of a particular user 118. The email service 108, upon receipt of the email, executes the manager module 110 to store the email in the email account 114(h) that corresponds to the particular user 118. The user 118 may then utilize one or more of the client devices 102(1)-102(N), through execution of respective communication modules 106(1)-106(N), to retrieve the email from the corresponding email account 114(h). For example, the user 118 may utilize client 102(N) to “log on” to the email service 108 (e.g., by providing a user identification and password) and retrieve emails from the email account 114(h). In a further instance, the client 102(N) pulls the email from the email provider 108 (and more particularly the manager module 110)). A variety of other instances are also contemplated.
As previously described, the client devices 102(1)-102(N) can also represent multiple different devices via which the user 118 may access a corresponding email account 114(h) at the email service 108. For example, client device 102(1) can be the user's 118 personal computer located at the user's home and client device 102(N) can be the user's 118 mobile phone. Therefore, client device 102(1) may include a plurality of email 120(e) (where “e” can be any integer from one to “E”) and client 102(N) may also include a plurality of email 122(f), where “f” can be any integer from one to “F”. Thus, each client device 102(1)-102(N) may include different respective emails 120(e), 122(f) due to different respective synchronization states with the email 116(g) of the email service 108.
For example, the user 118 may have various emails 116(g) which have been received at his email account 114(h) and may continue to receive additional emails at his email account 114(h) throughout the day. In the morning, for instance, the user 118 may decide to download his email 116(g) from the internet email service 108 to his personal computer (e.g., client 102(1)) at home before leaving for work, which may correspond to email 120(e). Later in the day, the user 118 may check the email account 114(h) from another client 102(N) located at the user's workplace. In another example, the user 118 may have synchronized today with one client 102(1), but may have not synchronized for several days with another client 102(N). In each of these examples, since different clients 102(1)-102(N) have been used to access the email account 114(h) at different times, one or more of the different clients 102(1)-102(N) can have different synchronization states, e.g., the clients 102(1)-102(N) do not have the same emails stored locally.
To synchronize the clients 102(1)-102(N) with the email service 108, the clients 102(1)-102(N) and/or the email service 108 may utilize respective synchronization modules 124(1)-124(N), 126. The synchronization modules 124(1)-124(N), 126 are executable to track each time the user 118 makes a change to a state of an email (e.g., when a new email is received by the client's email account, when one of the respective email is read, or when one of the respective email is moved) and for tracking the synchronization state of each of the different clients 102(1)-102(N). As described in further detail below, this tracking facilitates efficient synchronization on a large scale between multiple clients 102(1)-102(N) and the email service 108.
Generally, any of the functions described herein can be implemented using software, firmware, fixed logic circuitry, manual processing, or a combination of these implementations. The terms “module,” “functionality,” and “logic” as used herein generally represent software, firmware, or a combination of software and firmware. In the case of a software implementation, the module, functionality, or logic represents program code that performs specified tasks when executed on a processor (e.g., CPU or CPUs). The program code can be stored in one or more computer readable memory devices, further description of which may be found in relation to
Additionally, although a single memory 206(s), 210(1)-210(N) is shown for the respective servers 202(s) and clients 102(1)-102(N), the memories 206(s), 210(1)-210(N) may represent a wide variety of types and combinations of memory devices, such as random access memory (RAM), hard disk memory, removable medium memory, and other computer-readable media.
The manager module 110 and the synchronization module 126 are illustrated as being executed on the processor 204(s) and are also storable in memory 206(s). The synchronization module 126 is representative of functionality that is employable by the manager module 110 to synchronize emails 116(g) in the email accounts 114(h) with clients 102(1)-102(N) over the network. For example, the synchronization module 126, when executed, may maintain a plurality of generation IDs 212(x) and change sequence numbers 214(y), where “x” and “y” can be any integer from one to “X” and “Y”, respectively. The change sequence numbers 214(y) are utilized to represent changes to a state of the email 116(g) in the email account 114(h), such as deletion, addition, movement from one folder to another, and so on.
The generation IDs 212(x) may be configured as monotonically increasing integers used to mark a current synchronization position in order to detect a recovery synchronization scenario. After the email service 108 (and more particularly the manager module 110) successfully processes a synchronization request between the client 102(1) and the corresponding email account 114(h), for instance, the stored generation ID 212(x) is incremented and sent back to the client 102(1). If in a subsequent synchronization request, the client 102(1) still sends the previous generation ID, then the email service 108 “knows” that the client 102(1) failed to receive the synchronization response with the updated generation ID. Recovery synchronization may then be performed. Further discussion of the generation ID 212(x) may be found in relation to the exemplary procedures section that follows.
Exemplary Procedures
The following discussion describes synchronization techniques that may be implemented utilizing the previously described systems and devices. Aspects of each of the procedures may be implemented in hardware, firmware, or software, or a combination thereof. The procedures are shown as a set of blocks that specify operations performed by one or more devices and are not necessarily limited to the orders shown for performing the operations by the respective blocks. Thus, the order in which the procedures are described is not intended to be construed as a limitation, and any number of the described blocks can be combined in any order to implement the procedures. Furthermore, the procedures may be implemented in any suitable hardware, software, firmware, or combination thereof. In portions of the following discussion, reference will be made to the environment 100 of
The generation ID received from the client is compared to a generation ID stored at the server (decision block 306). For example, the generation ID received from client 102(1) is compared to a generation ID 212(x) stored at the server 202(s) to determine whether the generation ID received from the client 102(1) matches the generation ID for that client stored at the server 202(s). The server 202(s), for instance, may store generation IDs that are specific for each client that is to synchronize with the server such that a first client may have a first generation ID which maps to a particular change number while another generation ID may map to another change number. Further discussion of multi-client synchronization may be found in relation to
When the generation IDs do not match (“no” from decision block 306), synchronization is initiated with the client (block 308). The synchronization uses change sequence numbers which correspond to the respective generation IDs. Each of the change sequence numbers represents a change in state of a corresponding email in the client's email account.
The generation ID stored at the server is also incremented (block 310). For example, the generation ID 212(x) stored at the server 202(s) can be incremented. The incremented generation ID is communicated to the client as part of a synchronization key to mark an updated synchronization state for the client 102(1) (block 312). For example, the incremented generation ID can be communicated from the server 202(s) to the client 102(1) as part of a synchronization key to mark an updated synchronization state for the client 102(1).
A subsequent synchronization request is then received at the server 202(s) from the client 102(1) to synchronize the client's email account (block 314). The subsequent synchronization request includes a generation ID. For example, a subsequent synchronization request can be received at the server 202(s) from the client 102(1) over the network 104 to synchronize the client's email account 114(h). The subsequent synchronization request includes a generation ID.
The generation ID received from the client is then compared to the incremented generation ID stored at the server (decision block 316). For example, the generation ID received from the client 102(1) can be compared to the incremented generation ID stored at the server 202(s) to determine whether the generation ID received from the client 102(1) matches the incremented generation ID.
When the generation IDs match (“yes” from decision block 316), the matching of the generation ID received from the client with the incremented generation ID stored at the server confirms that the client has previously successfully synchronized with the client's email account (block 318). For example, when the generation ID received from the client 102(1) matches the incremented generation ID stored at the server 202(s), the matching confirms that the client 102(1) has previously successfully synchronized with the client's email account 114(h).
When the generation IDs do not match (“no” from decision block 316), a non-matching of the generation ID received from the client with the incremented generation ID stored at the server confirms that the client has not previously successfully synchronized with the client's email account (block 320). Thus, the email service 108 is “made aware” of the synchronization state of the client, and may perform appropriate actions. For example, the procedure 300 may return to block 308 to retry the synchronization process.
A temporary object identifier (ID) which identifies the new object is generated at the client (block 406). The temporary object ID is then communicated from the client to the server (block 408). For example, the temporary object ID can be communicated from the client 102(1) to the server 202(s) which is used by the client 102(1) to identify the locally composed email.
A permanent object identifier (ID) is then generated at the server to replace the temporary object ID (block 410). For example, a permanent object identifier (ID) can be generated at the server 202(s) to replace the temporary object ID used and communicated by the client. The permanent object ID is communicated from the server to the client (block 412). For example, the permanent object ID can be communicated from the server 202(s) to the client 102(1) such that the permanent object ID may be utilized by the client 102(1) when referencing the composed email. Again, although email has been described, a wide variety of electronically-stored objects may be synchronized utilizing these techniques.
The generation ID received from the client is then compared to one or more of a plurality of generation IDs stores at the server (decision block 506). For example, the generation ID received can be compared to one or more of a plurality of generation IDs stored at the server 202(s). At least one of the stored generation IDs represents a group of changes that was most recently communicated to the client, and another of the stored generation IDs represents a group of changes confirmed to have been most recently processed by the client, which was confirmed by reception from the client of the corresponding generation ID at sometime in the past. Each of the changes in a group relates to a change in state of an email in an email account that corresponds to the client.
When the generation ID received from the client matches at least one of the stored generation IDs (“yes” from decision block 506), a communication that references the group of changes that correspond to the at least one said stored generation ID is formed (block 508). Thus, receipt of a generation ID confirms which changes the client has processed and identifies a group of changes the client has received. The server may then form a communication that contains the change that the client has not received. These may include changes corresponding to later generation IDs and new changes that do not yet have a generation ID.
During the matching, the generation ID received from the client is also compared to the stored generation ID that represents a group of changes that was most recently communicated to the client (decision block 510). For example, the generation ID received from the client 102(1) can be compared to the stored generation ID that represents a group of changes that was most recently communicated to the client 102(1).
When the generation ID received from the client matches the at least one stored generation ID that represents the group of changes that was most recently communicated to the client (“yes” from decision block 510), it is determined that the group of changes that was most recently communicated to the client was successfully processed by the client (block 512). Thus, the synchronization state of the client matches the synchronization state “expected” by the email service.
When the generation ID received from the client does not match the at least one stored generation ID that represents the group of changes that was most recently communicated to the client (“no” from decision block 510), it is determined that the group of changes that was most recently communicated to the client was not successfully processed by the client. Therefore, a recovery scenario may be performed, such as by resending the changes as well as the newer changes to the client.
A next change number is then created (block 606) for subsequent changes. In one implementation, the next change number can be monotonically incremented each time there is a change and applies to objects in all the collections within an email account 114(h). For example, if fifty changes were to happen in rapid succession, there will be a different monotonically incremented change sequence number assigned to the email 116(g) associated with the email account 114(h) for each of the fifty changes. It should be apparent however, that a variety of techniques may be employed to track changes. For example, different sets of sequence numbers may be employed for different parts of an email account, e.g., one for an inbox and another for all other folders, a sequence number for calendar items, and so on. Tracking the next change number allows the Internet email service 108 to conveniently assign change sequence numbers to any new changes.
A determination is then made as to whether a change has occurred (decision block 608). For example, it is determined whether a new email 116(g) is received by the client's email account 114(h), whether one of the respective email 114(h) is read, whether one of the respective email 114(h) is moved, and so on.
When it is determined that a change has occurred (“yes” from decision block 608), then the next change sequence number (706 of
In an implementation, the change sequence number 706 assigned to an email 704 can be an integer that is monotonically increased each time there is a change. For example, the change sequence numbers can be consecutive integers such as 3, 4, and 5 (as shown), can be non-consecutive integers like 1, 3, and 6, and so on. In either case, the integer for a particular email 704 is increased each time there is a change. Therefore, when comparing two change sequence numbers 706 in this instance, the larger change sequence number 706 represents the change which happened more recently. In an implementation, these change sequence numbers 706 are stored in the memory 206(s) of the server 202(s), and the clients 102(1)-102(N) will not see the change sequence numbers 706. Instead, the clients 102(1)-102(N) will see a generation ID number that is sent back to the client as part of a synchronization key. The emails and corresponding change sequence numbers described in relation to table 702, are further described below with reference to flow diagram 714.
Reference numeral 716 points to a first box of the flow diagram 714. This first box 716 of the flow diagram 714 shows an initial synchronization position of two clients 718, shown here as “client A” 720 and “client B” 722. In the illustrated example, three different numbers are associated with each of the two clients 718. These three numbers include: a generation ID number 724 (which is stored at server), a last sent change sequence number 726, and a last confirmed change sequence number 728. The last sent change sequence number 726 and the last confirmed change sequence number 728 are change sequence numbers 706 that have been assigned to a particular email 704, and the generation identifier (ID) 724 is a number with can be used by the Internet email service 108 to track the synchronization state of a client (e.g., “client A” 720 or “client B” 722).
In this example, the user's email account 114(h) at the email service 108 has three emails (i.e., emails X, Y, and Z), and both clients 718 are synchronized with the user's email account 114(h). In other words, there are three emails (i.e., X, Y and Z) and both of the clients 718 (i.e., “client A” 720 and “client B” 722) have all three email. In the present example, both of the clients 718 are on generation ID=2, and further, the last time the clients 718 synchronized with the email service 108, the email service 108 sent both of the clients 718 the first group of emails 708 (which includes emails X, Y, and Z). In other words, the clients 718 were sent emails 708 with corresponding change sequence number 706 up to five (i.e., emails X=3, Y=5, and Z=5). Therefore, both of the clients 718 have seen up to change sequence number five. In addition, the last time the clients 718 synchronized with the email service 108, the email service 108 sent both of the clients 718 a synchronization key that included generation ID=2.
It should be noted that although the Internet email service 108 knows that it sent the first group of emails 708 with corresponding change sequence numbers 706 up to five (i.e., emails X=3, Y=5, and Z=5) to both of the clients 718, at this point, the email service 108 does not know if the clients 718 received these emails 708.
Therefore, the next time the clients 718 synchronize, if the previous synchronization was successful and the clients 718 received everything up to change sequence number five, then the clients 718 will send the email service 108 the same generation ID that was sent them during the last synchronization. In the present example, the clients 718 will send a generation ID=2 to the email service 108 in the next synchronization request if the previous synchronization was successfully performed by the client. The receipt of this generation ID in the next request provides the email service 108 with confirmation that the clients 718 are “up-to-date” through change sequence number five.
As shown in block 730, now that the email service 108 has confirmation that the clients 718 are up-to-date, the last confirmed change sequence number is column is made a “5”. Continuing with the example, two more email 710 (i.e., email “email A” and “email B”) are received by the email service 108, and therefore “email A” is assigned a “change sequence number=6”, and that “email B” is assigned a “change sequence number=7”. The email service 108 then receives a synchronization request from the clients 718, and in response sends the two new email pieces 710 (i.e., “email A” which corresponds to change sequence number 6 and “email B” which corresponds to change sequence number 7) to the clients 718. At this point, the last sent change sequence number is set at 7, and the generation ID number is incremented to 3. The response which is sent to the clients 718 will include the emails (e.g., email A and email B) and the synchronization key will include generation ID=3. However, as before, when the email service 108 sends the changes to the clients 718, the email service 108 does not receive any confirmation that the clients 718 actually received the changes.
The next time the clients 718 synchronize, when the previous synchronization was successful and the clients 718 are synchronized through change sequence number=7, then the clients 718 send the email service 108 the same generation ID that was sent in the response. In the present example, the clients 718 will send the email service 108 a generation ID=3 in the next synchronization request when the previous synchronization was successful. This provides confirmation to the email service 108, that the clients 718 are “up-to-date” through change sequence number=7.
As shown in block 732, now that the email service 108 has confirmation that the clients 718 are up-to-date through change sequence number=7, the last confirmed change sequence number column is set at “7”.
Continuing with the present example, two more pieces of email 712 (i.e., “email C” and “email D”) are received by the email system 108. As described previously, “email C” is assigned a change sequence number=8, and “email D” is assigned a change sequence number=9. Again, the clients 718 send a synchronization request to the email service 108, and that in response to the synchronization request, the email service 108 sends the clients 718 the new changes 712 (i.e., the two new email pieces with corresponding change sequence numbers of C=8 and D=9). Now the last sent change sequence number is set at 9, and the generation ID number is incremented to 4. Therefore, the response which is sent from the email service 108 to the clients 718, will include “email C” and “email D”, and the synchronization key will include generation ID number=4. However, as before, when the email service 108 sends the changes 712 to the clients 718, the email service 108 does not immediately receive a confirmation that the clients 718 actually received the changes. In the present example, assume that for some reason, “email D” failed to be transmitted to the client via the network, and so the client 718 has not received “email D”.
In such a situation, when the client 718 sends another synchronization request to the email service 108, the synchronization request will include generation ID=3 (the request will not include generation ID=4). The email service 108 will recognize that the client 718 sent the previous generation ID number 3, thereby indicating that the client 718 did not receive the previously transmitted changes 712.
In response to the synchronization request, the email service 108 will send the clients 718 “email C” and “email D”. This is a recovery synchronization that allows the email service 108 to handle the failure of the earlier transmission.
If the client 718 sends the email service 108 the expected generation ID (e.g., generation ID=4) or the previous generation ID (e.g., generation ID=3), the server 202(s) will handle the synchronization request. However, if the client 718 sends the email service 108 an erroneous generation ID (e.g., “generation ID=1”), the email service 108 will advise the client 718 that the synchronization request is invalid, and will direct the client 718 to restart synchronization from scratch.
Although embodiments of Internet email service client synchronization have been described in language specific to structural features and/or methods, it is to be understood that the subject of the appended claims is not necessarily limited to the specific features or methods described. Rather, the specific features and methods are disclosed as exemplary implementations of Internet email service client synchronization.
