Synchronization is a function that provides or maintains consistent copies of data between applications, computers, and devices. For example, a desktop computer may have desktop data sets regarding personal information management (“PIM”). A user of that desktop computer may desire to use that PIM data when she is away from her desktop computer. Therefore, she may desire access to the PIM data while using a laptop computer or a personal digital assistant (“PDA”) such as a phone or other device like a miniature device. In order to accommodate that desire, her laptop computer and PDA may each carry PIM data sets that correspond to the PIM data sets on the desktop computer. The role of the synchronization function is to give the user a common view of her data on each device. This role is generally accomplished by synchronization events when two or more of the devices synchronize.
A common technique for synchronizing devices is by using snapshots of data at a point in time and comparing current data to the snapshot to determine what has changed. For illustration purposes,
Typical synchronization occurs by comparing each of desktop database 101, portable database 111, and PDA database 121 with snapshot database 102. Items in respective databases are identified as corresponding if those items share common identity data, which is typically a name in a PIM database, but may be any data property. During the compare operation, corresponding items are compared and the synchronization system assembles a list of data items that are new or changed in the active databases 101, 111, and 121 as compared to database 102. Finally, to finish out the synchronization, the list of new and changed data may be used to update all four databases 101, 102, 111, and 121.
In the described prior art synchronization process between three or more systems, the change of identity data on a record of one of the databases can be problematic. For example, assume a PIM database where the name property is used for identity data. Further, and referring to
Another problem that occurs when three or more synchronizing systems synchronize is known as the deletion problem. Referring again to
Yet another similar problem further illustrates issues in the prior art. For example, assume the devices of
Background art and other techniques related to synchronization may be found in the following U.S. patents and copending patent applications, all of which are incorporated herein by reference: U.S. Pat. No. 5,710,922 “Method for synchronizing and archiving information between computer systems”; “A Method of Synchronising Between Three or More Devices” by Toby Paterson and Jerome Lebel, Ser. No. 10/853,306 filed May 24, 2004, now patent publication no. 2006/0031857; “A Method of Synchronising” by Toby Paterson and Jerome Lebel, Ser. No. 10/852,026 filed May 24, 2004, now patent publication no. 2004/0214926; “State Based Synchronization,” by Bertrand Serlet, Ser. No. 10/883,541, filed Jul. 1, 2004, now patent publication no. 2006/0069809; and “Apparatus and Method For Peer-To-Peer N-Way Synchronization In A Decentralized Environment,” by Joe Holt, Ser. No. 11/157,647, filed Jun. 21, 2005. In view of the discussion herein as well as the other problems existing in the prior art, certain embodiments of the invention propose a synchronization system that provides for the identification of truly corresponding records and thus resolves the problems discussed above.
The embodiments described herein relate to the use of a global equivalency identification datum or set of datum (hereinafter “GID”) as an aid to synchronization systems and methods. In a very simple embodiment, the synchronization problems discussed above are solved by associating a universally unique identification datum (hereinafter “UUID”) with each independently created associated data set (e.g. structured data record). For example, in a specific embodiment relating to PIM data, upon creating a record for Joe Doe in a first peer device, the record is assigned a GID, which for purposes of this example we shall call GID1. If an analogous record for the same Joe Doe is created on a second peer device, that record is also assigned a GID, which for purposes of this example, we shall call GID2. Further, since many embodiments use a UUID as a GID, the GID1 is certainly unique or different from the GID2. If in our example, the name property is the identity key, then upon synchronizing the first peer and the second peer, the two independently created Joe Doe records will be associated as corresponding records of the “same” data set. Finally, according to some embodiments of the invention, as a result of such synchronization, the GIDs of both Joe Doe records will become a Global Equivalency Set (“GES”) comprised of GID1 and GID2.
A more complex embodiment may contemplate the software elements in a typical synchronization system and the interaction between those elements. For example, in some embodiments, a synchronization server (“Sync-Sever”) software element may be responsible for maintaining synchronization for a plurality of clients; some clients potentially being software elements (e.g. a contact manager program), other clients potentially being devices such as phones or PDAs. Each client represents a vehicle for any one or more of the following: viewing records or portions thereof; editing records or portions thereof; adding records or portions thereof; and deleting records or portions thereof. Furthermore, for the sake of clarity and without limitation, we are generally discussing records as a set of associated properties. For example, a contact record may contain properties or fields such as name, address and phone number. Such a contact may also contain metadata fields such as date of last edit, identity of creator client or the GID datum itself may be carried as a property to a record.
In many embodiments, new records are created by clients, and the creator client assigns a local ID datum to the record. When that creator client synchronizes with the Sync-Server, the new record is pushed to the Sync-Server as a new record. Since the Sync-Server cannot be certain that the record is truly new, the Sync-Server will embark upon a process to verify the newness of the record. It is important to realize that while the creator client believes the new record is indeed new, it may not actually be truly new. This is because, the Sync-Server may already know about a corresponding record that was either (i) independently created by another client (e.g. the same contact information independently entered into two different peers of the relevant group of syncing systems); or (ii) originally a duplicate of the creator clients new record that somewhere in the peer system lost its ability to be readily identified as such (through user and/or system manipulations or anomalies).
In some embodiments, verification of the record's newness involves assuming that the local ID is a GID and comparing that datum to the all GID data sets that the Sync-Server knows about. For example, the Sync-Server may use a table to hold GID information for all of the records known to that Sync-Server, which according to some embodiments may comprise records that have been deleted in the past. If the Sync-Server does not find the GID in its records, then the new record may be treated as truly new (subject to any other checks against the Sync-Server database such as an identity key check). However, if the GID is found in the Sync-Server's records, then the handling of the pseudo new record will be according to the information found on the Sync-Server with respect to that GID. For example, the Sync-Server records may indicate that the record has been previously deleted; and some embodiments may treat the pseudo new record as deleted and inform the creator client to delete it, while other embodiments may enter a conflicts resolution process to determine user intent either expressly or by inference. In some embodiments, when presented with a new record from a client, if the Sync-Server does not find a GID match, the Sync-Server will proceed to check the new record's identity keys against the Sync-Server's relevant database or table. If there is no GID match but there is an identity key match, some embodiments will associate the two records and update the GES for that record in each system (the client and the Sync-Server) to reflect two GID datums (one for the original record on the Sync-Server and one for the new record coming from the client). These actions may also be taken if the identity keys have substantially the same value. In various embodiments, substantially the same value may be defined as having a particular number or pattern of common values. For example, if a name property is the identity key, values may be defined as substantially the same value if the last name of each value is identical and the first name of one value is a common nickname or an alternative spelling of the first name of another name property value. Other variations of this concept will be apparent to those of skill in the art. Equivalent values may be pre-configured and stored, may be dynamically determined according to an algorithm, or a combination of the two. In addition to updating the GID properties of each system, any conflict between the properties of the associated records will be resolved. Of course, each system may have a different scheme for property-level conflict resolution, and many such schemes are known in the art and may be included in the patents and patent applications incorporated herein.
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 way 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
Thus, we see now that all three systems have a full understanding of the same status in the system.
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.
This is a continuation of U.S. patent application Ser. No. 11/462,676 entitled “Method and System for Using Global Equivalency Sets to Identify Data During Peer-To-Peer Synchronization” filed Aug. 4, 2006 by Bruce Nilo and Gordie Freedman, which is incorporated herein by reference and to which priority is claimed.
Number | Name | Date | Kind |
---|---|---|---|
4467419 | Wakai | Aug 1984 | A |
4558413 | Schmidt et al. | Dec 1985 | A |
4631673 | Haas et al. | Dec 1986 | A |
4761737 | Duvall et al. | Aug 1988 | A |
4792909 | Serlet | Dec 1988 | A |
4953080 | Dysart et al. | Aug 1990 | A |
5163148 | Walls | Nov 1992 | A |
5175849 | Schneider | Dec 1992 | A |
5201044 | Frey, Jr. et al. | Apr 1993 | A |
5276860 | Fortier et al. | Jan 1994 | A |
5287496 | Chen et al. | Feb 1994 | A |
5355483 | Serlet | Oct 1994 | A |
5369757 | Spiro et al. | Nov 1994 | A |
5375232 | Legvold et al. | Dec 1994 | A |
5379412 | Eastridge et al. | Jan 1995 | A |
5381545 | Baker et al. | Jan 1995 | A |
5386554 | Nozaki | Jan 1995 | A |
5403639 | Belsan et al. | Apr 1995 | A |
5454103 | Coverston et al. | Sep 1995 | A |
5481721 | Serlet et al. | Jan 1996 | A |
5487160 | Bemis | Jan 1996 | A |
5490246 | Brotsky et al. | Feb 1996 | A |
5594900 | Cohn et al. | Jan 1997 | A |
5603020 | Hashimoto et al. | Feb 1997 | A |
5627996 | Bauer | May 1997 | A |
5636359 | Beardsley et al. | Jun 1997 | A |
5636360 | Courts et al. | Jun 1997 | A |
5642501 | Doshi et al. | Jun 1997 | A |
5664177 | Lowry | Sep 1997 | A |
5664186 | Bennett et al. | Sep 1997 | A |
5687370 | Garst et al. | Nov 1997 | A |
5710900 | Anand et al. | Jan 1998 | A |
5710922 | Alley et al. | Jan 1998 | A |
5727202 | Kucala | Mar 1998 | A |
5742752 | DeKoning | Apr 1998 | A |
5758358 | Ebbo | May 1998 | A |
5764972 | Crouse et al. | Jun 1998 | A |
5765171 | Gehani et al. | Jun 1998 | A |
5771379 | Gore, Jr. | Jun 1998 | A |
5778411 | DeMoss et al. | Jul 1998 | A |
5806078 | Hug et al. | Sep 1998 | A |
5819275 | Badger et al. | Oct 1998 | A |
5832489 | Kucala | Nov 1998 | A |
5884323 | Hawkins et al. | Mar 1999 | A |
5918229 | Davis et al. | Jun 1999 | A |
5946689 | Yanaka et al. | Aug 1999 | A |
5991771 | Falls et al. | Nov 1999 | A |
6000000 | Hawkins et al. | Dec 1999 | A |
6006231 | Popa | Dec 1999 | A |
6006274 | Hawkins et al. | Dec 1999 | A |
6026415 | Garst et al. | Feb 2000 | A |
6098079 | Howard | Aug 2000 | A |
6101615 | Lyons | Aug 2000 | A |
6151659 | Solomon et al. | Nov 2000 | A |
6188995 | Garst et al. | Feb 2001 | B1 |
6233648 | Tomita | May 2001 | B1 |
6240414 | Beizer et al. | May 2001 | B1 |
6272558 | Hui et al. | Aug 2001 | B1 |
6275831 | Bodnar et al. | Aug 2001 | B1 |
6292803 | Richardson et al. | Sep 2001 | B1 |
6295541 | Bodnar et al. | Sep 2001 | B1 |
6304884 | Garst et al. | Oct 2001 | B1 |
6308201 | Pivowar et al. | Oct 2001 | B1 |
6311193 | Sekido | Oct 2001 | B1 |
6317754 | Peng | Nov 2001 | B1 |
6330618 | Hawkins et al. | Dec 2001 | B1 |
6353837 | Blumenau | Mar 2002 | B1 |
6360272 | Lincke et al. | Mar 2002 | B1 |
6389423 | Sakakura | May 2002 | B1 |
6397311 | Capps | May 2002 | B1 |
6401112 | Boyer et al. | Jun 2002 | B1 |
6446088 | Vaduvur et al. | Sep 2002 | B1 |
6457062 | Pivowar et al. | Sep 2002 | B1 |
6466950 | Ono | Oct 2002 | B1 |
6505215 | Kruglikov et al. | Jan 2003 | B1 |
6516327 | Zondervan et al. | Feb 2003 | B1 |
6539381 | Prasad et al. | Mar 2003 | B1 |
6553037 | Pivowar et al. | Apr 2003 | B1 |
6571262 | Garst et al. | May 2003 | B2 |
6651137 | Baek et al. | Nov 2003 | B2 |
6654772 | Crow et al. | Nov 2003 | B1 |
6671772 | Cousins | Dec 2003 | B1 |
6717599 | Olano | Apr 2004 | B1 |
6748504 | Sawdon et al. | Jun 2004 | B2 |
6757896 | Cohen et al. | Jun 2004 | B1 |
6775679 | Gupta | Aug 2004 | B2 |
6823336 | Srinivasan et al. | Nov 2004 | B1 |
6829617 | Sawdon et al. | Dec 2004 | B2 |
6868417 | Kazar et al. | Mar 2005 | B2 |
6901479 | Tomita | May 2005 | B2 |
6925477 | Champagne et al. | Aug 2005 | B1 |
6981171 | Hashemi | Dec 2005 | B2 |
6983277 | Yamaguchi et al. | Jan 2006 | B2 |
7043637 | Bolosky et al. | May 2006 | B2 |
7085784 | Krishna et al. | Aug 2006 | B2 |
7085785 | Sawdon et al. | Aug 2006 | B2 |
7113963 | McCaw | Sep 2006 | B1 |
7149761 | Cooke et al. | Dec 2006 | B2 |
7181521 | Knauerhase et al. | Feb 2007 | B2 |
7216135 | Sawdon et al. | May 2007 | B2 |
7216199 | Mizuno | May 2007 | B2 |
7216289 | Kagle et al. | May 2007 | B2 |
7290019 | Bjorner et al. | Oct 2007 | B2 |
7346616 | Ramanujam et al. | Mar 2008 | B2 |
7370044 | Mulhern et al. | May 2008 | B2 |
7406499 | Singh et al. | Jul 2008 | B2 |
7426563 | Morita et al. | Sep 2008 | B2 |
7430640 | Schmuck et al. | Sep 2008 | B2 |
7490112 | Suresh et al. | Feb 2009 | B1 |
7502801 | Sawdon et al. | Mar 2009 | B2 |
7506007 | Bjorner | Mar 2009 | B2 |
7523146 | Holt et al. | Apr 2009 | B2 |
7606881 | Chasman et al. | Oct 2009 | B2 |
7610387 | Liskov et al. | Oct 2009 | B1 |
7657769 | Marcy et al. | Feb 2010 | B2 |
7680834 | Sim-Tang | Mar 2010 | B1 |
7728823 | Lyon et al. | Jun 2010 | B2 |
7730026 | Serlet | Jun 2010 | B2 |
7760767 | Nilo et al. | Jul 2010 | B2 |
7769717 | Federwisch et al. | Aug 2010 | B2 |
7778963 | Novik et al. | Aug 2010 | B2 |
7809682 | Paterson et al. | Oct 2010 | B2 |
7814231 | Paterson et al. | Oct 2010 | B2 |
7860826 | Freedman et al. | Dec 2010 | B2 |
7917471 | Balandin | Mar 2011 | B2 |
20020040445 | Flanagin et al. | Apr 2002 | A1 |
20020049764 | Boothby et al. | Apr 2002 | A1 |
20040193952 | Narayanan et al. | Sep 2004 | A1 |
20040214926 | Bittner | Oct 2004 | A1 |
20050144219 | Terada | Jun 2005 | A1 |
20060045092 | Kubsch et al. | Mar 2006 | A1 |
20080005195 | Li | Jan 2008 | A1 |
Number | Date | Country |
---|---|---|
39 19 802 | Dec 1989 | DE |
0 339 221 | Nov 1989 | EP |
0 341 037 | Nov 1989 | EP |
0 501 160 | Sep 1992 | EP |
0 566 966 | Oct 1993 | EP |
0 278 313 | Aug 1994 | EP |
0 679 028 | Oct 1995 | EP |
0 238 158 | Dec 1995 | EP |
0 694 879 | Jan 1996 | EP |
0 840 242 | Oct 1996 | EP |
1 246 061 | Oct 2002 | EP |
1 383 080 | Jan 2004 | EP |
2 218 833 | Nov 1989 | GB |
2000122907 | Apr 2000 | JP |
2000299698 | Oct 2000 | JP |
2003-330827 | Nov 2003 | JP |
200486800 | Mar 2004 | JP |
2005-507130 | Mar 2005 | JP |
9308529 | Apr 1993 | WO |
9820419 | May 1998 | WO |
WO 9845815 | Oct 1998 | WO |
9913403 | Mar 1999 | WO |
9963441 | Dec 1999 | WO |
WO 0106364 | Jan 2001 | WO |
03036541 | May 2003 | WO |
WO 2005112388 | Nov 2005 | WO |
Entry |
---|
Abuan et al.; U.S. Appl. No. 10/769,841, filed Feb. 2, 2004. |
Demers et al.; “Epidemic Algorithms for Replicated Database Maintenance,” Xerox Palo Alto Research Center; (c) 1987. |
PCT Written Opinion received in International Application No. PCT/US2005/022930 mailed Oct. 27, 2005. |
PCT International Search Report received in International Application No. PCT/US2005/022930 mailed Oct. 27, 2005. |
Babaoglu et al.; “Consistent Global States of Distributed Systems: Fundamental Concepts and Mechanisms,” Technical Report UBLCS-93-1; Jan. 1993; Laboratory for Computer Science University of Bologna. |
Holt; “Apparatus and Method for Peer-to-Peer N-Way Synchronization in a Decentralized Environment.” U.S. Appl. No. 11/157,647, filed Jun. 21, 2005. |
Benford, “Dynamic Definition of Entries and Attributes in the Directory Service,” IEEE 1988. |
Chang et al., “Extended K-d Tree Database Organization: A Dynamic Multiattribute Clustering Method,” IEEE Transactions on Software Engineering, vol. SE-7, No. 3, May 1981. |
Chen et al., “A Performance Evaluation of RAID Architectures,” IEEE Transactions on Computers, vol. 45. No. 10, Oct. 1996. |
Chen et al., “Schemes for Snapshot Advancement for Multiversion Concurrency Control,” IBM TDB May 1992. |
Coley, “Support of a Dynamically managed Device Switch Table on a Unix Operating System,” IBM TDB May 1992. |
Com, “Dynamic Memory Estimation for Database Monitor Snapshot,” IBM TDB Mar. 1993. |
Condry et al., “The Object-Oriented Advantage in Prototyping a Remote File System,” In Proceedings Second International Workshop on Object-Orientation in Operating Systems, pp. 190-199, Paris, France, Sep. 1992. |
Cruz et al., “DUNES: A Performance-Oriented System Support Environment for Dependency Maintenance in Workstation Networks,” IEEE 1999. |
Duvall et al., “Database Server Journal Backup Automation Technique,” IBM TDB Feb. 1993. |
Emma et al., “Exclusive Use Directory and Inode Caching,” IBM TDB Dec. 1989. |
Gait, “Stability, Avaliability, and Response in network File service,” IEEE Transactions on software Engineering, vol. 17, No. 2, Feb. 1991. |
Greene, “Indicating the ‘File Types’ in the Files window of a User-Interactive Display System,” IBM TDB Nov. 1986. |
Helary et al., “Computing Particular Snapshots in Distributed Systems,” IBM TDB Mar. 1988. |
Henson, “Managing Executing Files in a Virtual file System,” IBM TDB Mar. 1988. |
Heyrman et al., “Storage management Mechanism for Managing Snapshot Pages,” IBM TDB Sep. 1992. |
Honishi et al., “An Index Structure for Parallel Database Processing,” IEEE 1992. |
Hsieh et al., “Performance Evaluation of Software RAID vs. Hardware RAID for Parallel Virtual File System,” Proceedings in Parallel and Distributed Systems 2002. |
Hua et al., Improving RAID Performance Using a Multibuffer Technique, Proceedings 15th International Conference on Data Engineering. |
Hwang et al., “Reliable Cluster computing with a New Checkpoint RAID-Xarchitecture,” Proceedings of Heterogenous Computing Workshop, 2000. |
Hwang et al., “Orthogonal Striping and Morroring in a Distributed RAID for I/O-Centric Cluster Computing,” IEEE Transactions on Parallel and Distributed Systems, vol. 13, No. 1, Jan. 2002. |
Jin et al., “Improving Partial Stripe Write Performance in RAID Level 5,” IEEE 1998. |
Jonge et al., “Concurrent Access to B-trees,” IEEE 1990. |
Kashyap et al., “Analysis of the Multiple-Attribute-Tree Data-Base Organization,” IEEE Transactions on Software Engineering, vol. SE-3, No. 6, Nov. 1977. |
Kumar, “Coping with Conflicts in a Optimistically Replicated File System,” Proceedings on the Management of Replicated Data 1990. |
Mogi et al., “Dynamic Parity Stripe Reorganizations for RAIDs Disk Arrays,” IEEE 1994. |
Park et al., “Striping in Disk Array RM2 Enabling the Tolerance of Double Disk Failures,” IEEE 1996. |
Pilarski et al., “Checkpointing for Distributed Databases: Starting From the Basics,” IEEE Transactions on the Parallel and Distributed Systems, vol. 13, No. 5, Sep. 1992. |
Santry, “Elephant: the File System That Never Forgets,” Proceedings of the Seventh Workshop on Hot Topics in Operating Systems, 1999. |
Sechrest et al., “Blending Hierarchical and Attribute-Based File Naming,” IEEE 1992. |
Venkatesan, “Message-Optimal Incremental Snapshots,” IEEE 1989. |
Watanabe et al., “Eliminate Information Inconsistency for X.500 Directory,” IEEE 1994. |
Yang et al., “Global Snapshots for Distributed Debugging,” IEEE 1992. |
Number | Date | Country | |
---|---|---|---|
20110264623 A1 | Oct 2011 | US |
Number | Date | Country | |
---|---|---|---|
Parent | 11462676 | Aug 2006 | US |
Child | 12978714 | US |