Method and apparatus for synchronizing how data is stored in different data stores

#The present invention pertains to how the respective data stores on different devices, holding data items of one or more applications such as desktop calendars and e-mail, are synchronized. More particularly, the present invention concerns how the data structure of such data stores is synchronized.

#Today it is possible for a businessperson to use an e-mail application and a calendar application (for keeping track of appointments) on a mobile phone or a palm (handheld) computer (or some other mobile terminal) and have an assistant use the same applications on a desktop computer to keep track of e-mail sent and received by the assistant on behalf of the businessperson, and to keep track of appointments for the businessperson. In such an arrangement, it is often the case that the data items (also called here data units) for the e-mail application and data items for the calendar are kept in a data store on the mobile phone and in another data store on the desktop. Thus, when changes are made to either of the data stores, each including data items for both the e-mail and the calendar application, the data stores need to be synchronized. In synchronizing respective data stores (i.e. synchronizing both the data items and data structure of the two data stores) used by two applications running on different equipment the contents of the two data stores are set to correspond to each other based on a protocol in which changes since a last synchronization are communicated, conflicts between changes made on both pieces of equipment are resolved (according to some policy), and changes are made to either the data items or their organization or both in one or both of the data stores.

#A facility is being developed for synchronizing such data stores based on what is called SyncML (synchronization markup language), being developed under the so-called SyncML Initiative. (See http://www.syncml.org/ for information about SyncML, including standards and specifications for SyncML, and the SyncML Initiative, especially including the SyncML Representation Protocol and the SyncML Sync Protocol.) SyncML is an open industry standard for a common language for universal synchronization of remote data (i.e. data items stored in different equipment and so in different data stores) and personal information across multiple networks, platforms and devices. With SyncML, data items, but not yet data structure, can be synchronized on different devices connected via one or more interconnecting networks, including, for example, a Universal Mobile Telecommunications System (UMTS) Radio Access Network (UTRAN) and the Internet, where the communication may be wireless in whole or in part or may be wireline. Thus, the devices may communicate via, for example, fixed networks (including wireless networks), infrared, cable, or Bluetooth.

#The above and other objects, features and advantages of the invention will become apparent from a consideration of the subsequent detailed description presented in connection with accompanying drawings, in which:

#FIG. 1 is a block diagram/flow diagram of a client (such as a mobile phone) and a server (such as a network server or is PC) exchanging SyncML messages to synchronize their respective data stores, according to the invention;

#FIG. 2 is a schematic of a SyncML message according to the invention;

#Referring now to FIG. 1, a client 11 is shown synchronizing a client data store 11c with a corresponding server data store 12c of a server 12. (The data stores can be of use in either device management or for holding user data, such as for example e-mails.) A data store can in general include one (or even more) system directory structures and possibly also one or more internal directory structures (i.e. an internal directory structure being one maintained by one or more applications as opposed to an operating system), with any directory structure able to be represented as illustrated in FIG. 4, so that a directory structure is a tree structure of folders, each folder able to include one or more data units (such as files, i.e. units of data maintained in a system directory structure, or units or data maintained by applications in an internal directory, such as e-mails maintained by an e-mail application) and one or more other folders of the tree structure. The synchronizing occurs via the exchange of SyncML messages, although messages according to any similarly structured or analogous language could also be used. Some of the SyncML messages being exchanged include commands for synchronizing the data stores 11c 12c with respect to data units, and some for synchronizing the data stores with respect to the data organization, i.e. so that both data stores have an equivalent structure in terms of folders, at least in so far as the applications are concerned on whose behalf the synchronization is being performed. The client 11 is any device that plays the role of a client in a client/server model, and according to SyncML protocol, a client (usually a laptop or a portable phone or other wireless terminal) sends all changes in its data store 11c to the server 12, a device (usually for example a desktop computer) having the role of a server in the client/server model. (Of two devices synchronizing their respective data stores, the device having the greater computing capability will usually assume the role of the server.)

#The client 11 and the server 12 include one or more respective application entities 11a 12a, and they also include a (generic, i.e. not particularized to a particular application) respective sync agents 11b 12b. The server application entity 12a differs from the client application entity 11a in that it not only interfaces with the server sync agent, but also interfaces with a server sync engine 12f, which has no counterpart in the client 11. Similarly, the server sync agent 12c differs from the client sync agent 11c in that it also interfaces with the server sync engine 12f. The client/server application entity 11a/12a is for example a calendar application used to keep track of appointments for a salesperson. If an appointment is made on the client device 11, then the appointment information is stored in the client data store 11c as a new file. Later, either at the request of the client 11 or the prompting of the server 12, the data store 12c is synchronized with the client data store 11c in respect to the new data (i.e. the new file). In addition, if a change is made to the directory structure on the client data store 11c, then again, the client data store 11c and server data store 12c must be synchronized, in this case with respect to the directory structure, i.e. in respect to what folders are used to hold the data units for the application. Also, any change made on the server data store 12c, including changes to either folders or data units for the applications 11a 12a, will require synchronizing the client data store 11c and the server data store 12c by the exchange of SyncML messages.

#Still referring to FIG. 1, the SyncML messages may be communicated according to various transport connections 14, including for example hypertext transport protocol (HTTP), wireline session protocol (WSP), and object exchange protocol OBEX). (The transport connections may be provided using any kind of physical layer connection, including either a wireless connection or a wireline connection.) As shown, when the server 12 communicates a SyncML message to the client 11 (and vice versa), the server sync agent 12b uses a sync interface (I/F) 12d to provide the message to a server sync adapter 12e which in turn provide the SyncML message to the client 11 via the transport connection 14. At the receiving end, a client sync adapter 11e receives the SyncML message and passes it to a client sync I/F 11d which in turn provides it to the client sync agent 11b.