Patent Application
20080034009
I. Vocabulary and Non-Limitation
Throughout this disclosure, we shall use certain vocabulary to discuss synchronization techniques and examples. Most of the illustrations discussed will relate to PIM data and the synchronization of same. However, many embodiments of the invention are expressly intended to apply to virtually any kind of data. Some examples of data that may be synchronized using the techniques taught herein are the following: text files; word processing files; files from a file system, media files such as jpegs, mp3, mpeg2, mpeg4, or wav files; records from a database; favorites lists; preferences settings, or any other data file type or data that may comprise a file or object, whether or not associated with a specific applications. Therefore, in discussing synchronization services, we are at least referring to services that would apply to application software suite sold by Apple Computer. Some examples of that software include, without limitation, Dashboard, Safari, iChat AV, Mail, iCal, iPhoto, iWeb, iMovie HD, iDVD, Garageband, Keynote, and Pages.
Retreating then to the language of most of our illustrative embodiments, we shall primarily discuss the invention in terms of PIM data. Generally, we shall discuss devices such as computers, PDAs, phones or other intelligent devices that are used to access PIM data. Each device is generally associated with a Sync-Server and a sync client, which are each usually one or more processes resident on the device. In some instances, a first device will have a sync client resident on another device (this is called a proxy). This may be because the first device is not sufficiently equipped to host a sync client. Alternatively, in a multi-peer system, the synchronization system may use a local proxy for each other peer in order to synchronize all peers even when many peers are not present (the proxy stands in for the missing devices). These proxies are also simply known as sync clients to the Sync Server.
PIM data itself generally occurs as personal contacts, calendar entries, notes, journal entries, etc. When we discuss a record, we are generally referring to a set of data items that have been associated. For example, a personal contact card for John Doe may be viewed as a record wherein a phone number, street address, pager number and a variety of other data items are interrelated by their common association with John Doe. Each record present for a Sync Server or client may have a corresponding record on other Sync Servers or clients. For example, there may be a contact record for Jon Doe on each of Jane Doe's phone, desktop computer and portable computer. Likewise, each item of PIM data on a single device may have one or more corresponding data items on one or more other devices. For example, Jon Doe's street address may have corresponding data items on each of Jane Doe's desktop computer, portable computer, PDA, and telephone. Likewise, if our data were digital photographs, a picture of Jon Doe on the desktop may have corresponding pictures of Jon on the PDA, the portable computer and elsewhere. It is an overall job of the synchronization function to provide a common view (as much as possible) of corresponding data across many devices. In many embodiments, the common view comprises analogous or corresponding records as well as analogous or corresponding properties within those records.
II. Sample Hardware and Software Structures
While the techniques described herein may be embodied in virtually any structural context, we shall describe some example structural embodiments for illustrative purposes. Referring to
Referring now to
Transitioning from sample hardware, we shall now discuss general software background. In particular, referring to
With those caveats, we see in
Referring again to
III. An Example of a Four Peer System
a. A Sample Software Stack and Group of Synching Peers
Referring to
Referring further to
The Sync-Server and client processes work together to service the synchronization needs of the client device. In some embodiments, the work can be modeled by assuming that the client process represents the client device to the Sync Server. Thus, in many embodiments, the client process is responsible for interaction with the client device and serves as intermediary for the device with the Sync Server. Alternatively, the Sync-Server is responsible for maintaining the accuracy of synchronization through its own techniques and the protocols it requires of the clients.
As noted earlier, the moniker “quasi-peer” was given to the exemplary cell phone quasi-peer 517 to indicate a potential difference between it and full peers. That indication is to exemplify a device type that is desirable to include in the synchronization group but that may be incompatible or incapable of running a compatible Sync-Server and client processes. In the case of such a client device, the associated software process, client Z 509, usually serves as a proxy to quasi-peer Z 517 and has more significant duties and data retention (as well known in the art) than a normal client process. Thus, for example, client Z 509 may retain data structures that represent all the relevant data for synchronizing on quasi-peer Z 517. Furthermore, client Z 509 may also be responsible for monitoring and enforcing hardware and software limitations of the device such as the number of records that fit or number and types of properties or fields allowed for a record. Obviously neither the function of client Z 509, or any other process discussed, is necessarily limited to a single program or process.
b. A Sample Synchronization
Referring now to
Referring further to
With respect to the creation of R1 and R1′, there are other interesting points to note. First, many embodiments require that a universally unique ID (UUID) is assigned to record upon the creation of the record. In the broadest sense, this is actually the Sync-Server's responsibility; however, in common embodiments where the client local ID is ultimately used by the Sync-Server as the GID datum, the responsibility falls further down to the client application where the record was created. Moreover, in the case of a quasi-peer type device as discussed earlier, the responsibility likely falls upon the proxy portion of the client process. Second, one should note that creation of a record can take many forms such as input by a user typing, by importing through software, or otherwise coming to the client device through a mechanism other than synchronization with members of the synchronization group here-discussed. Third, one should note that in some embodiments, GID datum is simply a property of a record. If the record somehow exists without a GID property field, then that field is created when it becomes desirable to incorporate GID datum in the record's properties. Fourth, one should also note that records may carry GID datum in one or more property fields. As we should discuss, the GID properties of a record may comprise multiple sets of GID datum. All of the GID datum can be combined in a single property field or each can have its own property field.
Having discussed origin and nature of a GID datum, one should also note that in
Having set that predicate, we can move to column 681 and see that our example calls for the synchronizing system A 600 with system B 620. With attention to column 680, we see that system A 600 started with a null for data, therefore column 682 shows that after synchronizing with system B 620, system A 600 has record R1, the GID property of G(B,R1), which simply comes as a property of R1. Moving then to column 683, we see our example calls for synchronizing system C 640 with system B 620. Assuming these systems have never synchronized before, they will attempt to match their records by identity key data properties. In that process they will identify that R1 and R1′ are the same record (or at least similar enough to be associated). Therefore, the records will be synchronized without creating a duplicate record and by using the domain's conflict rules for resolving any property conflicts; however, excepting the GID property, which, if residing in the same field property, is resolved by deriving a global equivalency set from the GID datum of both records. This derivation is discussed throughout in terms of combining (by accumulating, concatenating, or any other functional means) the GID datum. However, any derivation resulting in a derived global equivalency set with a value unique to the GID datum (or, in some embodiments, previous global equivalency sets) from which the global equivalency set is derived (e.g., a hash function) may also be used, are readily apparent to those of skill in the art. If GID data reside in individual record property fields, then there will be no conflict and new property field is created when a unique GID datum is added to a record. Therefore, we see in column 684 (post synchronization) that system B 620 still has R1, but that the GID properties have been updated by the synchronization so that those properties represents the GID datum set G(B,R1), G(C,R1′). Similarly, with attention to column 684, we see that post synchronization, system C 640 still has R1′ but its GID properties have been updated by the synchronization so that those properties now represent G(B,R1), G(C,R1′). Finally, having had no interaction in the synchronization, the data state of system A 600 remains unchanged.
Moving then to
Given the potential avoidance of duplicates and false adds (adding a record previously deleted), some Sync Server embodiments check GID information before checking identity key properties. Some embodiments also perform identity key property or other property analysis to determine if records are the same. Techniques for this analysis are known in the art.
c. GID Datum Tables
One potential disadvantage to the foregoing example is the use of brute force to match or search or GID datum equivalency. Thus, in many embodiments of the invention a Sync-Server maintains tables for use in GID equivalency searching. For any given type of structured data, each table may associate (e.g. in the same row) the following items: a native GID datum; all associated non-native GID datum; and a key into the local associated record. By way of explanation, the Native GID datum may be represented by the first GID that a particular Sync-Server receives for a record. Therefore, if the record is created on an application program local to the Sync-Server, the native GID datum is the GID datum assumed at the creation of the record. Alternatively, if a GID datum is first received with a new record from another system, that first received GID may be used for the native GID. As yet another alternative, for GIDs created on other systems, a Sync-Server may create a native GID, for example, represented by the GID format discussed above (i.e. G(local system identifier, record identifier)). For purpose of illustration, we shall retread the example of
Therefore, referring to
Thus, we see that at the state represented by
Moving now to column 681, that is a function calling for the synchronization of system A 600 and system B 620. The result in column 682 shows that after synchronizing with system B 620, system A 600 has record R1, and the GID property G(B,R1). The new tables corresponding with the data state at column 682 are as follows:
Thus, we see that the only change to the tables occurring due to synchronization of system A 600 with system B 620 is that system A 600 received a duplicate of the record and properties (including GID datum) in system B 620. It is noteworthy that we have chosen to use G(B,R1) as the native GID datum for system A 600. As discussed earlier there are many other alternatives that fall within the scope of the invention.
Moving then to
Thus we see that the tables for Sync-Servers B and C have been updated to show non-native associated GID datum. Since our example has only three systems and two independent creations of the same record, this example will not carry more than one non-native associated GID datum per native GID datum. However, one should note that in a more complex and/or larger system consistent with real-world use and manipulation, there may be many non-native associated GID datum per native datum. From the standpoint of the inventive concepts, there is no limit.
Moving then to
IV. The Case of Deletions
Some embodiments of the invention benefit from the GID techniques by acquiring the added ability to determine if a “new” record being pushed to a Sync-Server is actually a record that has been previously deleted. With that added knowledge, the Sync-Server can maintain a view of data that is most consistent with the user's desires. Thus, many embodiments of the invention contemplate techniques for use when deleting records.
In some embodiments, when the Sync-Server is notified of a deletion, it deletes the record and all its properties, including all its GID properties. However, the Sync-Server does retain a “tombstone” of the deleted record. The tombstone is datum that indicates the identity of the record and its disposition as deleted. In some embodiments, the tombstone datum is retained in log-type information for tracking the various client synchronizations. So, in those embodiments, the synchronization generation information will also be associated with the tombstone. In addition, upon deletion of a record, most embodiments do not immediately call for the deletion of the native-to-non-native association datum in the table discussed above. The association datum in the tables may only be deleted once the Sync-Server is certain that all know systems have deleted the record. The tombstones may be deleted at that time as well.
For purpose of illustration, we will discuss an example regarding deletions. Referring to
Moving to column 781, we see that our example requires system B 720 to delete R1′. As discussed earlier, when system B 720 deletes R1′, the Sync-Sever in system B will: (i) delete all properties of the record; maintain a tombstone as described above; and leave the related entries in the native-to-non-native GID association table. The data state of the systems is then shown in column 782 and the state of the native-to-non-native association tables will be unchanged as follows:
Moving on to column 783, the example requires that we synchronize system A 700 with system C 740. Since system A 700 has no knowledge regarding the system B deletion of the record, result column 784 shows that system A 700 pushes record R1 to system C and, of course, includes the GID properties. Therefore, we have a situation here where system C has updated its datum to incorporate a record that the user probably intended for deletion. However, using the embodiments of the invention, we shall see that the user's intent shall ultimately prevail. In any case, the state of the native-to-non-native association tables at the point of column 784 will be as follows (although for the first time in our examples, we are assuming that the Sync-Server in system B will create its own native ID for the table):
Moving now to column 785, we see that our example requires the synchronization of system B 720 with system C 740. According to our example, system B 720 and system C 740 have never seen each other before, however, due to the GID properties, the result of the synchronization will turn out in accordance with the user's desires. In particular, system C 740 will attempt to push R1 to system B, but because the GID properties of record R1 match the table entry of system B 720's native-to-non-native association table, system B is able to determine that record R1 has a corresponding datum on system B. Thus, system B can use the R1 tombstone to determine that R1 was deleted and then system B 720 can push the deletion back to system C 740. Thus, we see in result column 786 that, using the inventive embodiments, rather than system B receiving an unwanted record, an unwanted record was removed from system C. Once again the table status remains unchanged as follows:
Finally, per column 787, we can synchronize system A 700 with either of system B 720 or C 740 and get the same result, which is shown column 787. Again, rather than revive a deleted record, the delete is pushed to the system holding the obsolete record. It may be determined that all clients have synchronized the last modification of a record by analyzing the last synchronization generation associated with the client or the last modified generation associated with each record. This function may be used to determine that all regularly synching clients have knowledge of a deleted record.
The foregoing embodiments are intended as illustrative and without limitation unless expressly stated. One skilled in the art may adapt these embodiments and illustrations in a variety of ways. Such adaptation is expected and intended as part of the discussion herein.
