Method, system and program for synchronizing data

Provided are a method, system, and program for synchronizing data. A client data record is received from a client and a determination is made of a server data record corresponding to the client data record and a stored digest generated from a previously received version of the received client data record. A current digest is computed from the received client data record. A determination is then made as to whether the computed current digest matches the stored digest. The server data record is updated with modified data from the received client data record if the computed digest and stored digest do not match.

BACKGROUND OF THE INVENTION

1. Field of the Invention

The present invention relates to a method, system, and program for synchronizing data.

2. Description of the Related Art

Many small mobile devices, such as hand held computers, Personal Digital Assistants (PDAs), etc., utilize the SyncML synchronization protocol to synchronize data at a remote central server. Handheld computers, mobile phones, pagers, laptops, Personal Digital Assistant (PDA), etc., may synchronize their data with network applications, desktop calendars, and other locations where information is stored. This ability to readily access and synchronize information is key to the pervasive nature of mobile computing.

Occasionally, conflicts may need to be resolved between the data at the remote devices and the central data location, or server. Mobile device users may retrieve data from the network and store the data on the mobile device, where they access and manipulate the local copy of the data. Periodically, users reconnect with the network to send any local changes back to the networked data repository. Users also have the opportunity to learn about updates made to the networked data while the device was disconnected. Occasionally, they need to resolve conflicts among the updates made to the networked data and/or local copy of the data at the mobile device. This reconciliation operation where updates are exchanged and conflicts are resolved is known as data synchronization, where two sets of data are processed to make the two sets identical. For a mobile device, synchronization applies to the data that the mobile device stores locally.

In the SyncML protocol, a SyncML client, such as a mobile phone, pager, PDA, etc., sends modifications to data to a SyncML server. The SyncML server is responsible for performing the synchronization analysis when receiving client modifications. If for some reason, the client and server lose synchronization in a manner that results in errors or synchronize for the first time, either the server or client may initiate a slow synchronization (slow sync). Slow sync is a two-way synchronization in which all items in one or more database are compared with each other on a field-by-field basis. In the slow sync process, the client sends all its data in a client database stored in the client device to the server, and the server performs the sync analysis on a field-by-field basis between the received client data and the server data. After the slow sync analysis, the server returns all needed modifications back to the client. Further details of the slow sync and other synchronization methods are discussed in the publication “SyncML Sync Protocol, Version 1.1”, (February 2002), available at www.syncml.org, which publication is incorporated herein by reference in its entirety.

Because a slow sync operation requires an analysis of every record in a database as maintained at a client and server on a field-by-field basis, the slow sync process can take a considerable amount of time and consume significant network bandwidth resources to transfer all records in the database. Network bandwidth and transmission time is even more crucial for wireless networks where the transmission bandwidth is significantly less than that of a high speed transmission line based network.

Accordingly, there is a need in the art for improved techniques for synchronizing data between clients and servers.

SUMMARY OF THE PREFERRED EMBODIMENTS

Provided are a method, system, and program for synchronizing data. A client data record is received from a client and a determination is made of a server data record corresponding to the client data record and a stored digest generated from a previously received version of the received client data record. A current digest is computed from the received client data record. A determination is then made as to whether the computed current digest matches the stored digest. The server data record is updated with modified data from the received client data record if the computed digest and stored digest do not match.

In further implementations, a determination is made as to whether the server data record corresponding to the received client data record was modified, wherein the server data record is updated with the modified data from the received client data record if the server data record was not modified. In such case, modified data from the server data record may be transmitted to the client if the server data record was modified and the current and stored digests match.

Still further, a conflict resolution may be applied if the server data record was modified and the current and stored digests do not match to determine one of updating the server data record with modified data from the received client data record or transmitting modified data from the server data record to the client.

Yet further, the server data record may maintain information on a set of property values and the client data record may maintain a subset of the set of property values maintained in the server data record.

Described implementations provide techniques for synchronizing data records between a client and server, where a digest of a previously received client data record is used to determine whether the client has modified the transmitted client data record. In this way, the client and server may maintain different subsets of information and the digest may be used to determine whether the data from the client or server has changed since the last time the digest was generated.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

FIG. 1illustrates a computing environment in which aspects of the invention are implemented. A client system2and server system4communicate over a network6, where the network may comprise a wireless network or network data transmission lines between the network6and the systems2and4. The network may comprise the Internet, an Intranet, a Wide Area Network (WAN), Local Area Network (LAN), Storage Area Network (SAN), etc.) using any network communication protocol known in the art. Although only one client2is shown, there may be multiple client systems that communicate with the server4. The client2includes a client database8of records, such as an address database of electronic business card records. The server4includes a server database10maintaining records corresponding to the records maintained in one or more client databases8in one or more clients2. The client2and server4also include a client12and server14sync agents, respectively, to perform synchronization between the records in the client database8and the server database10.

The client2may comprise a remote computing device capable of remote communication with the network6, such as a Personal Digital Assistant (PDA), pager, cellular phone, hand held computer, laptop computer, satellite device, etc. Alternatively, the client2may comprise other types of computing devices, such as workstations, desktop computers, servers, mainframes, etc. The server4may comprise a server class machine or any other computer device capable of storing a server database10maintaining database records for one or more clients2. The client8and server10databases may store any type of data, such as address information, electronic business cards, calendar information, e-mail messages or any other type of information capable of being maintained in a database. The databases8and10may comprise any type of database known in the art, such as a relational database, object oriented database, or any other data structure capable of maintaining information on one or more records having common fields. The client12and server14sync agents may utilize any protocol known in the art to perform synchronization of the databases8and10over the network6. For instance, in certain implementations, the sync agents12and14may utilize the SyncML protocol discussed above.

FIG. 2illustrates an example of the format of client records20maintained in the client database8. The client record20has data fields22a,22b, and22c.FIG. 3illustrates an example of the format of server records30maintained in the server database10, where the server record30has data fields32a,32b,32c,32d, and32e. In the example, the client data fields22a,22b,22cand server data fields32a,32b,32cwould maintain the same data. However, the server has additional data in fields32dand32ethat is not maintained at the client. Such a situation may occur when the client2is a remote device that has limited storage capability and only maintains a subset of the data that the server database10maintains. Alternatively, such a situation may occur when the server record30maintains data that is not needed or not intended for access by the client2. The server database10also maintains a client record digest34with a server record30, where the client record digest34comprises a computed value based on the client record20corresponding to the server record30. The client record digest34may comprise a checksum value calculated from the content of the client record20that is intended to provide a unique representation of the client record20. In certain implementations, the client record digest34may be generated using the MD5 message-digest algorithm that produces as output a 128-bit “fingerprint” or “message digest” of the input client record20, where it is computationally infeasible to produce two messages having the same message digest. Further details of the MD5 message digest algorithm are described in the publication “The MD5 Message-Digest Algorithm”, published by the Internet Engineering Task Force (IETF) as “Request for Comments: 1321” (April 1992), which publication is incorporated herein by reference in its entirety. Alternatively, any algorithm known in the art that is capable of generating unique output codes from input can be used to generate the client record digest34from the input client record20. In certain implementations, the digest34may be fewer bytes than the input client record20in order to conserve storage space at the server4.

A corresponding client20and server30record that maintain data for a same record may have a common unique identifier identifying the particular record that is represented in both the client8and server10databases in corresponding client20and server30records. For instance, in certain implementations the databases8and10may maintain contact information using the vCard format, where each card for a contact may have any number of attributes for a particular person or entity for which information is maintained in a vCard object. Such attributes may comprise the name of the person or organization, home address, work address, phone numbers, e-mail, birth date, etc. If the client database8maintains a subset of the data maintained in the server database10, then the client database8may not include all of the properties maintained in the server vCard in the server database10to conserve client2storage resources. Further details of the vCard object format are described in the publication “vCard Specification, Version 2.1” (1996), available on the Internet at ww.icm.org, which publication is incorporated herein by reference in its entirety.

FIG. 4illustrates logic implemented in the client12and server14sync agents to perform synchronization in accordance with implementations of the invention. A slow sync process is initiated at blocks100and104at the client12and server14, respectively, where either the client12or server14sync agent may initiate the slow synchronization process. Slow synchronization refers to a process where all records in the client database8are processed by the server sync agent14and may comprise the slow sync process specified in the SyncML protocol or any other device synchronization protocol known in the art. As part of the slow sync process, the client sync agent12transmits every client record20in the client database8to the server sync agent14to consider.

In response (at block106) to receiving a client record20, having one or more fields of property values22a,22b,22c, the server sync agent14determines (at block108) whether the server database10maintains a server record30corresponding to the received client record20, such as an electronic business card for the same person, calendar record, etc. If (at block108) there is no corresponding server record30, such as the case if the record was created by the client database8in the client2, then the server sync agent14generates (at block110) a server record30in the server database14and copies data from each field22a,22b,22cfrom the received client record20to the corresponding fields32a,32b,32cin the generated server record30. In implementations where the client records20include a subset of fields22a,22b,22cthat the server records30maintains, those fields32dand32ein the server records30not included the client records20remain empty until such additional fields are subsequently updated to a user having access to such fields32dand32e. The server sync agent14further computes (at block114) a client record digest34from the received client record20and stores and associates the generated client record digest34with the server record30corresponding to the received client record20.

If(at block108) the server database10already has a server record30corresponding to the received client record20, then the server sync agent14computes (at block116) a digest from the received client record20, using the same algorithm used to compute the client record digest34from the previously received version of the client record20and compares (at block118) the digest computed from the received record (at block116) with the client record digest34associated with the server record30. If(at block118) the digests match and the server record30has been modified (at block120), then only the server record has been modified since the last time the client20and server30records were synchronized. The server sync agent14may use any technique known in the art, such as flags or time stamps, to determine whether the server record30has been modified since the last synchronization. In such case, the server sync agent14transmits (at block122) the server record30with the modified data to the client sync agent12. In alternative implementations, the server sync agent14may only transmit the modified fields32a,32b,32cto the client sync agent12. If(at block120) the digests match and the server record30has not been modified, then neither the client2nor server4has modified the client20and server30records, and control ends as no synchronization is necessary.

Upon receiving (at block124) the modified server record30or modified fields32a,32b,32ctransmitted by the server sync agent14(at block122), the client sync agent12updates (at block126) the fields22a,22b,22cin the client record20corresponding to the received server record30with the data in the modified fields32a,32b,32cin the received server record30so that the client20and server30records are synchronized with respect to the common fields22a,22b,22cand32a,32b,32c, respectively.

If (at block118) the computed digest and stored client record digest34do not match, then the server sync agent14determines (at block130) whether the server record has been modified. If so, then both the client20and server30records were modified by the client2and server4. In such case, the server sync agent14applies a conflict resolution policy in a manner known in the art to determine whether the server or client modifications apply. If (at block132) the conflict resolution policy specifies to use the server changes, then the server sync agent12transmits (at block122) the modified server record30, or modified fields32a,32b,32c, to the client sync agent12to apply to the client record20in the client database8. Otherwise, if (at block132) the conflict resolution indicates to use the modifications in the client record20, then control proceeds to block112where the server sync agent12updates the server record30with the modified data in the corresponding client record20so that the server record30reflects the client modifications. Further, if (at block130) the client record20was modified, as indicated by the digests not matching (at block118) and no changes were made to the server record30, as determined at block130, then control proceeds to block112to update the server record30with the modified data from the received client record20and to recalculate the client record digest34from the modified received client record20for use in a subsequent slow sync operation.

After processing all client records20, the server sync agent14may then transmit any new server records30not included in the client database12or delete the server records30from the server database10corresponding to client records20deleted from the client database12since the last synchronization. The client sync agent would generate and store a client record20for the received new server record30and only include data from fields32a,32b,32cin the new server record30in the subset of fields22a,22b,22cin the generated client record20.

The described implementations utilize a digest calculated form the last transmitted client record to determine whether client changes have been made when performing a slow sync or other synchronization process. This provides an improved technique for checking whether client modified a database record during a synchronization process.

ADDITIONAL IMPLEMENTATION DETAILS

In the described implementations, the digest was used to detect client modifications to client records during a slow sync process. Alternatively, the above described techniques may apply to any synchronization process, and is not limited to a slow sync process.

In certain implementations, the client2comprises a mobile device that communicates with the server4over a wireless network6. Alternatively, the client2and server4may connect through data transmission lines connected to the network6. Still further, the client2and server4may comprise processes executing in programs on a same computer system that communicate through a shared memory space of the computer system.

The client and server records may comprise any type of data, such as addresses in an address database, electronic business cards (e.g., vCards), calendar appointments in a calendar database, electronic mail messages in an e-mail store, or any other type of data that may be represented and maintained in a database.

Certain described implementations concerned a modification of the SyncML slow sync process to improve the performance of the slow sync process. However, in alternative implementations, the above described technique for determining how to determine client modifications and handle such modifications may apply to any synchronization process known in the art, including synchronization processes for protocols other than SyncML and for SyncML synchronization processes other than the slow sync process.

The illustrated logic ofFIG. 4indicates certain events occurring in a certain order. In alternative implementations, certain operations may be performed in a different order, modified or removed. Morever, steps may be added to the above described logic and still conform to the described implementations. Further, operations described herein may occur sequentially or certain operations may be processed in parallel. Yet further, operations may be performed by a single processing unit or by distributed processing units.

FIG. 5illustrates one implementation of the architecture of the client2and server4systems. The systems2and4may implement a computer architecture200having a processor202(e.g., a microprocessor), a memory204(e.g., a volatile memory device), and storage206(e.g., a non-volatile storage, such as magnetic disk drives, optical disk drives, a tape drive, etc.). The storage206may comprise an internal storage device or an attached or network accessible storage. Programs in the storage206are loaded into the memory204and executed by the processor202in a manner known in the art. The architecture further includes a network card208to enable communication with a network, wherein the communication may be wireless or occur over a network cable and port. An input device210is used to provide user input to the processor202, and may include a keyboard, mouse, pen-stylus, microphone, touch sensitive display screen, or any other activation or input mechanism known in the art. An output device212is capable of rendering information transmitted from the processor202, or other component, such as a display monitor, printer, storage, etc.