WO2009111492A1 - Data synchronization protocol - Google Patents

Data synchronization protocol Download PDF

Info

Publication number
WO2009111492A1
WO2009111492A1 PCT/US2009/035909 US2009035909W WO2009111492A1 WO 2009111492 A1 WO2009111492 A1 WO 2009111492A1 US 2009035909 W US2009035909 W US 2009035909W WO 2009111492 A1 WO2009111492 A1 WO 2009111492A1
Authority
WO
WIPO (PCT)
Prior art keywords
sync
server
sync mode
proposed
dataclasses
Prior art date
Application number
PCT/US2009/035909
Other languages
French (fr)
Other versions
WO2009111492A4 (en
Inventor
Brendon A. Mccarthy
Carsten Guenther
Original Assignee
Apple Inc.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Apple Inc. filed Critical Apple Inc.
Priority to AU2009221998A priority Critical patent/AU2009221998B2/en
Priority to CA2717535A priority patent/CA2717535C/en
Priority to KR1020107022191A priority patent/KR101167833B1/en
Priority to GB1016416A priority patent/GB2471227A/en
Priority to KR1020127004382A priority patent/KR101343202B1/en
Priority to JP2010549823A priority patent/JP5280462B2/en
Priority to KR1020117026597A priority patent/KR101186042B1/en
Priority to CN2009801160698A priority patent/CN102016846B/en
Publication of WO2009111492A1 publication Critical patent/WO2009111492A1/en
Publication of WO2009111492A4 publication Critical patent/WO2009111492A4/en

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46Multiprogramming arrangements
    • G06F9/52Program synchronisation; Mutual exclusion, e.g. by means of semaphores
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/01Protocols
    • H04L67/10Protocols in which an application is distributed across nodes in the network
    • H04L67/1097Protocols in which an application is distributed across nodes in the network for distributed storage of data in networks, e.g. transport arrangements for network file system [NFS], storage area networks [SAN] or network attached storage [NAS]
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F15/00Digital computers in general; Data processing equipment in general
    • G06F15/16Combinations of two or more digital computers each having at least an arithmetic unit, a program unit and a register, e.g. for a simultaneous processing of several programs
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/27Replication, distribution or synchronisation of data between databases or within a distributed database system; Distributed database system architectures therefor
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F17/00Digital computing or data processing equipment or methods, specially adapted for specific functions

Definitions

  • Data synchronizing between a client and a server can be performed using synchronization protocols such as Open Mobile Alliance - Data Synchronization protocol OMA DS/SyncML (formerly known as the SyncML protocol).
  • OMA DS/SyncML Open Mobile Alliance - Data Synchronization protocol
  • the OMS DA/SyncML is a sync protocol that enables serial synchronization of dataclasses and can require 5 or more roundtrips per dataclass.
  • synchronizing data includes receiving a request to initiate a sync session.
  • the request includes a proposed sync mode for each of one or more dataclasses, and one or more changes to the one or more dataclasses.
  • One or more status codes are generated to indicate whether the proposed sync mode for each dataclass is accepted.
  • the accepted sync mode is used for each dataclass to selectively update one or more data items associated with the one or more changes to the one or more dataclasses.
  • the updated one or more data items are selectively committed at the server.
  • Generating one or more status codes can include accessing information saved from a previous sync session to determine whether to use the proposed sync mode to synchronize the one or more data items.
  • Receiving the request can include receiving the proposed sync mode for two or more dataclasses in parallel. Also, receiving the request can include receiving the proposed sync mode that includes a fast sync mode, a slow sync mode or a reset sync mode. Further, receiving the request can include receiving a fast sync mode that enables exchange of data items to be updated only.
  • the sync session can be completed in one round trip that includes two messages. When the sync session is interrupted, a fast sync can be reaccepted.
  • the updated one or more data items can be selectively committed at the server when the client device sends a command to commit the updated one or more data items.
  • the proposed sync mode can be rejected and the received request can be responded to with a different sync mode.
  • a computer program product embodied on a computer readable medium, is operable to cause a data processing apparatus to perform various operations.
  • the computer program product is operable to cause a data processing apparatus to receive a request to initiate a sync session.
  • the request includes a proposed sync mode for each of one or more dataclasses and one or more changes to the one or more dataclasses.
  • the computer program product is operable to cause a data processing apparatus to generate a status code indicative of whether the proposed sync mode for each dataclass is accepted.
  • the computer program product is operable to cause a data processing apparatus to based on the generated status code, use the accepted sync mode for each dataclass is used to selectively update one or more data items associated with the one or more changes to the one or more dataclasses.
  • the computer program product is configured to cause a data processing apparatus to selectively commit the updated one or more data items at a server.
  • Implementations can optionally include one or more of the following features.
  • the computer program product can cause a data processing apparatus to generate the one or more status codes based on information saved from a previous sync session.
  • the computer program product can cause a data processing apparatus to receive the proposed sync mode for two or more dataclasses in parallel.
  • the computer program product can cause a data processing apparatus to receive the proposed sync mode that includes a fast sync mode, a slow sync mode or a reset sync mode.
  • the computer program product can cause a data processing apparatus to receive a fast sync mode that enables exchange of data items to be updated only. Update operations on a data item may (1 ) create a new item (add), (2) modify properties of an existing item (modify) or (3) delete an existing item (delete).
  • the computer program product can cause a data processing apparatus to complete the sync session in one round trip that includes two messages.
  • the computer program product can cause a data processing apparatus to reaccept a fast sync mode when the sync session is interrupted.
  • the computer program product can ATTORNEY DOCKET NO. 18814-104WO1 / P6130WO1
  • the computer program product can cause a data processing apparatus to receive the proposed sync mode and the one or more changes to the one or more dataclasses in a single message.
  • the computer program product can cause a data processing apparatus to selectively commit the updated one or more data items at the server when the client device sends a command to commit the updated one or more data items.
  • the computer program product can case a data processing apparatus to reject the proposed sync mode and respond to the received request with a different sync mode.
  • a server for syncing data includes a processor configured to operate a transport protocol that enables opening of one or more connections to one or more client devices.
  • the processor is also configured to operate a sync protocol that enables data synchronization between the server and the one or more client devices over the opened one or more connections.
  • the sync protocol enables the server to receive a request to initiate a sync session.
  • the request includes a proposed sync mode fore each of one or more dataclasses and one or more changes to the one or more dataclasses.
  • the sync server also enables the server to generate one or more status codes to indicate whether the proposed sync mode for each dataclass is accepted.
  • the sync protocol also enables the server to, based on the generated status code, use the accepted sync mode for each dataclass to selectively update one or more data items associated with the one or more changes to the one or more dataclasses.
  • the sync protocol further enables the updated one or more data items to be selectively committed at the server..
  • Implementations can optionally include one or more of the following features.
  • the processor can be configured to access a data repository to update one or more data items based on the received one or more changes.
  • the processor can be configured to operate the sync protocol to accept or reject the proposed sync mode for each dataclass based on information saved from a previous sync session.
  • the processor can be configured to operate the sync protocol to received the proposed sync mode for two or more dataclasses in parallel.
  • the processor can be configured to operate the sync protocol to receive the proposed sync mode that includes a fast sync mode, a slow sync mode or a reset sync mode.
  • the processor can be configured to operate the sync protocol to receive the proposed sync mode that includes a fast sync mode that enables the one or more client devices to send data items to be updated only.
  • the processor can be configured to ATTORNEY DOCKET NO. 18814-104WO1 / P6130WO1
  • the processor can be configured to operate the sync protocol to receive request to reinitiate a fast sync when the sync session is interrupted.
  • the processor can be configured to operate the sync protocol to complete the sync session in one round trip that includes two messages.
  • the processor can be configured to operate the sync protocol to receive the proposed sync mode and the one or more changes to the one or more dataclasses in a single message from at least one of the one or more client devices.
  • the processor can be configured to operate the sync protocol to selectively commit the updated one or more data items at the server when one of the one or more client devices sends a command to commit the updated one or more data items.
  • the processor can be configured to operate the sync protocol to rejecting the proposed sync mode and responding to the request with a different sync mode.
  • synchronizing data includes sending a request to a server to initiate a sync session.
  • the request includes a proposed sync mode for each of one or more dataclasses, and one or more changes to the one or more dataclasses.
  • One or more status codes are received to indicate whether the proposed sync mode for each dataclass has been accepted by the server. Based on the received status code, the accepted sync mode for each dataclass is used to receive from the server additional changes to the one or more dataclasses. Further, at a client device, the additional changes received from the server are committed.
  • Implementations can optionally include one or more of the following features.
  • the one or more status codes can indicate that the proposed sync mode for at least one of the one or more data classes has been rejected by the server. Another request that includes a different sync mode than the rejected sync mode can be sent to the server. Also, the proposed sync mode and the one or more changes can be sent in a single message to the server.
  • the proposed sync mode for two or more dataclasses can be sent in parallel.
  • a different proposed sync mode can be sent for each of the two or more dataclasses in parallel. For example, a proposed fast sync mode can be sent for one of the dataclasses and a proposed slow sync mode for another of the dataclasses. After the sync session is interrupted, the sync session can be reinitiated using the accepted sync protocol..
  • a computer program product embodied on a computer- readable medium, is operable to cause a data processing apparatus to perform one or more operations.
  • the computer program product is operable to cause a data processing apparatus to send a request to a server to initiate a sync session.
  • the computer program product is operable to cause a data processing apparatus to receive one or more status codes that are indicative of whether the proposed sync mode for each dataclass has been accepted by the server. Based on the received status code, the computer program product is operable to use the accepted sync mode to receive from the server additional changes to the one or more dataclasses and commit at a client device the additional changes received from the server.
  • the computer program product can be operable to cause a data processing apparatus to perform operations that includes receiving the one or more status codes that indicate that the proposed sync mode for at least one of the one or more data classes has been rejected by the server; and sending another request that includes a different sync mode than the rejected sync mode.
  • the computer program product can be operable to cause a data processing apparatus to send the proposed sync mode and the one or more changes in a single message to the server.
  • the computer program product can be operable to cause the data processing apparatus to send the proposed sync mode for two or more dataclasses in parallel.
  • the computer program product can be operable to cause the data processing apparatus to send a different proposed sync mode for each of the two or more dataclasses in parallel.
  • the computer program product can be operable to cause the data processing apparatus to send a proposed fast sync mode for one of the dataclasses and a proposed slow sync mode for another of the dataclasses.
  • the computer program product can be operable to cause the data processing apparatus to reinitiate the sync session using the accepted sync protocol after the sync session is interrupted.
  • a client device includes a processor configured to operate a transport protocol that enables opening of one or more connections to a server and a sync protocol that enables data synchronization between the client device and the server over the opened one or more connections.
  • the sync protocol enables the client device to send a request to a server to initiate a sync session.
  • the request includes a proposed sync mode for each of one or more dataclasses and one or more changes to the one or more dataclasses.
  • the sync protocol also enables the client device to receive one or more status codes indicative of whether ATTORNEY DOCKET NO. 18814-104WO1 / P6130WO1
  • Implementations can optionally include one or more of the following features.
  • the processor can be configured to operate the sync protocol to receive the one or more status codes that indicate that the proposed sync mode for at least one of the one or more data classes has been rejected by the server; and send another request that includes a different sync mode than the rejected sync mode.
  • the processor can be configured to operate the sync protocol to send the proposed sync mode and the one or more changes in a single message to the server.
  • the processor can be configured to operate the sync protocol to send the proposed sync mode for two or more dataclasses in parallel.
  • the processor can be configured to operate the sync protocol to send the proposed sync mode for two or more dataclasses in parallel comprising sending a different proposed sync mode for each of the two or more dataclasses in parallel.
  • the processor can be configured to operate the sync protocol to send a proposed fast sync mode for one of the dataclasses and a proposed slow sync mode for another of the dataclasses.
  • the processor can be configured to operate the sync protocol to reinitiate the sync session using the accepted sync protocol after the sync session is interrupted.
  • the sync protocol as described in this specification can reduce the number of round trips (the number of back and forth messages exchanged) to complete a sync session.
  • the sync protocol as described in this specification can complete a sync session in one round trip, for example.
  • the sync protocol as described in this specification enables sync mode negotiation for each of multiple dataclasses in parallel. Thus, a request for sync mode negotiation can be sent for multiple dataclasses in one message.
  • the sync protocol as described in this specification enables field level differencing and record level differencing.
  • the synchronization protocol as described in this specification is simpler than conventional protocols, such as SyncML.
  • the set of commands available for the synchronization protocol is simple and yet extensible.
  • synchronization protocol as described in this specification represents each message as a text or binary property list files (plist).
  • the synchronization protocol as described in this specification is efficient and robust. For example, a sophisticated anchor logic is provided on the server. Further, the synchronization protocol is tolerant of unreliable network. Even when the network connection is interrupted, the anchor logic ensures efficient synchronization once reconnected. Further, the synchronization protocol can maintain relatively small message size.
  • the synchronization protocol as described in this specification is rich. For example, the synchronization protocol enables exchange of device information between the client device and the server. Also, the synchronization protocol provides convenient yet rich data representation.
  • FIG. 1 A is a block diagram showing a system for enabling data synchronization between a client device and a server.
  • FIG. 1 B shows example components of a server.
  • FIG. 1 C shows example components of a client device.
  • FIG. 2 is a table showing example elements for the header element of a message.
  • FIG. 3 shows an example property list file (plist).
  • FIG. 4 is a table showing example elements for a command request element.
  • FIG. 5 is a table shows example elements for command response element.
  • FIG. 6 is a table showing example parameters for a get command.
  • FIG. 7 is a table that shows examples of parameters for a get command response.
  • FIG. 8 is a table showing example parameters for a put command.
  • FIG. 9 is a table showing example parameters for a put command response.
  • FIG. 10 is a table showing example parameters for a delete command.
  • FIG. 1 1 is a table showing example parameters for a delete command response.
  • FIG. 12 is a table showing example parameters for a sync-start command. ATTORNEY DOCKET NO. 18814-104WO1 / P6130WO1
  • FIG. 13 is a table that shows example parameters for a sync-start command response.
  • FIG. 14 is a table showing example parameters for a sync-changes command.
  • FIG. 15 is a table showing example parameters for a sync-changes command response.
  • FIG. 16 is a table showing example parameters for a sync-commit command.
  • FIG. 17 is a table showing example parameters for a sync-commit command response.
  • FIG. 18 is a table showing example parameters for a sync-cancel command.
  • FIG. 19 is a table showing example parameters for a sync-cancel command response.
  • FIG. 20 is a table showing example status elements.
  • FIG. 21 is a table showing example status codes for statuses available to be included in message headers, commands and command responses.
  • FIG. 22 is a table describing the effect of receiving a given status for a command on the session or on other commands in the message.
  • FIG. 23 is a table showing example keys for the anchors element.
  • FIG. 24 shows an example of a sync session.
  • FIG. 25 shows an example of a optimal fast or reset sync between a client device and a server.
  • FIG. 26 shows an alternate example of a fast or reset data sync.
  • FIG. 27 shows another example data sync session with idmap deferred from session 1 to start of session 2.
  • FIG. 28 illustrates an example of a slow sync.
  • FIG. 29 shows an example of syncing multiple data classes in parallel.
  • FIG. 30 shows an example sync session that uses checkpoint anchors.
  • FIG. 31 is a table showing example checkpoint anchors.
  • FIG. 32 shows a table defines example key-value pairs for the Devicelnfo element.
  • FIG. 33 is a table showing example key-value pairs for filter settings.
  • FIG. 34 is an augmented Backus-Naur Form (ABNF) description of the ATTORNEY DOCKET NO. 18814-104WO1 / P6130WO1
  • FIG. 35 shows an example sync session.
  • FIG. 36 shows a summary of four example messages for a reset sync session.
  • FIGS. 37a and 37b show an example message sent from a client device to a server.
  • FIGS. 38a, 38b, 38c and 38d show an example message sent from a server to a client device.
  • FIGS. 39a, 39b and 39c show an example message sent from a client device.
  • FIGS. 40a and 40b shown an example message sent from a server.
  • FIG. 41 shows a summary of two example messages for a fast sync.
  • FIGS. 42a and 42b show an example message sent from a client device for a fast sync.
  • FIGS. 43a, 43b and 43c show an example message sent from a server in response to a message sent by a client device.
  • FIGS. 44a and 44b show an example process for syncing a client device and a server.
  • a wireless structured data synchronization protocol can enable a client device to interface with a server to synchronize various data.
  • Such protocol can be used to synchronize Mac ® Operating System X (OS X) SyncServices data between a handheld device such as the iPhone ® and a server such as the .Mac ® server, for example.
  • OS X Mac ® Operating System X
  • the OTA synchronization protocol as described in this specification relies upon the underlying network transport to perform authentication and/or authorization and message security/encryption using transport layer security (TLS), for example.
  • TLS transport layer security
  • the synchronization protocol can enable these data transport using hypertext transfer protocol (HTTP) transport protocol or other similar transport protocols which are capable of exchanging synchronization protocol messages between the device ATTORNEY DOCKET NO. 18814-104WO1 / P6130WO1
  • the synchronization protocol can enable exchange of protocol messages over the transport, such as HTTP transport.
  • the each message exchanged over the transport includes a header element and a body element.
  • the body element can include a sequence of command and/or command response elements.
  • the synchronization protocol assigns a unique label to each message, command and command response to ensure proper ordering and loss detection.
  • the label can include a sequence of numbers for ordering the messages, commands and command responses.
  • the synchronization protocol instead of the transport (e.g., HTTP) ensures proper ordering and loss detection even when the network protocol does not enforce message ordering.
  • the synchronization protocol is simpler than conventional protocols, such as Synchronization Markup Language (SyncML).
  • SyncML Synchronization Markup Language
  • the set of commands available for the synchronization protocol is simple and yet extensible. For example, three flexible primitive commands are available for manipulating resources. In addition, four "sync" family commands are available for data synchronization. Further, commands may be split across message boundaries.
  • the synchronization protocol as described in this specification represents each message as a text or binary property list files (plist).
  • plists are files that store serialized objects. The plists are often used to store a user's settings, similar to the function of the Windows registry on Microsoft Windows ® .
  • Property list files are also used to store information about bundles and applications.
  • a plist is easy to generate and parse using standard operating system (OS) features, such as NSProperty ⁇ stSerialization class.
  • OS operating system
  • NSProperty ⁇ stSerialization class NSProperty ⁇ stSerialization class.
  • synchronization protocol as described in this specification uses simple sync state machine.
  • the synchronization protocol as described in this specification is efficient and robust.
  • a sophisticated anchor logic is provided on the server.
  • An anchor is a tag or label used to keep track of the synchronization state.
  • the synchronization protocol can sync multiple dataclasses in parallel.
  • the synchronization protocol is tolerant of unreliable network. Even when the network connection is interrupted, the anchor logic ensures efficient synchronization once reconnected with minimal retransmission of data. Further, the synchronization protocol can maintain relatively small message size.
  • FIG. 1 a is a block diagram of a system 100 for enabling data synchronization between a client device and a server.
  • the system 100 includes one or more client devices 1 10 interfacing with one or more servers 120 over a network 150.
  • the client device 1 10 can include mobile devices, such as a mobile phone 1 12, a personal digital assistant (PDA) 1 14, a handheld data processing devicesi 16, etc.
  • the mobile phone 1 12 includes smart phones and integrated mobile devices such as the iPhone ® .
  • the handheld data processing devices can include audio playback devices such as MP3 players and iPod ® devices.
  • the client device 1 10 interfaces with the server 120 using a transport protocol such as HTTP transport protocol to complete a secure data connection.
  • a transport protocol such as HTTP transport protocol to complete a secure data connection.
  • a synchronization protocol 140 enables data synchronization between the connected client device 1 10 and the server.
  • Synchronized data can include various data classes such as contacts (e.g., addresses and phone numbers), calendar, etc.
  • Data synchronization can be performed over the network 150 that includes various wired and wireless networks such as local area network (LAN), wide area network (WAN), Ethernet, Internet, etc.
  • FIG. 1 b shows example components of the server 120.
  • the server 120 can include a processor 160 and a memory 170, among other components.
  • the processor 160 can include a central processing unit (CPU) or other classes of logic machines that can execute computer programs.
  • the memory can include nonvolatile storage devices such as a fixed hard drive or removable storage devices.
  • the removable storage devices can include a compact flash units, USB memory sticks, etc.
  • the processor 160 can operate the transport protocol 130 to open transport connections to one or more client devices 1 10.
  • the processor 160 can operate the sync protocol 140 over the opened transport connections to enable data synchronization between the server 120 and the client devices 1 10.
  • the transport protocol 130 and the sync protocol 140 can be loaded and running on the memory 170 to be executed or operated by the processor 160. For example, as described ATTORNEY DOCKET NO. 18814-104WO1 / P6130WO1
  • FIG. 1 c shows example components of the client devices 1 10.
  • the client devices 1 10 can also include a processor 180 and a memory 190, among other components.
  • the processor 180 can include a central processing unit (CPU) or other classes of logic machines that can execute computer programs.
  • the memory can include nonvolatile storage devices such as a fixed hard drive or removable storage devices.
  • the removable storage devices can include a compact flash units, USB memory sticks, etc.
  • the memory 190 can also include volatile memories such as various forms of random access memories.
  • the processor 180 can operate the transport protocol 130 to open transport connections to one or more servers 120.
  • the processor 180 can operate the sync protocol 140 over the opened transport connections to enable data synchronization between the client devices 1 10 and the server 120.
  • the transport protocol 130 and the sync protocol 140 can be loaded and running on the memory 190 to be executed or operated by the processor 180.
  • the processor 180 can operate the sync protocol 140 to send a request to the server 120 to initiate a sync session.
  • Synchronization is a process of maintaining consistency between two distinct datastores by periodically comparing the changes which have occurred to each since the last time the datastores were known to be consistent.
  • the datastores can include a client device 1 10 on one side and a server 120 on the other side.
  • the datastores are configured with various capabilities. For example, each datastore is configured to supply all data when requested. In addition, each datastore is configured to identify and supply changes since the time of the last synchronization. Each datastore is configured to agree on the schema to be kept in sync. Each datastore is configured to agree on the supported data representations. Each datastore is configured to agree on the semantics of synchronization primitives (i.e. add, update, delete). Further, each datastore is configured to rollback to a previous state should a problem occur during a sync to avoid corrupting the datastores.
  • the synchronized data follows the relational model (E-R) and is divided into "schemas” or “dataclasses” which group definitions of structured data types ("entities”.) Entities within a given dataclass may refer to one another via ATTORNEY DOCKET NO. 18814-104WO1 / P6130WO1
  • Relationships Relationships between entities in discrete dataclasses is forbidden, and thus each dataclass is wholly independent of other dataclasses. From a user's perspective, dataclasses may appear to be managed from separate dedicated applications. For example, the "contacts" dataclass can be managed primarily by an address book application, while the “calendars” dataclass can be managed by a calendar application.
  • the synchronization protocol 140 enables various synchronization modes including slow, reset and fast.
  • the first time a client device and a server sync all data for a dataclass are exchanged to "match" existing data items that are considered identical.
  • the client device and server should exchange only the data which has changed since the last time the pair synchronized.
  • each entity i.e., client device or server
  • each entity should be able to detect whether a situation has occurred which require exchanging more data before "fast" syncing can be resumed.
  • the slow sync mode may be required when the client device 1 10 and server 120 sync for the first time to establish a common baseline for subsequent difference-only data exchange.
  • the client device 1 10 sends all data for a dataclass to the server 120.
  • the server attempts to match these data items with those that are already known to the server 120. Failure to perform proper "identity matching" can result in duplicated data.
  • the server 120 then responds with data items missing at the client device 1 10.
  • the reset sync mode is used to reset all data for the dataclass on the client device with the server's data. This can occur when the data structure has been pushed to the device 1 10, or if the server 120 or device 1 10 determine that the device's local data is corrupt. The device 1 10 sends no data, and the server responds with the complete data structure for the dataclass.
  • the fast sync mode is the most efficient mode, especially when using a limited bandwidth connection. The client device 1 10 sends only those data that have changed since the last sync with the server 120. The server 120 responds with only those data that have changed external to the client device 1 10.
  • a synchronization session can follow a distinct set of phases including negotiation, pull, mingle, push, and commit. The terms, "pull” and “push” can be ATTORNEY DOCKET NO. 18814-104WO1 / P6130WO1
  • the client device 1 10 sends its local changes to the server 120 during the pull phase, and receives updates during the server's push phase.
  • both sides can exchange information from the previous sync session to determine what sync mode they agree to use for the current session.
  • a "sync anchor" is assigned to each sync session. If the client device 1 10 has previously synced with the server 120, the client device 1 10 likely expects a specific sync mode. The client device 1 10 may believe that it can fast sync with the server 120, but the server 120 may desire to reset the device.
  • synchronization can proceed to the pull phase.
  • the client device 1 10 sends its changed records (or if the sync mode is "slow", all records) to the server 120. Invalid changes may be rejected by the server 120.
  • the server 120 enters the mingle phase and merges any pending updates in its database with the changes from the client device 1 10.
  • the result of mingling is a set of conflicting changes and a set of updates which should be pushed to the client device 1 10.
  • the server 120 can automatically resolve all conflicts using a heuristic algorithm. In some implementations, it may be desirable for the client device 1 10 to resolve certain conflicts.
  • the synchronization protocol 140 can be designed to allow for conflicts to be represented and transmitted from the server 120 to the client device 1 10.
  • the synchronization protocol 140 can be designed to enable conflicts to be resolved on the client device by the user to be transmitted to the sync server 120.
  • updates from the server 120 are sent to the client device 1 10.
  • the commit phase is entered. Both sides (client device 1 10 and server 120) may agree that the sync was successful, persist their current sync anchors, and commit the exchanged data to their respective data stores.
  • either side may decide to cancel the sync and rollback any changes to the local datastore. Cancellation may occur explicitly in response to one or more of the following events: when unexpected or invalid data is sent; when the expected transitions in the sync state machine are not followed; when ATTORNEY DOCKET NO. 18814-104WO1 / P6130WO1
  • communications between the client device 1 10 and server 120 are interrupted; or when some other problems occur.
  • the difference in data can be synced in various granularities.
  • the client device 1 10 and the server 120 may send the complete data for each changed record for a record-level differencing (RLD).
  • RLD record-level differencing
  • FLD field- level differencing
  • FLD may be preferred over RLD, especially when data records include many fields, or contain large amounts of data, such as the images in the contact dataclass.
  • the server 120 can dynamically support both RLD and FLD representations of data received from the client device 1 10.
  • the data representation for the changes indicates whether the client device 1 10 is using RLD or FLD for a given dataclass. This provides client device datastore implementation with maximum flexibility when the complexity of maintaining meta information to support FLD is unreasonable.
  • the server 120 When receiving RLD changes, the server 120 internally converts the changes to FLD for processing, storage and communication efficiency.
  • the server 120 expects an RLD client device 1 10 to send complete records. Data fields that are supported by the client device 1 10 and are missing from the client device's data record are assumed to have been cleared/deleted by the client device 1 10. However, a mechanism can be provided to enable the client device 1 10 to indicate that certain data field exceptional values are unchanged without sending the values.
  • Identification (ID) mapping is another basic synchronization concept. Every synced datum has an universal unique record ID or UUID. For efficiency sake, the server 120 can use the UUIDs of the SyncService on Mac OS X.
  • an application on the client device 1 10 can use its local unique IDs (LUIDs) for data to promote local datastore efficiency, for example.
  • the server 120 enables the client device 1 10 datastores to use their own LUID to refer to data items as needed. In this case, the server 120 maintains a LUID to UUID mapping to enable the client device 1 10 to transparently reference global records by using its own local IDs. The server 120 reestablishes new mappings when a "slow" or "reset” sync mode is accepted for the dataclass.
  • the synchronization protocol 140 includes a sequence of messages exchanged between the server 120 and the device 1 10 using a transport protocol ATTORNEY DOCKET NO. 18814-104WO1 / P6130WO1
  • the synchronization protocol 140 includes the messages exchanged on the transport protocol 130.
  • the roles of the client device120 and server 130 in the synchronization protocol are distinct from their roles in the communications/transport protocol.
  • the device 1 10 is always a client with respect to the transport 130, and thus the device 1 10 makes requests only.
  • both the client device 1 10 and server 120 may issue message commands to each other.
  • the transport protocol 130 manages the exchange of messages between the server 120 and client device 1 10.
  • the transport protocol 130 can include HTTP transport or other suitable transports, such as Extensible Messaging and Presence Protocol (XMPP).
  • XMPP Extensible Messaging and Presence Protocol
  • the transport protocol 130 layer handles authentication, and thus the synchronization protocol 140 does not need to handle security/authentication processing. This enables the synchronization protocol 140 to function more efficiently and require few number of roundtrips.
  • Transport Layer Security TLS
  • the transport protocol 130 may perform message chunking.
  • the transport protocol 130 need not guarantee delivery or message ordering, as the synchronization protocol 140 has the necessary information to do so and to detect message loss.
  • the HTTP defines eight methods or "verbs" that indicate actions to be performed on a resource.
  • the HTTP methods includes: HEAD, GET, POST, PUT, DELETE, TRACE, OPTIONS and CONNECT.
  • the POST method is to be used.
  • the POST method submits data to be processed, such as data from an HTML form, to the identified resource.
  • the data is included in the body of the request.
  • the result of the POST method may result in the creation of a new resource or the updates of existing resources or both.
  • the server 120 can provide the OTA sync service on a URL, such as "http://sync. mac.com/ota”.
  • the "Content-Type” header should be "text/xml”.
  • the "Content-Type” header must be present and must be "application/octet-stream”.
  • the "Content-Length” header must indicate the size of the message.
  • the User- Agent string is used to identify the client protocol implementation.
  • the User-Agent string should be of the form: "Mobile/1 A543".
  • Devicelnfo method can be used to determine the device implementation version.
  • a session consists of an exchange of a number of protocol messages between the client device 1 10 and the server 120.
  • the HTTP transport implementation can use cookies to maintain a session with the server 120.
  • Either the client device 1 10 or the server 120 may indicate that the session is complete by setting a flag in a message header.
  • Each message contains a series of commands that can be processed by the recipient.
  • the client device 1 10 may be designated as the party that initiates the connection to the server 120.
  • the messages exchanged using the synchronization protocol 140 is represented as UTF-8 encoded OS X property lists (i.e. a dictionary.) This representation facilitates creation, serialization and parsing on both the client device 1 10 and the server 120.
  • the synchronization protocol 140 can support both Extensible Markup Language (XML) and binary representations of plists.
  • Binary plists can be 60% to 80% more compact than XML plists.
  • any binary data transmitted are serialized as base-64 encoded NSData objects and the text data are XML-escaped according to RFC 3076.
  • Each protocol message consists of two root elements: the header and the body.
  • FIG. 2 is a table illustrating example header elements 210.
  • the message header element 210 can include service, deviceid, version, userid, sequence, msisdn, final, result, etc.
  • the type 220 of the header element is also shown.
  • FIG. 2 also shows whether each header element 210 is required 230. Further, a short description 240 of each header element is provided in FIG. 2.
  • the header element 210 can identify the entity (e.g., client device 1 10 or server 120) sending the message, and can contain certain session control information.
  • the header element 210 is a required element of the message, and the ATTORNEY DOCKET NO. 18814-104WO1 / P6130WO1
  • header element is a dictionary.
  • Elements 210 in the header can indicate the source entity ("deviceid") and target service ("service”), target account ("userid”), and message sequence number (“sequence”), for example.
  • the "version” element can indicate the synchronization protocol version being used. For example, FIG. 2 shows in the description 240 column that the current version is "1 .0". These elements 210 should all be present in the message.
  • FIG. 2 also shows that the values of the header elements 210 service, deviceid, version, userid, sequence and msisdn are set as strings.
  • the value of the sequence element is a monotonically increasing integral value that starts at "1 " for a given session.
  • the sequence element is used to indicate message ordering for the session.
  • the value of the service element is a string that identifies the name of the target service, such as the sync server.
  • the value for userid element is a string that indicates the target account for the message.
  • the userid element can identify the principal that authenticated with the server 120 on the transport layer 130.
  • the deviceid for the client device 1 10 is a string that uniquely identifies the device hardware. For iPhone ® and iPod ® touch devices, the deviceid element can be the Integrated Circuit Card (ICCID) value.
  • Client devices 1 10 with a GSM radio may also send the msisdn element to indicate the phone number of the currently installed/active Security Information Management (SIM) card.
  • SIM Security Information Management
  • the final element is present in the header when the sender (e.g., the client device 1 10) considers its side of the session to be complete.
  • the final element is a Boolean with a value being TRUE.
  • the sender may then free any session related resources, and the recipient is not required to send another message.
  • the recipient may send another message to return outstanding command responses. However, the recipient should not send any further command requests.
  • the values for the userid and service elements should be constant for all messages in a given session.
  • the values for the deviceid element should remain constant for the sending entity. In other words, while the server 120 and the client device 1 10 may have different values, those values may not change.
  • the result element may be present in the header of a message to indicate the overall status for a message.
  • an S_OK status is implied for any message without a header status.
  • the result element is present in the header.
  • the message may not be accepted when the data is malformed, or when the recipient encounters a session fatal condition.
  • a non-OK status value indicates that the preceding message body was not processed, none of the message's commands were performed, and the session should be terminated.
  • a header status value of E BadRequest (703) indicates that the previous message was malformed.
  • a header status value of EJJmitExceeded (61 1 ) indicates that the previous message size exceeded the recipient's capability.
  • FIG. 3 shows an example plist 300.
  • the example plist 300 includes a header 310 and a body 320.
  • the header 310 includes various example header elements 312, 314, 316, 318 and 319.
  • an example deviceid element 312 having a string value of "f1234567a0745a890a86b5556d9e020202bRX8" is shown.
  • an example msisdn element having a string value of "14155338207" is shown.
  • an example sequence element having a value of "1 " is shown.
  • the plist 300 also includes an example service element with a string value of sync.
  • the plist 300 further includes an example version element with a string value of "1.0.”
  • the body of the message includes an array of command requests and/or command responses to be processed by the recipient.
  • the body element is a required element of the message, and the value of the body is represented as an array of command or command response dictionaries.
  • the body element may be empty when the sender has no commands to send. Commands in the body are processed in command sequence order.
  • Both the device 1 10 and the server 120 may send command requests and responses within the same message. This may depend on the state of the current session.
  • the commands in the synchronization protocol can fall into two general categories: (1 ) commands that affect the state of the sender, the recipient and the processing of other commands in the message or the session; and (2) commands ATTORNEY DOCKET NO. 18814-104WO1 / P6130WO1
  • Stateful commands begin with a "command family" prefix (e.g. "sync-" for all data synchronization commands).
  • the command family prefix also provides a useful command namespace mechanism that allows the server 120 to support an arbitrary set of services for different client devices 1 10.
  • the commands in a given "command family” are processed in series, and if any command returns a nonsuccess status, subsequent commands in that family may not be processed at all.
  • a command response with a status code that indicates that the command has not been processed e.g., E CommandNotProcessed
  • the recipient of a non-final message includes one or more command responses for each command in the session's next message.
  • the recipient of a final message includes one or more command responses for each command when the final message was sent on a transport layer request (i.e. a transport response is expected.)
  • the recipient of a final message may include one or more command responses for each command when the final message was sent on a transport layer response.
  • stateless primitive commands can be defined: "get”, “put” and "delete”. These stateless commands may be used to implement arbitrary object exchange or Representational State Transfer (RESTful) semantics within the synchronization protocol 140. This can be used, for example, to perform management actions, to transfer device settings or capabilities, or to reference binary large objects or other meta data without requiring the server 120 to perform data synchronization operations.
  • RESTful Representational State Transfer
  • FIG. 4 is a table showing example command elements included in a command request. Each command request or command response is represented by a dictionary. For a command request, various command elements 410 can be provided. The example command elements can include the "name” element, the "sequence” element and the "params” element. These command elements 410 should be present for all commands. The values 420 for the "name” and "sequence” ATTORNEY DOCKET NO. 18814-104WO1 / P6130WO1
  • elements are strings.
  • the value for the "params" element should be a dictionary.
  • a dictionary is a map of key/value pairs.
  • the keys are strings, and the values are other types, depending on the specific command.
  • the value type 420 is shown in the second column of the table.
  • the third column 430 indicates whether the command element is required. Further, a short description
  • the commands can assign an integral value to the sequence element that monotonically increases for each session.
  • the integral value can start at "1 " and monotonically increase for each session.
  • the recipient Based on the detected value of the sequence element, the recipient processes the commands in the sequence order.
  • the name element is a required element that indicates the command's name.
  • the value of the name element is a string.
  • Command requests use the params element to pass the parameters for the command to the recipient.
  • the params element is a required element having a value that includes a dictionary. Specific parameter elements and values may vary depending on the specific command as shown in FIG. 4.
  • FIG. 5 is a table showing example command response elements.
  • the command response elements include "name”, “sequence”, “params”, “more”, “result” and “response.”
  • a value type 520 is provided for each command response element.
  • the values of the name and sequence elements are strings, for example.
  • the value of the params element is a dictionary.
  • the values of the more and response elements are the Boolean value "TRUE", and the value of the result element is an array.
  • the third column 530 of the table shows whether the command response elements are required. In addition, for each command response, a short description
  • the name element describes the name of the command, such as "get.”
  • the sequence element for a command response corresponding to a command request should have an identical sequence value as the parent command request. Similar to the command, the ATTORNEY DOCKET NO. 18814-104WO1 / P6130WO1
  • params element is used by the command response to pass the parameters for the command response to the recipient.
  • the params element is a required element having a value that includes a dictionary. Specific parameter elements and values may vary depending on the specific command response as shown in FIG. 5. In addition, the command responses use the same parameter values as their associated command requests.
  • the response element indicates that a message body item is a command response. Absence of the response element indicates that the body is a command request. The value of the response element is a Boolean with the value "TRUE”.
  • Command responses use the sequence element assigned with integral values. As described above, the values assigned to the sequence element correspond to a command sequence previously sent by the recipient. The recipient processes the command responses in sequence order based on the sequence values. Normally, the sender sends exactly one command response per command received in a given message. However, if the status for the command response is S_NotCompleted (indicating that processing of the command has not yet completed), the sender may send another command response for the command in a subsequent message.
  • the result element is a required element included in the command responses.
  • the value of the result element is an array of one or more status items indicating the results of the command request.
  • S_NotCompleted 602
  • This status does not indicate success or failure of the command, but instead informs the sender of the command that results will be available later in the session.
  • a failure status such as E Failed staus is assumed.
  • Unknown command requests result in an unknown status value, such as E UnknownCommand (608). Also, unexpected commands for stateful commands result in a state error value, such as E_StateError (610).
  • E_StateError 610.
  • FIGS. 6, 7, 8, 9, 10, 1 1 , 12, 13, 14, 15, 16, 17, 18 and 19 are tables showing examples of commands and command definitions.
  • the synchronization protocol 140 defines these commands that are available to send during a sync session. This listing of commands is not an inclusive list. Additional commands can be added to scale and extend the synchronization protocol to provide other services. [00129] Primitive commands
  • the commands listed in FIGS. 6, 7, 8, 9, 10 and 1 1 are stateless commands that can modify an arbitrary resource on the recipient.
  • the available stateless commands include “get”, “put” and “delete”. These stateless commands can implement object exchange or RESTful semantics within the synchronization protocol 140.
  • Each command can include one or more parameters, such as “uri”, “value”, “item-type”, “items”, “idmap”, “userid”, “authtype”, “auth”, “version”, “anchors”, etc. Some of these parameters are required, while others are optional.
  • the "uri” parameter is a required parameter with a string value assigned.
  • the "uri” parameter can specify the desired resource to access.
  • the synchronization protocol 140 does not specify whether the "uri" parameter represents an actual resource on the client device 1 10 or server 120, for example a file system path or a virtual resource.
  • the type of the "value” parameter is determined by the client device 1 10 and the server 120.
  • the type of the "value” parameter is not specified by the synchronization protocol 140.
  • the logical type of the "value” parameter may be explicitly specified using the "item-type” parameter. Regardless, the representation of the "value” parameter must be a valid property list type.
  • the recipient may use the message's "userid” as the authorized principal for the purposes of limiting access to the indicated URI. If the session authorization is insufficient, the "userid” , "authtype” and “auth” elements may optionally be included in the command.
  • FIG. 6 is a table showing the get command with its associated parameters 610 that includes "uri”, “userid”, “authtype” and “auth”. Each of these parameters is assigned a string value 620. The table also shows whether any of the parameters are required 630. While the uri parameter is required (indicated by the check mark), the rest of the parameters may be optionally included with the get command. Also, the descriptions 640 of the parameters are provided.
  • the value of the uri parameter describes the URI of a data object to retrieve.
  • the value of the optional userid parameter describes whether to optionally override the message's userid.
  • the value of the optional authtype parameter can describe the optional authentication type.
  • the value of the optional auth string value can describe the optional authentication credential.
  • FIG. 7 is a table showing example parameters 710 for the get command response.
  • the example parameters include "uri", "value” and "item-type.”
  • the associated parameter value 720 is a string for these parameters.
  • the fourth column 730 shows that the uri and value parameters are required while the item-type is optional.
  • the descriptions 740 of the parameters are also shown.
  • the uri parameter of the get command response describes the URI of the data object requested by the get command.
  • the value parameter describes the value of the URI.
  • the get command enables the sender to request a desired data object or value from the recipient.
  • the recipient sends a get command response to the sender of the get command.
  • the get command response includes a value parameter to return the result value for the URI indicated by the get command.
  • the optional item-type parameter for the get command response describes the type of the value.
  • FIG. 8 is a table showing example parameters for the put command.
  • the put command enables the sender to transfer an arbitrary data object to the recipient.
  • the example parameters 810 include "uri”, “value”, “item-type”, “userid”, “authtype” and “auth”.
  • the table shows that each of these parameters 810 is assigned a string parameter type 820. Also, the tables show whether the parameters are required 830. For example, the uri and value parameters are required while the rest are optional.
  • the last column shows the description 840 of each parameter 810.
  • the value of the uri parameter represents the URI of the data object to replace.
  • the value parameter specifies the value to be put to the recipient.
  • the item-type parameter describes the logical type of the value.
  • the parameter describes whether to optionally override the message's userid.
  • the value of the optional authtype parameter can describe the optional authentication type.
  • the value of the optional auth string value can describe the optional authentication credential.
  • FIG. 9 is a table showing example parameters 910 for the put command response.
  • the recipient sends a put command response that includes the uri parameter.
  • the uri parameter is a required parameter as shown by the check mark in the fourth column 930.
  • the parameter type 920 is a string for the uri parameter. Similar to the put command, the uri parameter describes 940 the URI of the data object that was replaced in response to the put command.
  • FIG. 10 is a table showing example parameters for the delete command.
  • the delete command includes various parameters 1010 such as "uri", "userid”, "authtype” and "auth.”
  • the parameter type 1020 is a string for these parameters.
  • the uri parameter is required as shown by the check mark in the fourth column 1030.
  • FIG. 1 1 is a table showing an example parameter 1 1 10 for the delete command response.
  • the delete command response includes a uri parameter.
  • the table shows that the uri parameter type 1 120 is a string.
  • the uri parameter is required 1 130 and thus included in the delete command response.
  • the table also includes a description 1 140 of the parameters.
  • the string type uri parameter describes the URI of the object deleted in response to the delete command.
  • the commands listed in FIGS. 12, 13, 14, 15, 16, 17, 18 and 19 are stateful commands.
  • the synchronization protocol 70 also provides stateful sync- family commands and command responses.
  • the stateful command includes sync- start, sync-changes, sync-commit and sync-cancel. These stateful commands enable structured data synchronization between the protocol client device 1 10 and server 120.
  • Each of the stateful commands and command responses include the "uri" parameter to identify a dataclass state machine to be affected by a given command.
  • FIG. 12 is a table showing example parameters 1210 for the sync-start command.
  • the sync-start command enables the creation of a sync state machine ATTORNEY DOCKET NO. 18814-104WO1 / P6130WO1
  • the example parameters 1210 include "uri” and “anchors.”
  • the parameter type 1220 is a string for the uri parameter.
  • the parameter type 1220 is a dictionary for the anchors parameter.
  • the "uri” and “anchors” parameters are required parameters as shown by the check mark in the third column 1230.
  • the table also includes a description 1240 for each parameter.
  • the uri parameter indicates the dataclass names, such as the string "com. apple. Contacts” for contacts or the string "com. apple. Calendars” for calendars.
  • the status E NotSupported 612
  • the status E NotAllowed 604
  • the status "param- name” element should be present and should have the value "uri” to indicate that the uri parameter was the cause of the returned status.
  • the anchors parameter contain information used during the sync negotiation phase. The information can include the requested sync mode ("mode”); the datastore versions ("device_version”,"server_version”); and sync anchors
  • the “device_version” parameter for the anchor element describes the version of the client device 1 10.
  • the “server version” parameter for the anchor element describes the version of the server process 120.
  • the anchors parameter can include device, server, filter and reset anchors.
  • the anchors can be used to request a sync mode.
  • the default sync mode is the fast sync mode.
  • the anchors can be used to specify a sync direction.
  • the default sync direction is "twoway", which indicates that changes will be sent from the client device 1 10 to the server process 120 as well as from the server process 120 to the client device 1 10.
  • FIG. 13 is a table that shows example parameters for the sync-start command response.
  • the example parameters 1310 for the sync-start command response can include the "uri” and “anchors” parameters.
  • the parameter types 1320 for the uri and anchors parameters are a string and a dictionary respectively. The table also shows whether these parameters are required parameters 1330. The descriptions 1340 of the parameters are also shown in the table.
  • the uri parameter describes the dataclass names, such as contacts, calendars, etc.
  • the anchors parameter can be provided for the client device 1 10, server 120, filter and reset. In addition, the anchors parameter can be used to indicate the requested sync mode, ATTORNEY DOCKET NO. 18814-104WO1 / P6130WO1
  • the recipient When the recipient is willing to sync using the submitted information, the recipient returns a OK status S_OK (600) with the sync-start command response. When the recipient is willing to sync with adjusted parameters (e.g. using a different sync mode than the client requested), the recipient returns a failed-negotiation status, such as E NegotiationFailed (613). When the recipient does not support the supplied sender's version (e.g. "device_version”) the recipient returns a status, such as the E VersionNotSupported (612) status to indicate that the version is not supported. When the recipient does not support the desired sync direction (e.g.
  • the recipient returns a status, such as the E NotSupported (614) to indicate that desired sync direction is not supported.
  • the status includes the "param-name” parameter with the value “anchors” indicating that elements in the "anchors” parameter of the command were the cause of the unsuccessful status.
  • the recipient can indicate the desired sync mode and anchors in the command response's "params” dictionary.
  • the server 120 When the server 120 accepts the "sync-start" command received from the client device 1 10, the client device 1 10 begins sending "sync-changes" commands. Sending the "sync-start” command during a session which has already started syncing results in a state error status such as E StateError (610) status.
  • a state error status such as E StateError (610) status.
  • commands for each dataclass operate on distinct state machines. Usually, the server 120 waits until all dataclasses have completed the pull phase or cancelled before mingling the changed data.
  • FIG. 14 is a table showing example parameters for the sync-changes command.
  • the parameters 1410 can include "uri”, “itemtype”, “items”, “anchors” and "idmap.”
  • the parameter type 1420 for the uri and itemtype parameters is a string.
  • the parameter type for the anchors, items and idmap parameters is a dictionary.
  • the table shows in column four 1430 that the uri, itemtype and items parameters are required while the idmap and anchors are optional.
  • the table also includes descriptions 1440 of these parameters.
  • the uri parameter describes the dataclass ATTORNEY DOCKET NO. 18814-104WO1 / P6130WO1
  • the itemtype parameter describes type of the item or data identified in the sync-changes command.
  • the items parameter describes a dictionary of items, such as format/type that depends on the itemtype.
  • the associated keys for the items parameter can be device recordids.
  • the idmap parameter describes a dictionary of GUID-LUID pairs.
  • the associated keys are server record ids and the values are device record ids.
  • the anchors parameter may be included as a "checkpoint anchor". When present, the receiver updates its anchors with the supplied value. Should the session become interrupted, the recipient may start a subsequent sync session with the check point anchors and continue to sync normally without falling into slow sync mode.
  • the sync-changes command enables the client device 1 10 to send changes to the server 120.
  • the server 120 can send updates to the client device 1 10.
  • the uri parameter indicates the dataclass of the data items to be updated or changed.
  • the type of data item being sent is indicated by the itemtype parameter.
  • the itemtype parameter can indicate that the item parameter represents either full records ("records") or field-level changes ("changes").
  • data items are keyed by the device LUID in the items parameter.
  • the format of the dictionaries for the items parameter depends on the item-type.
  • the values of the items parameter are of homogeneous item-type.
  • the items parameter can be an empty array to indicate that no more items need to be sent. For example, the empty array can indicate that there are no changes, or there are no records.
  • the client device 1 10 When detected that there are no device changes or the sync mode is "reset", the client device 1 10 sends a "sync-changes" command with an empty array for the "items" parameter.
  • the "more” Boolean flag element is also included if all appropriate data items for the dataclass are not included in the command params.
  • the "more” Boolean flag element can be used to break up large amounts of synchronization data into smaller chunks. This is useful when the size of the data to be exchanged is larger than the capability of the recipient. For example, the recipient may have message size limitations.
  • the "more" Boolean flag element can enable exchange of multiple item-types for a given dataclass in a single session.
  • the server 120 When the server 120 has received the last "sync-changes" chunk for all dataclasses from the client device 1 10, the server 120 synchronizes all supplied data with the central database. Then the client-server roles within the protocol session ATTORNEY DOCKET NO. 18814-104WO1 / P6130WO1
  • the client device 1 10 begins processing commands from the server 120.
  • the client device 1 10 can also return command responses to the server 120. Any synchronization data updates from the server are then sent in "sync- changes" commands.
  • the server 120 sends a "sync- changes" command with an empty array for the "items” parameter.
  • the client device 1 10 responds to these commands, and includes any required mapping information for add transactions in the command response's "params" using the "idmap” parameter.
  • the "idmap” parameter is sent in a "sync-changes" command from the client device to update existing mappings.
  • id mappings may be updated independent of the server 120 changing the data entities.
  • the device 1 10 may omit sending "sync-changes” command response and defer sending the "idmap" parameter until the "sync-changes" command of the subsequent sync session. This may be done in order to reduce the number of transport roundtrips necessary to complete the sync session.
  • FIG. 15 is a table showing example parameters for the sync-changes command response.
  • the parameters 1510 includes "uri”, "anchors” and 'idmap.”
  • the table includes the parameter types 1520 for these parameters.
  • the uri parameter is a string type and the anchors and idmap parameters are dictionaries.
  • the table also includes an indication of whether the parameters are required 1530.
  • the uri parameter is required while the anchors and idmap parameters are optional.
  • the table also includes descriptions 1540 of these parameters.
  • the uri parameter indicates the dataclass for the requested changes.
  • the anchors parameter is checkpoint anchors used to indicate specific points where the last sync session left off.
  • the idmap parameter is a dictionary of GUID-LUID pairs with keys that include server record ids. The values of the keys can include device record ids. [00151] FIG.
  • the 16 is a table showing example parameters for the sync-commit command.
  • the parameters 1610 for the sync-commit command include "uri" and “anchors.”
  • the sync-commit command is used to commit the sync operation.
  • the command indicates that the sender has already committed and is telling the recipient to commit as well.
  • the table shows whether the parameters are required 1630. For ATTORNEY DOCKET NO. 18814-104WO1 / P6130WO1
  • the "uri” parameter is required while the anchors parameter is optional.
  • the table also shows the parameter type 1620 for the parameters.
  • the uri parameter is a string type, and the anchors parameter is a dictionary.
  • the table also shows the descriptions 1640 of the parameters.
  • the uri parameter indicates the dataclass to commit the sync changes.
  • the anchors parameter is used by the client device 1 10 to send "next_device_anchor" for the server 120 to store.
  • the server 120 sends the "next_server_anchor” to the device 1 10 in the sync-commit command.
  • the sync mode to use in the next sync is indicated and returned in the sync-commit command.
  • FIG. 17 is a table showing example parameters for the sync-commit command response.
  • the parameter 1710 includes the "uri” parameter.
  • the parameter type 1720 for the uri parameter is a string.
  • the uri parameter is a required parameter that is included in the sync-commit command response.
  • the description 1740 of the uri parameter shows that the uri parameter indicates the dataclass committed during the sync session.
  • the device 1 10 may omit sending "sync-commit" command response in order to reduce the number of transport roundtrips necessary to complete the sync session.
  • the server 120 can infer that the previous "sync-commit” was received.
  • FIG. 18 is a table showing example parameters for the sync-cancel command.
  • the sync-cancel command is used to cancel the sync operation.
  • the sync-cancel command indicates that the sender has already cancelled and is telling the recipient to cancel as well. The recipient should rollback any changes it has made for the dataclass to the state represented by the last received sync anchor.
  • the table shows that the parameters 1810 for the sync-cancel command include the "uri" parameter and the anchors parameter.
  • the parameter type 1820 for the uri parameter is a string and the anchors parameter is a dictionary.
  • the table also shows in column four 1830 whether the parameters are required.
  • the uri parameter is required while the anchors parameter is optional.
  • the table also shows the descriptions 1840 of the parameters.
  • the uri parameter indicates the dataclass to cancel the sync.
  • the anchors parameter may be used to specify the anchors and/or ATTORNEY DOCKET NO. 18814-104WO1 / P6130WO1
  • the device 1 10 may omit sending "sync-cancel" command response in order to reduce the number of transport roundtrips necessary to complete the sync session.
  • the server 120 can infer that the previous "sync-cancel" was received.
  • FIG. 19 is a table showing example parameters for the sync-cancel command response.
  • the available parameter 1910 for the command response includes the "uri" parameter.
  • the parameter type 1920 for the uri parameter is a string.
  • the table also shows in the fourth column 1930 an indication of whether the parameter is required.
  • the uri parameter is required to be included in the command response as indicated by the check mark.
  • the table also includes a description 1940 of the uri parameter.
  • the uri parameter indicates the dataclass to cancel the sync.
  • FIG.20 is a table showing example status elements.
  • the example status elements are show in the first column 2010 with the corresponding values shown in the second column 2020.
  • the third column 2030 of the table shows whether the status element is required.
  • the last column 2040 of the table shows a short description for each status element.
  • the status resulting from the processing of a given command or message is represented by the "status" element.
  • a single status element may appear in the message header. When the message was not processed, the corresponding status element is included in the message header.
  • An array of "status” elements is included in the "results” parameter of command responses.
  • Status elements indicate the results of a command request.
  • a status item is a Dictionary.
  • the dictionary may contain the "status” element and contain the "code” elements to indicate the result status of the corresponding command request.
  • the value for the "status” element is a string.
  • the value for the "code” element includes an integer string or an integer.
  • the “description” element is an optional element that may be present in the command.
  • the value of the “description” element is a string.
  • the “description” element is purely informational and has no ATTORNEY DOCKET NO. 18814-104WO1 / P6130WO1
  • the "param-name”, "param-key” and “param-index” elements MAY be present. They are used to provide multi-status responses for certain commands.
  • the " param-name” value MUST be a String and indicates to which parameter in the command request this Status item corresponds.
  • the "param-index” value MUST be either a String or an Integer. It MUST be present if the "param-name” element is present and it's value in the command request was an Array.
  • the value of the "param-index” indicates the index of the "param-name” item in the command request to which this Status item corresponds. Index values are zero-based.
  • the "param- key” value MUST be a String.
  • the value of the "param-key” indicates the value of the key of the "param-name” item in the command request to which this Status item corresponds.
  • the "param-name” "param-key” and “param-index” elements may also be present. They are not required elements and can be used to provide multi-status responses for certain commands.
  • the value of the "param-name” status element is a string that indicates to which parameter in the command request this status element corresponds.
  • the value of the "param-index” element can be either a string or an integer.
  • the "param-index” status element is included in the status dictionary when the "param-name” status element is present and the value of the parameter matching the value of the "param-name” status element in the command request was an array.
  • the value of the "param-index” status element indicates the index in the array parameter item for the parameter whose name corresponds to the value of the "param-name” status element in the command request to which the status element corresponds.
  • the value of the index status element is zero-based.
  • the value of the "param-key” element is a string that indicates to which parameter in the command request this status element corresponds.
  • the value of the "param-key” status element is a string.
  • the "param-key” status element is included in the status dictionary when the "param-name” status element is present and the value of the parameter matching the value of the "param-name” status element in the command request was a dictionary.
  • the value of the "param-index" status element indicates the key in the dictionary parameter item for the parameter whose name corresponds to the value of the "param-name” status element in the command request to which the status element corresponds.
  • the indices in a status refer to the index of the param which resulted in the status, if the original param was an Array. Indices start counting from a zero-basis.
  • This zero-basis mechanism enables the a sparse array of statuses to be returned.
  • examplecommand For example, consider a command (named “examplecommand") shown below that has a parameter "items" which is an array. Suppose that all but two of the items in the command are well formed with the second and fifth items having values ("bad").
  • a sparse array of statuses may be represented by including a status, such as S_MultiStatus (601 ) as the first element of the status array.
  • Subsequent status elements may then indicate the parameter index value and a distinct status for any failed parameter elements for which the parameter type was an array.
  • subsequent status elements may indicate the parameter key value and distinct status for any failed parameter elements for which the parameter type was a dictionary.
  • Status codes in a certain range such as the status code range 600-699 can be reserved for general statuses.
  • Status codes in another range such as the range 700-799, can be reserved for errors returned by the server and generally lead to termination of the current session.
  • FIG. 21 is a table showing example status codes for the statuses available to be included in the commands and the command responses.
  • the first column 21 10 describes the available statuses.
  • the associated status codes are shown in the second column 2120.
  • the third column 2130 shows a description for each status.
  • the last column 2140 shows the parent element or parameter for each status.
  • the table describes success statuses and error statuses.
  • the "S_OK" status is assigned the code 600 to indicate a success.
  • the parent element may be a message header or command response.
  • the other success status is the "S-MultiStatus" status assigned to code 601 to indicate a success with multi-valued statuses.
  • the parent element is a command response.
  • the error statuses include the "E-NotCompleted" status assigned to code 602 to indicate that command processing for the command has not yet completed.
  • the parent element is a command response.
  • the "E NotFound” error status is assigned to code 603 to indicate that the indicated data object or URI was not found.
  • the parent element is a command response.
  • the "E NotAllowed” error status is assigned to code 604 to indicate that the operation is not permitted that may be due to insufficient access rights, for example.
  • the parent element is a command response.
  • the "E MissingParam” error status is assigned to code 605 to indicate that the command was missing a required parameter.
  • the "E ParamError” error status is assigned to code 606 to indicate that a supplied parameter was incorrect.
  • the parent element is a command response.
  • the "E BadValue” error status is assigned to code 607 to indicate that a bad value was supplied.
  • the parent element ATTORNEY DOCKET NO. 18814-104WO1 / P6130WO1
  • the "E UnknownCommand” is assigned to code 608 to indicate that an unknown command was issued and ignored.
  • the parent element is a command response.
  • the "E CommandNotProcessed” error status is assigned to code 609 to indicate that a command was not processed due to errors processing a previous command.
  • the parent element is a command response.
  • the "E StateError” is an error status assigned to code 610 to indicate that an unexpected command was received based on the command family's current state machine.
  • the parent element is a command response.
  • the "EJJmitExceeded” error status is assigned to code 61 1 to indicate that too many items were supplied.
  • the parent element is a command response.
  • the "E VersionNotSupported” error status is assigned to code 612 to indicate that the protocol or command version is not supported.
  • the parent element is a message header or command response.
  • the "E NegotiationFailed” error status is assigned to code 613 to indicate that the sync mode negotiation failed.
  • the parent element is a command response.
  • the "E NotSupported” error status is assigned to code 614 to indicate that an unsupported or unimplemented operation was attempted.
  • the parent element is a message header or command response.
  • the "E Failed” error status is assigned to code 615 to indicate a generic failure.
  • the parent element is a message header or command response.
  • the "E Canceled” error status is assigned to code 616 to indicate that the current state machine has been cancelled.
  • the parent element is a command response.
  • the "E ServiceBusy” error status is assigned to code 700 to indicate that the server 120 is too busy and could not process the message. This status code also indicates that the device 1 10 should retry the command again soon.
  • the parent code is a message header.
  • the "E ServiceUnavailable” error status is assigned to code 701 to indicate that the serve 120 is unavailable and could not process the message. This status code also indicates that the device 1 10 should retry again soon.
  • the parent element is a message header.
  • the "E ServiceError” error status is assigned to code 702 to indicate that the server 120 had an internal error.
  • the parent element is a message header or command response.
  • the "E BadRequest” error status is assigned to code 703 to indicate that the server 120 could not understand the message.
  • the parent element is a message header.
  • the "E RetryLater” error status is assigned to code 704 to indicate that the server 120 needs the client device 1 10 to retry at a later time.
  • the parent element is a message header. ATTORNEY DOCKET NO. 18814-104WO1 / P6130WO1
  • FIG. 22 is a table showing the effects of receiving a given status for a command.
  • the indicator “C” indicates that a failure for that command receiving the status only.
  • the indicator “F” indicates a termination of the command family state machine.
  • An example of the termination of the state machine for "sync” commands is an indication that a “sync-cancel" is forthcoming.
  • the indicator “M” indicates that the message was not processed.
  • the indicator "S” indicates that the session will terminate.
  • the effect of receiving the "E NotFound” error status is a failure for the get, put and delete commands.
  • sync-start sync-changes, sync-cancel and sync-commit commands
  • the dataclass state machine is terminated.
  • the effect of receiving the "E NotAllowed” error status is a failure for the get, put and delete commands.
  • sync-start sync-changes, sync-cancel and sync-commit commands
  • the dataclass state machine is terminated.
  • the effect of receiving the "E MissingParam” error status is a failure for the get, put and delete commands.
  • sync-start sync-changes, sync-cancel and sync-commit commands
  • the dataclass state machine is terminated.
  • the message is not processed.
  • the effect of receiving the "E Param Error” error status is a failure for the get, put and delete commands.
  • the effect of receiving the "E BadValue” error status is a failure for the get, put and delete commands.
  • For the sync-start, sync-changes, sync-cancel and sync-commit commands the dataclass state machine is terminated.
  • the message is not processed.
  • the effect of receiving the "E UnknownCommand" is a failure for the get, put and delete commands.
  • the dataclass state machine For the sync-start, sync-changes, sync-cancel and sync-commit commands, the dataclass state machine is terminated.
  • the effect of receiving the "E CommandNotProcessed” error status is a failure for the get, put and delete, sync-start, sync-changes, sync-cancel and sync-commit commands.
  • the effect of receiving the "E StateError” error status is that for the sync-start, sync- changes, sync-cancel and sync-commit commands, the dataclass state machine is terminated.
  • the effect of receiving the "E LimitExceeded” error status is a failure for the get, put and delete commands.
  • the effect of receiving the "E Canceled” error status is that the dataclass state machine is terminated for the sync-start, sync-changes, sync-cancel and sync- commit commands.
  • the effect of receiving the "E ServiceBusy” error status is that the session will be terminated.
  • the effect of receiving the "E ServiceUnavailable” error status is that the session will be terminated.
  • the effect of receiving the "E ServiceError” error status is that the session will be terminated for all commands.
  • the effect of receiving the "E BadRequest” error status is that the session will be terminated.
  • the effect of receiving the "E RetryLater” error status is that the session will be terminated.
  • Synchronization state information such as the sync mode, sync direction, agent versions, and sync anchors are exchanged between the device and server at various times.
  • the “anchors” element is implemented as a Dictionary.
  • FIG. 23 is a table showing example keys for the anchors element.
  • the table includes columns that show examples of sync anchor keys 2310, the associated key types 2320 and descriptions 2330 of the keys.
  • the "mode” key represents the desired or negotiated sync mode.
  • the mode key can optionally be present in the anchors element. When present, the value of the mode key is implemented as a String, and the string value includes "slow", "fast", or “reset” to represent the sync mode. When the value of the mode key is not present, the receiver of the message infers the value to be "fast”. Thus, in absence of the mode key value indicated by the sender, the fast sync mode is assumed by the recipient.
  • the "direction" key represents the desired or negotiated sync direction. ATTORNEY DOCKET NO. 18814-104WO1 / P6130WO1
  • the value of the direction key can optionally be present in the anchors element.
  • the value of the direction key is implemented as a String, and the string value can include "to_server”, “to_device”, or "twoway”.
  • these values indicate the sync direction as syncing from the device 1 10 to the server 120, syncing from the server 120 to the device 1 10 or both.
  • the receiver infers the value as "twoway.
  • the "device_version" key is sent by the device 1 10 and represents the device datasource agent version. When present, the value of the device_version key is implemented as a String. This information can be used by the server 120 to infer behaviors or capabilities specific to a given version of the device software. The server 120 can determine that synchronization is not permitted with a given device agent version, for example.
  • the "server version" key is sent by the server 120 and represents the server's datasource agent version.
  • the value of the server version key is implemented as a String. This information can be used by the device 1 10 to infer behaviors or capabilities specific to a given version of the server software. The device 1 10 can determine that synchronization is not permitted with a given server agent version, for example.
  • the actual anchors are exchanged using the keys "last_device_anchor”, “next_device_anchor”, “last_server_anchor” and “next_server_anchor”.
  • the value for each of these keys can be present in the "anchors" dictionary. When present, the value for each of these keys is implemented as a String. When not present, the recipient infers the last known value for the keys.
  • the client device 1 10 When the client device 1 10 sends the differences (i.e., the changed, deleted or new data) to the server 120, the client device 1 10 indicates whether “record level differences” (RLD) or “field level differences” (FLD) is used via the "item-type” parameter of the “sync-changes” command.
  • the value "change” in the "item-type” parameter indicates FLD, while the value "record” indicates RLD.
  • Devices that support RLD send the entire data set for a given changed record for a ATTORNEY DOCKET NO. 18814-104WO1 / P6130WO1
  • the "idmap" parameter can be included in the command or the command response for a "sync-changes" command from the server 120.
  • the value of the "idmap” parameter is a dictionary that maps server universal unique identifications (UUIDs) to client device 1 10 local unique identifications (LUIDs). Thereafter, the server 120 refers to the mapped entity using the client device 1 10 LUID.
  • the synchronization protocol 140 enables recovery from broken sessions without falling out of "fast” sync. By maintaining "fast” sync even in the event of a broken session, the number of communication round trips are reduced. The reduced number of roundtrips can reduce or minimize message/packet loss. [00187]
  • the synchronization protocol 140 is designed to minimize the number of transport messages (HTTP request/response roundtrips) in normal circumstances. The ability to remain in "fast" sync mode can minimize the bandwidth usage and effort for each sync process by exchanging smaller amounts of data.
  • frequent fast syncs mean the device 1 10/server 120 pair never drift much from one another. In other words, the device 1 10 and the server 120 remain more in sync than possible without fast sync. Also, this wireless "trickle syncing" can yield a better user experience.
  • Certain events can cause a fast syncing pair (e.g., client device 1 10 and server 120 pair) to resort to a less efficient sync mode (e.g., slow sync mode).
  • These events can include device data corruption, interrupted sync sessions, failure to agree on consistent sync anchors, data structure reset (e.g., when a user pushed an entirely new data set for the dataclass from another machine).
  • the synchronization protocol 140 can avoid being pessimistic and minimize ore eliminate ATTORNEY DOCKET NO. 18814-104WO1 / P6130WO1
  • the synchronization protocol 140 implements various techniques to optimize data sync between the client device 1 10 and the server 120.
  • optimization techniques include sync phase compression that enables optimistic negotiation and commit; implementing multiple dataclass state machines in parallel; using sync anchor checkpoints; and enable session robustness.
  • FIG. 24 shows an example of a sync session.
  • a sync session between the client device 1 10 and the server 120 includes exchange of various messages 2410, 2420, 2430, 2440, 2450 and 2460.
  • message 1 2410 is sent by the sender to the recipient.
  • the sender is the client device 1 10 and the recipient is the server 120.
  • Message 1 2410 includes the sync- start command to negotiate a sync mode for the sync session.
  • the recipient sends message 2 2420 that includes a command response, such as sync-start command response.
  • the command response includes a status to indicate whether the command included in message 1 2410 was successful, failed, etc. End the end of message 2 2420, a first round trip is concluded.
  • additional messages n, n+1 , n+2, etc. can be exchanged to complete a sync session.
  • the sync session can end at the receipt of the final message n+1 , for example.
  • additional optional messages 2450, 2460, etc. can be exchanged.
  • FIG. 25 shows an example of an optimal fast or reset data sync between the client device 1 10 and the server 120.
  • Sync phase compression enables the client device 1 10 to compress distinct sync state machine phases. For example, when the client device 1 10 believes the likely sync mode will be "fast” or “reset", the client device 1 10 sends negotiation ("sync-start") and pull phase commands ("sync- changes") in the first message 2510 to the server 120.
  • Sync phase compression can minimize or eliminate wasted network traffic in case the server 120 rejects the requested sync mode.
  • the client device 1 10 sends a first message 2510 that includes the "sync-start" and "sync-change" commands.
  • the server 120 may not send a "sync-commit" command in the second message 2520. Instead, the server 120 sends a "sync-start” response, a “sync- changes” response, and a “sync-changes” command in the second message 2520. In the second round trip 2530, the client device 1 10 sends a sync-change response and a "sync-commit” command. The server 120 responds with a "sync-commit" ATTORNEY DOCKET NO. 18814-104WO1 / P6130WO1
  • FIG. 26 shows another example of an optimal fast or reset sync between the client device 1 10 and the server 120.
  • the client device 1 10 sends negotiation ("sync-start") and pull phase commands ("sync-changes") in the first message 2610 to the server 120.
  • the sync-start negotiation command can include parameters that indicate the dataclass, the anchors and the sync mode.
  • the fast sync mode is indicated.
  • the sync server 120 compresses the push and commit phases by sending its "sync-changes" and "sync-commit" commands for a given dataclass in the same message.
  • the server 120 replies with a sync-start command response (OK, dataclass, anchors) and sync-change command response (OK, dataclass) in the second message 120.
  • the server 120 can include a sync-changes command (dataclass, changes) and a sync-commit command (dataclass anchors) in the second message 2620 to complete one round trip.
  • the optimistic approach can complete data synchronization in a single HTTP roundtrip.
  • a data sync can be completed in two roundtrips when the client device 1 10 responds to the server's 120 "sync-changes" command in the second message 2620 with an optional message for id mapping in the second round trip 2630.
  • the client device 1 10 can also send a sync-commit response in the optional message.
  • the client device 1 10 may defer sending id mappings to the server 120 until a subsequent session and may omit sending the sync-commit response, since the server 120 can infer that the commands were received and processed by comparing the sync anchors sent in the subsequent session.
  • FIG. 27 shows an example data synchronization between a client and a server, where the device omits sending the command response to "sync-changes" or “sync-commit” when the server's previous message was final. In that case, any pending id mappings (if necessary) is sent to the server 120 in the subsequent sync session.
  • the client device 1 10 compresses the negotiation and pull phases as described with respect to FIG. 25.
  • the server 120 sends a second message 2720 with the push and commit phases compressed as described with respect to FIG. 26.
  • the first session is completed in ATTORNEY DOCKET NO. 18814-104WO1 / P6130WO1
  • a second sync session is initiated by the client device 1 10 with the pull and negotiation phases compressed in the third message 2730.
  • the pending id mappings leftover from the first session is sent to the server 120.
  • the server 120 responds in the fourth message 2740 with sync-changes and sync- commit commands.
  • FIG. 28 illustrates an example of a slow sync.
  • the client device 1 10 believes the next sync mode will be "slow" sync mode, the client device 1 10 does not compress the negotiate and pull phase because sending it's entire data set in the initial request message 2810 to the server 120 can be expensive with respect to processing cost, for example.
  • sending the data would have been wasted bandwidth.
  • the client device 1 10 sends a sync-start command with the dataclass, anchors and the slow sync mode identified in the first message 2810.
  • the server 120 responds in the second message 2820 with a sync-start response.
  • the client device 1 10 sends a sync-changes command for a dataclass.
  • the server 120 responds in the next message 2840 by including a sync-changes response (OK, dataclass), sync- changes command (dataclass) and sync-commit command (dataclass, anchors).
  • the client device 1 10 sends a sync-changes response (OK, dataclass, idmap) and a sync-commit response (OK).
  • FIG. 29 shows an example of syncing multiple data classes in parallel.
  • Implementing multiple dataclass state machines in parallel (“parallelism") enables multiple dataclasses to sync in parallel.
  • Each dataclass as specified by the "uri” required parameter in all "sync” family commands, operates its own distinct state machine.
  • all dataclasses can fast sync in a single transport roundtrip.
  • other synchronization protocols such as Open Mobile Alliance - Data Synchronization protocol (formerly known as the SyncML protocol) OMA DS/SyncML sync in series and can require 5 or more roundtrips per dataclass.
  • the client device 1 10 also sends sync-changes command for the multiple dataclasses.
  • the server 120 sends a response 2920 with sync-start responses and sync-changes responses for the multiple dataclasses.
  • the sync-start response from the server 120 states that the calendars dataclass is reset on the server 120 due to a failed negotiation.
  • the sync-changes response for the calendars states that the changes have not been processed for the calendars dataclass.
  • the sync-start commands for contacts and bookmarks are successful as shown by the OK status of the sync-start response.
  • the sync-changes commands for contacts and bookmarks have not completed, as shown by the S_NotCompleted status of the sync-changes responses.
  • the client device 1 10 sends another sync-start command requesting a reset sync (the sync mode requested by the server in the previous calendars sync-start command response) and sync-changes command for the calendar dataclass with an empty items parameter.
  • the server 120 responds in the next message 2940 with a sync-start response and a sync-changes response for the contacts, calendars and bookmarks dataclasses; a sync-changes response for the contacts and bookmarks; sync changes command for calendars indicating that more changes are pending; and sync-commit command for contacts and bookmarks.
  • the third round trip begins with a message 2950 from the client device with sync-changes response for contacts, calendars and bookmarks.
  • the message 2950 includes sync-commit responses for the contacts and bookmarks.
  • the server 120 sends a sync-changes command for dataclasses and sync-commit commands to the client device 1 10 in the next message 2960.
  • multiple dataclasses syncing, sync mode renegotiation (calendars were reset on the server), and split sync-changes (calendar changes from the server were sent in message 2940 and message 2960) can be completed.
  • An optional fourth roundtrip 2970 can be implemented to enable the client device 1 10 to send a sync-changes response for the calendars with idmap and a sync-commit response to the server 120.
  • the server 120 does not perform the mingle phase until all dataclasses have completed the pull phase (i.e. upon receipt of the third message). This enables the server 120 to perform all work in a single sync job.
  • the server sends S_NotCompleted for the dataclasses other dataclasses until all the client 1 10 changes for all dataclasses has been received by the server 120.
  • the synchronization protocol uses the "sync anchors" parameter in the commands and command responses to organize and maintain trackable sync sessions.
  • the server 120 can manage the anchors in the commands and the command responses vis-a-vis its internal versioning methods.
  • Sync anchors are opaque data that the client device 1 10 and the server 120 exchange during the sync process.
  • the anchors can be exchanged during the negotiation phase to determine the sync session's sync mode. Then, during the commit phase, a new set of anchors can be exchanged and persisted for use during the following sync sessions.
  • other sync protocols use the anchors at the beginning of the sync session, and the anchors are updated only when the sync session completes successfully, or are rolled back if the session is cancelled or terminates unexpectedly.
  • anchor mismatch Any discrepancy between expected and actual anchors during negotiation (known as anchor mismatch) can result in a slow sync, or at the very least, retransmission of all data from the failed sync session. On an unreliable data- network, this can lead to a situation where no progress can be made and synchronization with the server is effectively blocked from successfully completing a sync until external conditions change. Unexpected session failures can also lead to anchor mismatches on the next sync session.
  • the OTA synchronization protocol 140 enables the server 120 to optionally return updated anchors at various checkpoints during a sync session.
  • the "anchor" parameter may be present in any sync family command or command response.
  • a checkpoint anchor contains the "next_server_anchor” element and may contain the "mode” element. This enables fine-grained updating of sync anchors to reduce the likelihood and impact of anchor mismatches.
  • Each server anchor is encoded with information that provides the server 120 with precise information regarding the internal server state at the time the anchor was generated. For example, the server anchor can be encoded with information on whether the ATTORNEY DOCKET NO. 18814-104WO1 / P6130WO1
  • Example anchor checkpoints can include the "end of server mingle phase" in response to the client device's final “sync-changes" command.
  • the anchor checkpoints can also include the point during a split "sync-changes" and the commit phase among others.
  • the server 120 can intelligently decide the time and location to add the checkpoint anchors.
  • the checkpoint anchors guarantee that the received data set enforces the data integrity requirements of the dataclass's schema.
  • the data integrity requirements can include having no references to unknown entities in a check pointed data set.
  • the most recent checkpoint anchors may be saved by the client device 1 10, even if the sync session is cancelled.
  • the sync server 120 will expire the checkpoint anchors when they are no longer needed, or when the server needs to release associated server-side resources used to maintain the checkpoint state. When the client device 1 10 supplies an unknown or expired checkpoint anchor, the sync session will still fall into slow sync mode.
  • FIG. 30 shows an example sync session that uses checkpoint anchors.
  • the client device 1 10 initiates a sync session by sending a message 3010.
  • the client device 1 10 uses an anchor, a ⁇ , in the message 3010.
  • This anchor, aO can be the last server anchor value from the previous sync session.
  • the client device 1 10 ATTORNEY DOCKET NO. 18814-104WO1 / P6130WO1
  • the sync server 120 exchange other messages 3020, 3030, 3040, 3050 and 3060 as needed.
  • the sync server 120 returns checkpoint anchors a1 , a2, and a3 using these messages 3020, 3030, 3040, 3050 and 3060.
  • FIG. 31 is a table showing example checkpoint anchors. The table includes columns that describe the possible checkpoint anchors 31 10, the associated sync phases 3120 and server state 3130 associated with the checkpoint anchors.
  • the anchor aO can represent the negotiation phase, which cause no change in the sever state.
  • the anchor a1 can represent the push phase.
  • the server 120 applies the changes requested by the client device 1 10, and the server 120 sends part 1 of its changes to the client device 1 10.
  • the anchor a2 can represent the push phase initiated by the server 1 10.
  • the server sends part 2 of its changes to the client device 1 10.
  • the anchor a3 can represent the commit phase and signal that committing the changes has been completed. This anchor signals that the synchronization session has been completed. [00218] Device Settings
  • the synchronization protocol 120 provides a mechanism for the server 120 to dynamically request device settings and capabilities.
  • the "get” and “put” commands may be used to exchange information.
  • the server 120 may send a "get” command with the "uri” parameter having the value “deviceinfo” to request device settings and capabilities, for example.
  • the client device 1 10 may send a "put” command with the same "uri” parameter to the server 120.
  • the value of the "uri” parameter is a dictionary containing various key-value pairs.
  • the value for "userid” represents the authenticating principle and is implemented as a String.
  • the value for "authtype” represents the authentication scheme and is implemented as a String.
  • “auth” represents the authentication credential and is represented as a String.
  • the recipient When the recipient is willing to perform the operation, the recipient returns a success status, such as status S_OK (600).
  • the recipient returns a status, such as the status E NotFound (603) to indicate the URI was not found and is unknown.
  • the recipient returns a status, such as the status E NotAllowed (604) to indicate that the requested operation is not permitted.
  • the recipient returns a status, such as the status E BadValue (607) to indicate that the requested operation could not be performed.
  • the recipient When the requested operation could not be performed because the supplied "itemtype” was incorrect, the recipient returns a status, such as the status E NotSupported (614) to indicate that the requested operation is not supported.
  • FIG. 32 shows a table of example key-value pairs for the "uri” parameter.
  • the available keys 3210 for the "uri” parameter includes version, msisdn, deviceid, name, model, carrier and dataclasses.
  • the associated values 3220 for the version, msisdn, deviceid, name, model and carrier keys are string values.
  • the value 3220 for the dataclasses key is a dictionary.
  • the table also shows the associated description 3230 for these keys.
  • the version key-value can describe the product version, such as version 1 .1 .4.
  • the msisdn key-value can describe the phone number of a currently installed SIM card.
  • the deviceid key-value can describe the ICCID.
  • the name key-value can describe the user's device name, such as EctoPhone.
  • the model key-value can describe the model of the client device 1 10, such as iPhone ® , iPod Touch ® , etc.
  • the carrier key-value can describe the carrier name, such as AT&T ® , Verizon ® , etc.
  • the dataclasses key-value can describe
  • the server 120 requests for device information by sending a "get” command. Thereafter, when the device information changes, the client device 1 10 sends the changed device information to the server 120 by sending a "put" command.
  • Filtering is the ability to constrain a set of data items synchronized with the client device 1 10 based on the values in the data items. For example, a user may want to sync only the contacts contained within a certain set of groups, or the calendar events within a certain time window surrounding the current date.
  • filter settings are enforced by the computer during cable syncing to constrain or filter the set of data items sent to the client device 1 10, such as iPhone ® .
  • the synchronization protocol 140 provides similar filtering functionality in a wireless sync solution. The same filter settings from iTunes ® is enforced by the server 120 without requiring any user action. Thus, the filtering can be performed automatically.
  • FIG. 33 is a table showing example key-value pairs for filter settings.
  • the available keys 3310 for the filter settings include default_container, constrain containers, and discard_after_days.
  • the values 3320 of these filter setting keys are string, array and string respectively.
  • the dataclass 120 of the default_container key includes contacts and calendars.
  • the dataclass 120 of the constrain containers key includes contacts and calendars.
  • the dataclass 120 of the discard_after_days key includes calendar.
  • the default_container key describes the identification (LUID) of the container entity, such as the group ID for contacts and calendar ID for events.
  • the constrain containers key describes the set of LUIDs of container entities to include, such as the set of Groups to include.
  • the discard_after_days key describes the number of days after which events older than the described number of days should be deleted.
  • FIG. 34 is an example of a diagram in pseudo Backus-Naur Form (BNF).
  • BNF is a metasyntax that enables expression of context-free grammars.
  • Context-free grammars can define the syntax of a programming language by using two sets of rules: Lexical rules and Syntactic rules.
  • Augmented BNF is a modified version of ATTORNEY DOCKET NO. 18814-104WO1 / P6130WO1
  • FIG. 35 shows an example sync session.
  • the example sync session shown in FIG. 35 includes split sync-changes and put filter information.
  • the client device 1 10 sends a negotiation phase command ("sync-start") and a pull phase command (“sync-changes") in the first message 3510 to the server 120.
  • the put command is used to send data items for a specific dataclass.
  • the dataclass indicated in the put command is contacts.
  • the data items are filtered to constrain the data to be synced for the dataclass.
  • the server 120 responds by sending a sync- start command response with the status "S_OK" to indicate a successful negotiation for the contacts dataclass.
  • anchors are used to indicate the checkpoint.
  • the server 120 sends a sync-changes command for the contacts dataclass with the "more" Boolean flag indicate that not all appropriate data items for the dataclass are included in the command params.
  • the second message 3520 can be include a put command response with a "S_OK” status indicating a successful put.
  • the client device 1 10 includes a sync-changes command response with the "S_OK" status for the contacts dataclass indicated by the uri parameter.
  • idmap is included to provide GUID-LUID mapping, for example.
  • the server 120 sends a sync changes command with the uri parameter indicating the contacts dataclass.
  • the "more" Boolean is included to indicate that more data will follow.
  • the client device 1 10 sends a sync-changes command response with a status "S_OK" to indicate a successful update for the contacts dataclass.
  • the server 120 sends a sync-changes command and a sync-commit command for the contacts dataclass.
  • the client device 1 10 responds in the seventh message 3570 with a sync-changes command response indicating a successful update.
  • the client device 1 10 also includes a sync-commit response (OK) to indicate the client device has committed the changes.
  • the last message 3580 has an empty message body to indicate a sync session's final message. [00232] FIGS.
  • FIG. 36 shows a summary of four example messages for a reset sync session.
  • FIGS. 37a and 37b show an example message sent from the client device 1 10 to the server 120.
  • the sync-start command ATTORNEY DOCKET NO. 18814-104WO1 / P6130WO1
  • the message also includes a sync-changes command with the same dataclass (com.apple.Contacts), and empty changes.
  • FIGS. 38a, 38b, 38c and 38d show an example message sent from the server 120 to the client device 1 10.
  • the server 120 sends a sync-start command response with the status "S_OK" to indicate a successful negotiation.
  • the message also includes a sync-changes command response with the status "S_OK” to indicate a successful data update.
  • the server 120 sends a sync-changes command that sends one contact, phone number and email address.
  • the server 120 also sends a get command to pull device information from the client device 1 10.
  • FIGS. 39a, 39b and 39c show an example message sent from the client device 1 10.
  • the message includes a sync-changes command response with the status "S_OK" to indicate a successful update of the data items changed.
  • the idmap parameter is provided to indicate the GUID to LUID mapping.
  • the message also includes a get command response with the status "S_OK” to indicate a successful get operation in returning the device information. Further, the message includes a sync-commit command to indicate that the client device 1 10 has committed and the server 120 should commit also.
  • FIGS. 40a and 40b shown an example message sent from the server 120.
  • the server 120 sends a sync-commit command response with the status "S_OK" to indicate the server 120 had committed the changes also.
  • FIGS. 41 , 42a, 42b, 43a, 43b and 43c show example messages for a fast sync.
  • the client device 1 10 and the server 120 each have one delete.
  • FIG. 41 shows a summary of the two example messages for a fast sync.
  • FIGS. 42a and 42b show an example message sent from the client device 1 10 for a fast sync.
  • the message includes a sync-start command for the negotiation phase.
  • the uri parameter indicates the dataclass as com.apple.Contacts.
  • the sync mode is indicated as fast.
  • the message also includes a sync-changes command to delete a data record for the indicated com.apple.Contacts dataclass.
  • FIGS. 43a, 43b and 43c show an example message sent from the server 120 in response to the message sent by the client device 1 10.
  • the message ATTORNEY DOCKET NO. 18814-104WO1 / P6130WO1
  • the message from the server 120 also includes a sync-start command response with the status "S_OK” to indicate a successful negotiation.
  • the message also includes a sync-changes command response with the status "S_OK” to indicate a successful delete of the data record indicated by the client device 1 10.
  • the server 120 sends a sync-changes command to request another data record delete.
  • the same dataclass, com. apple. Contacts is indicated by the uri parameter in the sync-changes command.
  • the message from the server 120 also includes a sync- commit command to indicate that the server 120 has committed the sync and that the client device 1 10 should also commit.
  • FIGS. 44a and 44b show an example process for syncing a client device 1 10 and a server 120.
  • the sender initiates 4402 a negotiation phase with the recipient.
  • the sender is the client device 1 10 and the recipient is the server 120.
  • the negotiation phase is initiated 4402 by sending a message with a stateful sync-family command, such as sync-start.
  • the sync-start command includes a uri parameter that indicates a particular dataclass and an anchors parameter that can include the requested sync mode, datastore versions and/or sync anchors.
  • a separate "sync-start" command request is sent for each dataclass.
  • the server 120 responds 4404 to the negotiation phase by sending a message to the client device 1 10 with a sync-start command response.
  • a determination 4406 is made on whether the negotiation is a success.
  • the dataclass indicated by the uri parameter is detected and analyzed to determine whether the server 120 supports and enables 4424 the dataclass. When detected that the dataclass is not supported, an error status such as "E NotSupported (612)" is generated 4432. The generated error status can be included in the sync-start command response to indicate that the dataclass is not supported.
  • an error status such as "E NotAllowed (604)" is generated 4432.
  • the generated status is included in the sync-start command response to indicate that the dataclass is not enabled.
  • a success status such as "S_OK” is generated 4426.
  • the generated status is included in the sync-start command response to indicate that the server 120 supports and enables the ATTORNEY DOCKET NO. 18814-104WO1 / P6130WO1
  • the requested sync mode is analyzed to determine whether the server 120 accepts 4428 the sync mode.
  • an error status such as "E NegotiationFailed (613)" is generated 4434.
  • the generated status is included in the sync-start command response to indicate that the requested sync mode is not accepted.
  • the server 120 may decide 4436 whether to suggest a different sync mode to use.
  • the suggested different mode is included 4438 in the anchors parameter in the sync-start command response.
  • a success status such as "S_OK” is generated 4430. The generated success status is included in the sync- start command response.
  • the sync session proceeds 4408 to a pull phase.
  • the client device 1 10 sends the changed records to the server 120.
  • the sync mode is "slow"
  • all records are sent to the server 120.
  • the changes are sent using the sync-changes stateful commands.
  • the server 120 responds to the sync-changes command with the corresponding sync-changes command response to indicate whether the changes have been accepted.
  • the success status "S_OK" indicates that the changes have been accepted.
  • the server 120 proceeds 4410 to the mingle phase.
  • the sync- changes commands for each dataclass will have distinct state machines.
  • the server 120 waits until all dataclasses have completed the pull phase or cancelled before proceeding to the mingling phase. Any detected invalid changes may be rejected by the server 120.
  • the server decides 4412 whether any conflicts exists for the dataclass. When detected that conflicts exist, the server 120 decides 4416 whether to resolve the conflicts itself or whether to let the user or client device 1 10 resolve the conflicts. When the server 120 resolves the conflicts, the server 120 can rely on heuristics to resolve the conflicts. For example, the client device 1 10 initiating the most recent sync may be selected as the winner. [00245] For some instances such as the dataclass and/or data item, the user/client ATTORNEY DOCKET NO. 18814-104WO1 / P6130WO1
  • the device 1 10 may be selected as the one to resolve the conflicts. Then the detected conflicts are sent to the client device 1 10 to enable the client device 1 10 to resolve the conflicts. Also, the detected conflicts can be presented to the user by displaying the conflicts on a display unit on the client device 1 10, for example. The user can resolve the conflict manually. The result of the conflict resolution may then be sent from the device 1 10 to the server 120 during the next sync session. [00246] The changes from the server 120 (recipient) can be sent to the client device 1 10 during the push phase 4414. The server 120 can send a message to the client device with sync-changes commands to push the changes to the client device 1 10.
  • the commit phase is entered 4416. Both sides agree that the sync was successful, persist their current sync anchors, and commit the exchanged data to their respective data stores. In the commit phase, messages are sent with sync-commit commands and command responses.
  • Embodiments of the subject matter and the functional operations described in this specification can be implemented in digital electronic circuitry, or in computer software, firmware, or hardware, including the structures disclosed in this specification and their structural equivalents, or in combinations of one or more of them.
  • Embodiments of the subject matter described in this specification can be implemented as one or more computer program products, i.e., one or more modules of computer program instructions encoded on a tangible program carrier for execution by, or to control the operation of, data processing apparatus.
  • the tangible program carrier can be a propagated signal or a computer readable medium.
  • the propagated signal is an artificially generated signal, e.g., a machine-generated electrical, optical, or electromagnetic signal, that is generated to encode information for transmission to suitable receiver apparatus for execution by a computer.
  • the computer readable medium can be a machine-readable storage device, a machine- readable storage substrate, a memory device, a composition of matter effecting a machine-readable propagated signal, or a combination of one or more of them.
  • data processing apparatus encompasses all apparatus, devices, and machines for processing data, including by way of example a programmable processor, a computer, or multiple processors or computers.
  • the apparatus can include, in addition to hardware, code that creates an execution ATTORNEY DOCKET NO. 18814-104WO1 / P6130WO1
  • a computer program (also known as a program, software, software application, script, or code) can be written in any form of programming language, including compiled or interpreted languages, or declarative or procedural languages, and it can be deployed in any form, including as a stand alone program or as a module, component, subroutine, or other unit suitable for use in a computing environment.
  • a computer program does not necessarily correspond to a file in a file system.
  • a program can be stored in a portion of a file that holds other programs or data (e.g., one or more scripts stored in a markup language document), in a single file dedicated to the program in question, or in multiple coordinated files (e.g., files that store one or more modules, sub programs, or portions of code).
  • a computer program can be deployed to be executed on one computer or on multiple computers that are located at one site or distributed across multiple sites and interconnected by a communication network.
  • Processors suitable for the execution of a computer program include, by way of example, both general and special purpose microprocessors, and any one or more processors of any kind of digital computer. Generally, a processor will receive instructions and data from a read only memory or a random access memory or both.
  • the essential elements of a computer are a processor for performing instructions and one or more memory devices for storing instructions and data.
  • a computer will also include, or be operatively coupled to receive data from or transfer data to, or both, one or more mass storage devices for storing data, e.g., magnetic, magneto optical disks, or optical disks.
  • mass storage devices for storing data, e.g., magnetic, magneto optical disks, or optical disks.
  • a computer need not have such devices.
  • a computer can be embedded in another device.
  • Computer readable media suitable for storing computer program instructions and data include all forms of non volatile memory, media and memory ATTORNEY DOCKET NO. 18814-104WO1 / P6130WO1
  • semiconductor memory devices including by way of example semiconductor memory devices, e.g., EPROM, EEPROM, and flash memory devices; magnetic disks, e.g., internal hard disks or removable disks; magneto optical disks; and CD ROM and DVD-ROM disks.
  • semiconductor memory devices e.g., EPROM, EEPROM, and flash memory devices
  • magnetic disks e.g., internal hard disks or removable disks
  • magneto optical disks e.g., CD ROM and DVD-ROM disks.
  • the processor and the memory can be supplemented by, or incorporated in, special purpose logic circuitry.
  • embodiments of the subject matter described in this specification can be implemented on a computer having a display device, e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor, for displaying information to the user and a keyboard and a pointing device, e.g., a mouse or a trackball, by which the user can provide input to the computer.
  • a display device e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor
  • keyboard and a pointing device e.g., a mouse or a trackball
  • Other kinds of devices can be used to provide for interaction with a user as well; for example, input from the user can be received in any form, including acoustic, speech, or tactile input.
  • Embodiments of the subject matter described in this specification can be implemented in a computing system that includes a back end component, e.g., as a data server, or that includes a middleware component, e.g., an application server, or that includes a front end component, e.g., a client computer having a graphical user interface or a Web browser through which a user can interact with an implementation of the subject matter described is this specification, or any combination of one or more such back end, middleware, or front end components.
  • the components of the system can be interconnected by any form or medium of digital data communication, e.g., a communication network.
  • Examples of communication networks include a local area network (“LAN”) and a wide area network (“WAN”), e.g., the Internet.
  • the computing system can include clients and servers.
  • a client and server are generally remote from each other and typically interact through a communication network.
  • the relationship of client and server arises by virtue of computer programs running on the respective computers and having a client-server relationship to each other.

Abstract

Among other things, techniques and systems are disclosed for syncing data between a client device and a server. Synchronizing data includes initiating a sync session by negotiating a sync mode between a client device and a server for each of one or more dataclasses. A status code is generated based on a result of the negotiating. Based on the generated status code, the client device and the server exchanges one or more data items to be updated for the one or more dataclasses using the negotiated sync mode for each dataclass. The exchanged one or more data items are updated at the client device or the server The updated one or more data items are committed at the client or the server.

Description

ATTORNEY DOCKET NO. 18814-104WO1 / P6130WO1
DATA SYNCHRONIZATION PROTOCOL
TECHNICAL FIELD [0001] This application relates to protocols for data synchronization.
BACKGROUND
[0002] Data synchronizing between a client and a server can be performed using synchronization protocols such as Open Mobile Alliance - Data Synchronization protocol OMA DS/SyncML (formerly known as the SyncML protocol). The OMS DA/SyncML is a sync protocol that enables serial synchronization of dataclasses and can require 5 or more roundtrips per dataclass.
SUMMARY
[0003] Among other things, techniques and systems are disclosed for syncing data between a client device and a server.
[0004] In one aspect, synchronizing data includes receiving a request to initiate a sync session. The request includes a proposed sync mode for each of one or more dataclasses, and one or more changes to the one or more dataclasses. One or more status codes are generated to indicate whether the proposed sync mode for each dataclass is accepted. Based on the generated status code, the accepted sync mode is used for each dataclass to selectively update one or more data items associated with the one or more changes to the one or more dataclasses. The updated one or more data items are selectively committed at the server. [0005] Implementations can optionally include one or more of the following features. Generating one or more status codes can include accessing information saved from a previous sync session to determine whether to use the proposed sync mode to synchronize the one or more data items. Receiving the request can include receiving the proposed sync mode for two or more dataclasses in parallel. Also, receiving the request can include receiving the proposed sync mode that includes a fast sync mode, a slow sync mode or a reset sync mode. Further, receiving the request can include receiving a fast sync mode that enables exchange of data items to be updated only. The sync session can be completed in one round trip that includes two messages. When the sync session is interrupted, a fast sync can be reaccepted. The proposed sync mode and the one or more changes to the one or i ATTORNEY DOCKET NO. 18814-104WO1 / P6130WO1
more dataclasses can be received in a single message from a client device. The updated one or more data items can be selectively committed at the server when the client device sends a command to commit the updated one or more data items. In addition, the proposed sync mode can be rejected and the received request can be responded to with a different sync mode.
[0006] In another aspect, a computer program product, embodied on a computer readable medium, is operable to cause a data processing apparatus to perform various operations. The computer program product is operable to cause a data processing apparatus to receive a request to initiate a sync session. The request includes a proposed sync mode for each of one or more dataclasses and one or more changes to the one or more dataclasses. The computer program product is operable to cause a data processing apparatus to generate a status code indicative of whether the proposed sync mode for each dataclass is accepted. The computer program product is operable to cause a data processing apparatus to based on the generated status code, use the accepted sync mode for each dataclass is used to selectively update one or more data items associated with the one or more changes to the one or more dataclasses. In addition, the computer program product is configured to cause a data processing apparatus to selectively commit the updated one or more data items at a server.
[0007] Implementations can optionally include one or more of the following features. The computer program product can cause a data processing apparatus to generate the one or more status codes based on information saved from a previous sync session. The computer program product can cause a data processing apparatus to receive the proposed sync mode for two or more dataclasses in parallel. The computer program product can cause a data processing apparatus to receive the proposed sync mode that includes a fast sync mode, a slow sync mode or a reset sync mode. The computer program product can cause a data processing apparatus to receive a fast sync mode that enables exchange of data items to be updated only. Update operations on a data item may (1 ) create a new item (add), (2) modify properties of an existing item (modify) or (3) delete an existing item (delete). The computer program product can cause a data processing apparatus to complete the sync session in one round trip that includes two messages. The computer program product can cause a data processing apparatus to reaccept a fast sync mode when the sync session is interrupted. The computer program product can ATTORNEY DOCKET NO. 18814-104WO1 / P6130WO1
cause a data processing apparatus to receive the proposed sync mode and the one or more changes to the one or more dataclasses in a single message. The computer program product can cause a data processing apparatus to selectively commit the updated one or more data items at the server when the client device sends a command to commit the updated one or more data items. In addition, the computer program product can case a data processing apparatus to reject the proposed sync mode and respond to the received request with a different sync mode.
[0008] In another aspect, a server for syncing data includes a processor configured to operate a transport protocol that enables opening of one or more connections to one or more client devices. The processor is also configured to operate a sync protocol that enables data synchronization between the server and the one or more client devices over the opened one or more connections. The sync protocol enables the server to receive a request to initiate a sync session. The request includes a proposed sync mode fore each of one or more dataclasses and one or more changes to the one or more dataclasses. The sync server also enables the server to generate one or more status codes to indicate whether the proposed sync mode for each dataclass is accepted. The sync protocol also enables the server to, based on the generated status code, use the accepted sync mode for each dataclass to selectively update one or more data items associated with the one or more changes to the one or more dataclasses. The sync protocol further enables the updated one or more data items to be selectively committed at the server.. [0009] Implementations can optionally include one or more of the following features. The processor can be configured to access a data repository to update one or more data items based on the received one or more changes. The processor can be configured to operate the sync protocol to accept or reject the proposed sync mode for each dataclass based on information saved from a previous sync session. The processor can be configured to operate the sync protocol to received the proposed sync mode for two or more dataclasses in parallel. Also, the processor can be configured to operate the sync protocol to receive the proposed sync mode that includes a fast sync mode, a slow sync mode or a reset sync mode. The processor can be configured to operate the sync protocol to receive the proposed sync mode that includes a fast sync mode that enables the one or more client devices to send data items to be updated only. The processor can be configured to ATTORNEY DOCKET NO. 18814-104WO1 / P6130WO1
operate the sync protocol to receive request to reinitiate a fast sync when the sync session is interrupted. The processor can be configured to operate the sync protocol to complete the sync session in one round trip that includes two messages. The processor can be configured to operate the sync protocol to receive the proposed sync mode and the one or more changes to the one or more dataclasses in a single message from at least one of the one or more client devices. The processor can be configured to operate the sync protocol to selectively commit the updated one or more data items at the server when one of the one or more client devices sends a command to commit the updated one or more data items. Further, the processor can be configured to operate the sync protocol to rejecting the proposed sync mode and responding to the request with a different sync mode. [0010] In another aspect, synchronizing data includes sending a request to a server to initiate a sync session. The request includes a proposed sync mode for each of one or more dataclasses, and one or more changes to the one or more dataclasses. One or more status codes are received to indicate whether the proposed sync mode for each dataclass has been accepted by the server. Based on the received status code, the accepted sync mode for each dataclass is used to receive from the server additional changes to the one or more dataclasses. Further, at a client device, the additional changes received from the server are committed. [0011] Implementations can optionally include one or more of the following features. The one or more status codes can indicate that the proposed sync mode for at least one of the one or more data classes has been rejected by the server. Another request that includes a different sync mode than the rejected sync mode can be sent to the server. Also, the proposed sync mode and the one or more changes can be sent in a single message to the server. The proposed sync mode for two or more dataclasses can be sent in parallel. In addition, a different proposed sync mode can be sent for each of the two or more dataclasses in parallel. For example, a proposed fast sync mode can be sent for one of the dataclasses and a proposed slow sync mode for another of the dataclasses. After the sync session is interrupted, the sync session can be reinitiated using the accepted sync protocol.. [0012] In another aspect, a computer program product, embodied on a computer- readable medium, is operable to cause a data processing apparatus to perform one or more operations. The computer program product is operable to cause a data processing apparatus to send a request to a server to initiate a sync session. The ATTORNEY DOCKET NO. 18814-104WO1 / P6130WO1
request includes a proposed sync mode for each of one or more dataclasses and one or more changes to the one or more dataclasses. The computer program product is operable to cause a data processing apparatus to receive one or more status codes that are indicative of whether the proposed sync mode for each dataclass has been accepted by the server. Based on the received status code, the computer program product is operable to use the accepted sync mode to receive from the server additional changes to the one or more dataclasses and commit at a client device the additional changes received from the server. [0013] Implementations can optionally include one or more of the following features. The computer program product can be operable to cause a data processing apparatus to perform operations that includes receiving the one or more status codes that indicate that the proposed sync mode for at least one of the one or more data classes has been rejected by the server; and sending another request that includes a different sync mode than the rejected sync mode. The computer program product can be operable to cause a data processing apparatus to send the proposed sync mode and the one or more changes in a single message to the server. The computer program product can be operable to cause the data processing apparatus to send the proposed sync mode for two or more dataclasses in parallel. The computer program product can be operable to cause the data processing apparatus to send a different proposed sync mode for each of the two or more dataclasses in parallel. The computer program product can be operable to cause the data processing apparatus to send a proposed fast sync mode for one of the dataclasses and a proposed slow sync mode for another of the dataclasses. The computer program product can be operable to cause the data processing apparatus to reinitiate the sync session using the accepted sync protocol after the sync session is interrupted.
[0014] In another aspect, a client device includes a processor configured to operate a transport protocol that enables opening of one or more connections to a server and a sync protocol that enables data synchronization between the client device and the server over the opened one or more connections. The sync protocol enables the client device to send a request to a server to initiate a sync session. The request includes a proposed sync mode for each of one or more dataclasses and one or more changes to the one or more dataclasses. The sync protocol also enables the client device to receive one or more status codes indicative of whether ATTORNEY DOCKET NO. 18814-104WO1 / P6130WO1
the proposed sync mode for each dataclass has been accepted by the server. Based on the received status code, the sync protocol enables the client device to use the accepted sync mode to receive from the server additional changes to the one or more dataclasses. Further, the sync protocol enables the client device to commit at a client device the additional changes received from the server. [0015] Implementations can optionally include one or more of the following features. The processor can be configured to operate the sync protocol to receive the one or more status codes that indicate that the proposed sync mode for at least one of the one or more data classes has been rejected by the server; and send another request that includes a different sync mode than the rejected sync mode. The processor can be configured to operate the sync protocol to send the proposed sync mode and the one or more changes in a single message to the server. The processor can be configured to operate the sync protocol to send the proposed sync mode for two or more dataclasses in parallel. The processor can be configured to operate the sync protocol to send the proposed sync mode for two or more dataclasses in parallel comprising sending a different proposed sync mode for each of the two or more dataclasses in parallel. The processor can be configured to operate the sync protocol to send a proposed fast sync mode for one of the dataclasses and a proposed slow sync mode for another of the dataclasses. The processor can be configured to operate the sync protocol to reinitiate the sync session using the accepted sync protocol after the sync session is interrupted. [0016] Techniques and systems according to the present specification can be implemented to potentially provide various advantages. The sync protocol as described in this specification can reduce the number of round trips (the number of back and forth messages exchanged) to complete a sync session. The sync protocol as described in this specification can complete a sync session in one round trip, for example. The sync protocol as described in this specification enables sync mode negotiation for each of multiple dataclasses in parallel. Thus, a request for sync mode negotiation can be sent for multiple dataclasses in one message. Further, the sync protocol as described in this specification enables field level differencing and record level differencing.
[0017] The synchronization protocol as described in this specification is simpler than conventional protocols, such as SyncML. The set of commands available for the synchronization protocol is simple and yet extensible. Unlike SyncML, the ATTORNEY DOCKET NO. 18814-104WO1 / P6130WO1
synchronization protocol as described in this specification represents each message as a text or binary property list files (plist). In addition, the synchronization protocol as described in this specification is efficient and robust. For example, a sophisticated anchor logic is provided on the server. Further, the synchronization protocol is tolerant of unreliable network. Even when the network connection is interrupted, the anchor logic ensures efficient synchronization once reconnected. Further, the synchronization protocol can maintain relatively small message size. [0018] The synchronization protocol as described in this specification is rich. For example, the synchronization protocol enables exchange of device information between the client device and the server. Also, the synchronization protocol provides convenient yet rich data representation.
BRIEF DESCRIPTION OF THE DRAWINGS
[0019] FIG. 1 A is a block diagram showing a system for enabling data synchronization between a client device and a server. [0020] FIG. 1 B shows example components of a server. [0021] FIG. 1 C shows example components of a client device. [0022] FIG. 2 is a table showing example elements for the header element of a message.
[0023] FIG. 3 shows an example property list file (plist). [0024] FIG. 4 is a table showing example elements for a command request element.
[0025] FIG. 5 is a table shows example elements for command response element.
[0026] FIG. 6 is a table showing example parameters for a get command. [0027] FIG. 7 is a table that shows examples of parameters for a get command response.
[0028] FIG. 8 is a table showing example parameters for a put command. [0029] FIG. 9 is a table showing example parameters for a put command response.
[0030] FIG. 10 is a table showing example parameters for a delete command. [0031] FIG. 1 1 is a table showing example parameters for a delete command response. [0032] FIG. 12 is a table showing example parameters for a sync-start command. ATTORNEY DOCKET NO. 18814-104WO1 / P6130WO1
[0033] FIG. 13 is a table that shows example parameters for a sync-start command response.
[0034] FIG. 14 is a table showing example parameters for a sync-changes command.
[0035] FIG. 15 is a table showing example parameters for a sync-changes command response.
[0036] FIG. 16 is a table showing example parameters for a sync-commit command.
[0037] FIG. 17 is a table showing example parameters for a sync-commit command response.
[0038] FIG. 18 is a table showing example parameters for a sync-cancel command.
[0039] FIG. 19 is a table showing example parameters for a sync-cancel command response.
[0040] FIG. 20 is a table showing example status elements.
[0041] FIG. 21 is a table showing example status codes for statuses available to be included in message headers, commands and command responses.
[0042] FIG. 22 is a table describing the effect of receiving a given status for a command on the session or on other commands in the message.
[0043] FIG. 23 is a table showing example keys for the anchors element.
[0044] FIG. 24 shows an example of a sync session.
[0045] FIG. 25 shows an example of a optimal fast or reset sync between a client device and a server.
[0046] FIG. 26 shows an alternate example of a fast or reset data sync.
[0047] FIG. 27 shows another example data sync session with idmap deferred from session 1 to start of session 2.
[0048] FIG. 28 illustrates an example of a slow sync.
[0049] FIG. 29 shows an example of syncing multiple data classes in parallel.
[0050] FIG. 30 shows an example sync session that uses checkpoint anchors.
[0051] FIG. 31 is a table showing example checkpoint anchors.
[0052] FIG. 32 shows a table defines example key-value pairs for the Devicelnfo element.
[0053] FIG. 33 is a table showing example key-value pairs for filter settings.
[0054] FIG. 34 is an augmented Backus-Naur Form (ABNF) description of the ATTORNEY DOCKET NO. 18814-104WO1 / P6130WO1
protocol syntax.
[0055] FIG. 35 shows an example sync session.
[0056] FIG. 36 shows a summary of four example messages for a reset sync session.
[0057] FIGS. 37a and 37b show an example message sent from a client device to a server.
[0058] FIGS. 38a, 38b, 38c and 38d show an example message sent from a server to a client device.
[0059] FIGS. 39a, 39b and 39c show an example message sent from a client device.
[0060] FIGS. 40a and 40b shown an example message sent from a server.
[0061] FIG. 41 shows a summary of two example messages for a fast sync.
[0062] FIGS. 42a and 42b show an example message sent from a client device for a fast sync.
[0063] FIGS. 43a, 43b and 43c show an example message sent from a server in response to a message sent by a client device.
[0064] FIGS. 44a and 44b show an example process for syncing a client device and a server.
[0065] Like reference symbols and designations in the various drawings indicate like elements.
Detailed Description
[0066] Techniques and systems are disclosed for enabling over-the-air (OTA) synchronization between a client device and a server. In particular, a wireless structured data synchronization protocol can enable a client device to interface with a server to synchronize various data. Such protocol can be used to synchronize Mac® Operating System X (OS X) SyncServices data between a handheld device such as the iPhone® and a server such as the .Mac® server, for example. [0067] The OTA synchronization protocol as described in this specification relies upon the underlying network transport to perform authentication and/or authorization and message security/encryption using transport layer security (TLS), for example. The synchronization protocol can enable these data transport using hypertext transfer protocol (HTTP) transport protocol or other similar transport protocols which are capable of exchanging synchronization protocol messages between the device ATTORNEY DOCKET NO. 18814-104WO1 / P6130WO1
and server.
[0068] The synchronization protocol can enable exchange of protocol messages over the transport, such as HTTP transport. The each message exchanged over the transport includes a header element and a body element. The body element can include a sequence of command and/or command response elements. The synchronization protocol assigns a unique label to each message, command and command response to ensure proper ordering and loss detection. For example, the label can include a sequence of numbers for ordering the messages, commands and command responses. Using the label, the synchronization protocol, instead of the transport (e.g., HTTP) ensures proper ordering and loss detection even when the network protocol does not enforce message ordering.
[0069] The synchronization protocol is simpler than conventional protocols, such as Synchronization Markup Language (SyncML). The set of commands available for the synchronization protocol is simple and yet extensible. For example, three flexible primitive commands are available for manipulating resources. In addition, four "sync" family commands are available for data synchronization. Further, commands may be split across message boundaries. Unlike SyncML, the synchronization protocol as described in this specification represents each message as a text or binary property list files (plist). In the Mac OS X Cocoa, NeXTSTEP, and GNUstep programming frameworks, plists are files that store serialized objects. The plists are often used to store a user's settings, similar to the function of the Windows registry on Microsoft Windows®. Property list files are also used to store information about bundles and applications. A plist is easy to generate and parse using standard operating system (OS) features, such as NSPropertyϋstSerialization class. Also, the synchronization protocol as described in this specification uses simple sync state machine.
[0070] The synchronization protocol as described in this specification is efficient and robust. For example, a sophisticated anchor logic is provided on the server. An anchor is a tag or label used to keep track of the synchronization state. Also, the synchronization protocol can sync multiple dataclasses in parallel. The synchronization protocol is tolerant of unreliable network. Even when the network connection is interrupted, the anchor logic ensures efficient synchronization once reconnected with minimal retransmission of data. Further, the synchronization protocol can maintain relatively small message size. ATTORNEY DOCKET NO. 18814-104WO1 / P6130WO1
[0071] The synchronization protocol as described in this specification is rich. For example, the synchronization protocol enables exchange of device information between the client device and the server. Also, the synchronization protocol provides convenient yet rich data representation. [0072] FIG. 1 a is a block diagram of a system 100 for enabling data synchronization between a client device and a server. The system 100 includes one or more client devices 1 10 interfacing with one or more servers 120 over a network 150. The client device 1 10 can include mobile devices, such as a mobile phone 1 12, a personal digital assistant (PDA) 1 14, a handheld data processing devicesi 16, etc. The mobile phone 1 12 includes smart phones and integrated mobile devices such as the iPhone®. The handheld data processing devices can include audio playback devices such as MP3 players and iPod® devices.
[0073] The client device 1 10 interfaces with the server 120 using a transport protocol such as HTTP transport protocol to complete a secure data connection. Through the transport protocol, a synchronization protocol 140 enables data synchronization between the connected client device 1 10 and the server. Synchronized data can include various data classes such as contacts (e.g., addresses and phone numbers), calendar, etc. Data synchronization can be performed over the network 150 that includes various wired and wireless networks such as local area network (LAN), wide area network (WAN), Ethernet, Internet, etc. [0074] FIG. 1 b shows example components of the server 120. The server 120 can include a processor 160 and a memory 170, among other components. The processor 160 can include a central processing unit (CPU) or other classes of logic machines that can execute computer programs. The memory can include nonvolatile storage devices such as a fixed hard drive or removable storage devices. The removable storage devices can include a compact flash units, USB memory sticks, etc. The memory 170 can also include volatile memories such as various forms of random access memories.
[0075] The processor 160 can operate the transport protocol 130 to open transport connections to one or more client devices 1 10. The processor 160 can operate the sync protocol 140 over the opened transport connections to enable data synchronization between the server 120 and the client devices 1 10. The transport protocol 130 and the sync protocol 140 can be loaded and running on the memory 170 to be executed or operated by the processor 160. For example, as described ATTORNEY DOCKET NO. 18814-104WO1 / P6130WO1
with respect to FIGS 2-44b below, the processor 160 can operate the sync protocol 140 to receive a request from the client devices 1 10 to initiate a sync session. [0076] FIG. 1 c shows example components of the client devices 1 10. The client devices 1 10 can also include a processor 180 and a memory 190, among other components. The processor 180 can include a central processing unit (CPU) or other classes of logic machines that can execute computer programs. The memory can include nonvolatile storage devices such as a fixed hard drive or removable storage devices. The removable storage devices can include a compact flash units, USB memory sticks, etc. The memory 190 can also include volatile memories such as various forms of random access memories.
[0077] The processor 180 can operate the transport protocol 130 to open transport connections to one or more servers 120. The processor 180 can operate the sync protocol 140 over the opened transport connections to enable data synchronization between the client devices 1 10 and the server 120. The transport protocol 130 and the sync protocol 140 can be loaded and running on the memory 190 to be executed or operated by the processor 180. For example, as described with respect to FIGS 2-44b below, the processor 180 can operate the sync protocol 140 to send a request to the server 120 to initiate a sync session. [0078] Synchronization is a process of maintaining consistency between two distinct datastores by periodically comparing the changes which have occurred to each since the last time the datastores were known to be consistent. The datastores can include a client device 1 10 on one side and a server 120 on the other side. To synchronize with each other, the datastores are configured with various capabilities. For example, each datastore is configured to supply all data when requested. In addition, each datastore is configured to identify and supply changes since the time of the last synchronization. Each datastore is configured to agree on the schema to be kept in sync. Each datastore is configured to agree on the supported data representations. Each datastore is configured to agree on the semantics of synchronization primitives (i.e. add, update, delete). Further, each datastore is configured to rollback to a previous state should a problem occur during a sync to avoid corrupting the datastores.
[0079] The synchronized data follows the relational model (E-R) and is divided into "schemas" or "dataclasses" which group definitions of structured data types ("entities".) Entities within a given dataclass may refer to one another via ATTORNEY DOCKET NO. 18814-104WO1 / P6130WO1
"relationships". Relationships between entities in discrete dataclasses is forbidden, and thus each dataclass is wholly independent of other dataclasses. From a user's perspective, dataclasses may appear to be managed from separate dedicated applications. For example, the "contacts" dataclass can be managed primarily by an address book application, while the "calendars" dataclass can be managed by a calendar application.
[0080] The synchronization protocol 140 enables various synchronization modes including slow, reset and fast. The first time a client device and a server sync, all data for a dataclass are exchanged to "match" existing data items that are considered identical. To optimize syncing and network bandwidth usage for subsequent sync operations, the client device and server should exchange only the data which has changed since the last time the pair synchronized. Thus, each entity (i.e., client device or server) should be capable of determining what local changes should be sent to the other entity. In addition, each entity should be able to detect whether a situation has occurred which require exchanging more data before "fast" syncing can be resumed.
[0081] The slow sync mode may be required when the client device 1 10 and server 120 sync for the first time to establish a common baseline for subsequent difference-only data exchange. During a slow sync, the client device 1 10 sends all data for a dataclass to the server 120. The server attempts to match these data items with those that are already known to the server 120. Failure to perform proper "identity matching" can result in duplicated data. The server 120 then responds with data items missing at the client device 1 10.
[0082] The reset sync mode is used to reset all data for the dataclass on the client device with the server's data. This can occur when the data structure has been pushed to the device 1 10, or if the server 120 or device 1 10 determine that the device's local data is corrupt. The device 1 10 sends no data, and the server responds with the complete data structure for the dataclass. [0083] The fast sync mode is the most efficient mode, especially when using a limited bandwidth connection. The client device 1 10 sends only those data that have changed since the last sync with the server 120. The server 120 responds with only those data that have changed external to the client device 1 10. [0084] A synchronization session can follow a distinct set of phases including negotiation, pull, mingle, push, and commit. The terms, "pull" and "push" can be ATTORNEY DOCKET NO. 18814-104WO1 / P6130WO1
defined relative to the server process. The client device 1 10 sends its local changes to the server 120 during the pull phase, and receives updates during the server's push phase.
[0085] During the negotiation phase, both sides (client device 1 10 and server 120) can exchange information from the previous sync session to determine what sync mode they agree to use for the current session. To help identify and organize the sync sessions, a "sync anchor" is assigned to each sync session. If the client device 1 10 has previously synced with the server 120, the client device 1 10 likely expects a specific sync mode. The client device 1 10 may believe that it can fast sync with the server 120, but the server 120 may desire to reset the device. When the requested sync mode is accepted by both sides, synchronization can proceed to the pull phase.
[0086] During the pull phase, the client device 1 10 sends its changed records (or if the sync mode is "slow", all records) to the server 120. Invalid changes may be rejected by the server 120.
[0087] Once all changes have been received, the server 120 enters the mingle phase and merges any pending updates in its database with the changes from the client device 1 10. The result of mingling is a set of conflicting changes and a set of updates which should be pushed to the client device 1 10. The server 120 can automatically resolve all conflicts using a heuristic algorithm. In some implementations, it may be desirable for the client device 1 10 to resolve certain conflicts. The synchronization protocol 140 can be designed to allow for conflicts to be represented and transmitted from the server 120 to the client device 1 10. The synchronization protocol 140 can be designed to enable conflicts to be resolved on the client device by the user to be transmitted to the sync server 120. [0088] During the push phase, updates from the server 120 are sent to the client device 1 10. When all updates have been received by the client device 1 10, the commit phase is entered. Both sides (client device 1 10 and server 120) may agree that the sync was successful, persist their current sync anchors, and commit the exchanged data to their respective data stores.
[0089] At any point during a sync, either side may decide to cancel the sync and rollback any changes to the local datastore. Cancellation may occur explicitly in response to one or more of the following events: when unexpected or invalid data is sent; when the expected transitions in the sync state machine are not followed; when ATTORNEY DOCKET NO. 18814-104WO1 / P6130WO1
communications between the client device 1 10 and server 120 are interrupted; or when some other problems occur.
[0090] The difference in data can be synced in various granularities. When exchanging synchronization data, the client device 1 10 and the server 120 may send the complete data for each changed record for a record-level differencing (RLD). Alternatively, just the changed fields of each changed record can be sent for a field- level differencing (FLD). FLD may be preferred over RLD, especially when data records include many fields, or contain large amounts of data, such as the images in the contact dataclass.
[0091] The server 120 can dynamically support both RLD and FLD representations of data received from the client device 1 10. The data representation for the changes indicates whether the client device 1 10 is using RLD or FLD for a given dataclass. This provides client device datastore implementation with maximum flexibility when the complexity of maintaining meta information to support FLD is unreasonable.
[0092] When receiving RLD changes, the server 120 internally converts the changes to FLD for processing, storage and communication efficiency. The server 120 expects an RLD client device 1 10 to send complete records. Data fields that are supported by the client device 1 10 and are missing from the client device's data record are assumed to have been cleared/deleted by the client device 1 10. However, a mechanism can be provided to enable the client device 1 10 to indicate that certain data field exceptional values are unchanged without sending the values. [0093] Identification (ID) mapping is another basic synchronization concept. Every synced datum has an universal unique record ID or UUID. For efficiency sake, the server 120 can use the UUIDs of the SyncService on Mac OS X. Alternatively, an application on the client device 1 10 can use its local unique IDs (LUIDs) for data to promote local datastore efficiency, for example. [0094] The server 120 enables the client device 1 10 datastores to use their own LUID to refer to data items as needed. In this case, the server 120 maintains a LUID to UUID mapping to enable the client device 1 10 to transparently reference global records by using its own local IDs. The server 120 reestablishes new mappings when a "slow" or "reset" sync mode is accepted for the dataclass. [0095] The synchronization protocol 140 includes a sequence of messages exchanged between the server 120 and the device 1 10 using a transport protocol ATTORNEY DOCKET NO. 18814-104WO1 / P6130WO1
130, such as HTTP. The synchronization protocol 140 includes the messages exchanged on the transport protocol 130. The roles of the client device120 and server 130 in the synchronization protocol are distinct from their roles in the communications/transport protocol. For example, for the HTTP transport 130, the device 1 10 is always a client with respect to the transport 130, and thus the device 1 10 makes requests only. However, in the message protocol of the synchronization protocol 140, both the client device 1 10 and server 120 may issue message commands to each other. [0096] Transport
[0097] The transport protocol 130 manages the exchange of messages between the server 120 and client device 1 10. The transport protocol 130 can include HTTP transport or other suitable transports, such as Extensible Messaging and Presence Protocol (XMPP). The transport protocol 130 layer handles authentication, and thus the synchronization protocol 140 does not need to handle security/authentication processing. This enables the synchronization protocol 140 to function more efficiently and require few number of roundtrips. For example, Transport Layer Security (TLS) may be used to ensure security of the transmitted data, if desired. Also, the transport protocol 130 may perform message chunking. The transport protocol 130 need not guarantee delivery or message ordering, as the synchronization protocol 140 has the necessary information to do so and to detect message loss.
[0098] The HTTP defines eight methods or "verbs" that indicate actions to be performed on a resource. The HTTP methods includes: HEAD, GET, POST, PUT, DELETE, TRACE, OPTIONS and CONNECT. When using HTTP as the transport protocol 130, the POST method is to be used. The POST method submits data to be processed, such as data from an HTML form, to the identified resource. The data is included in the body of the request. The result of the POST method may result in the creation of a new resource or the updates of existing resources or both. ATTORNEY DOCKET NO. 18814-104WO1 / P6130WO1
[0099] For example, the server 120 can provide the OTA sync service on a URL, such as "http://sync. mac.com/ota". When using text plist representation, the "Content-Type" header should be "text/xml". When using binary plist representation, the "Content-Type" header must be present and must be "application/octet-stream". The "Content-Length" header must indicate the size of the message. The User- Agent string is used to identify the client protocol implementation. The User-Agent string should be of the form: "Mobile/1 A543". Alternatively, Devicelnfo method can be used to determine the device implementation version. [00100] The OTA Protocol Structure
[00101] A session consists of an exchange of a number of protocol messages between the client device 1 10 and the server 120. The HTTP transport implementation can use cookies to maintain a session with the server 120. Either the client device 1 10 or the server 120 may indicate that the session is complete by setting a flag in a message header. Each message contains a series of commands that can be processed by the recipient. The client device 1 10 may be designated as the party that initiates the connection to the server 120. [00102] The messages exchanged using the synchronization protocol 140 is represented as UTF-8 encoded OS X property lists (i.e. a dictionary.) This representation facilitates creation, serialization and parsing on both the client device 1 10 and the server 120. The synchronization protocol 140 can support both Extensible Markup Language (XML) and binary representations of plists. Binary plists can be 60% to 80% more compact than XML plists. When using XML plist representation, any binary data transmitted are serialized as base-64 encoded NSData objects and the text data are XML-escaped according to RFC 3076. Each protocol message consists of two root elements: the header and the body. [00103] FIG. 2 is a table illustrating example header elements 210. The message header element 210 can include service, deviceid, version, userid, sequence, msisdn, final, result, etc. Corresponding to each header element 210, the type 220 of the header element is also shown. FIG. 2 also shows whether each header element 210 is required 230. Further, a short description 240 of each header element is provided in FIG. 2.
[00104] The header element 210 can identify the entity (e.g., client device 1 10 or server 120) sending the message, and can contain certain session control information. The header element 210 is a required element of the message, and the ATTORNEY DOCKET NO. 18814-104WO1 / P6130WO1
value of the header element is a dictionary. Elements 210 in the header can indicate the source entity ("deviceid") and target service ("service"), target account ("userid"), and message sequence number ("sequence"), for example. Also, the "version" element can indicate the synchronization protocol version being used. For example, FIG. 2 shows in the description 240 column that the current version is "1 .0". These elements 210 should all be present in the message.
[00105] FIG. 2 also shows that the values of the header elements 210 service, deviceid, version, userid, sequence and msisdn are set as strings. For example, the value of the sequence element is a monotonically increasing integral value that starts at "1 " for a given session. The sequence element is used to indicate message ordering for the session.
[00106] The value of the service element is a string that identifies the name of the target service, such as the sync server. The value for userid element is a string that indicates the target account for the message. The userid element can identify the principal that authenticated with the server 120 on the transport layer 130. The deviceid for the client device 1 10 is a string that uniquely identifies the device hardware. For iPhone® and iPod® touch devices, the deviceid element can be the Integrated Circuit Card (ICCID) value. Client devices 1 10 with a GSM radio may also send the msisdn element to indicate the phone number of the currently installed/active Security Information Management (SIM) card. The msisdn value may change from one session to the next, for example when the user replaces the SIM card, without affecting synchronization behavior.
[00107] The final element is present in the header when the sender (e.g., the client device 1 10) considers its side of the session to be complete. The final element is a Boolean with a value being TRUE. When final element flag is present, the session is considered complete. The sender may then free any session related resources, and the recipient is not required to send another message. The recipient may send another message to return outstanding command responses. However, the recipient should not send any further command requests. The values for the userid and service elements should be constant for all messages in a given session. The values for the deviceid element should remain constant for the sending entity. In other words, while the server 120 and the client device 1 10 may have different values, those values may not change. ATTORNEY DOCKET NO. 18814-104WO1 / P6130WO1
[00108] The result element may be present in the header of a message to indicate the overall status for a message. For protocol brevity, an S_OK status is implied for any message without a header status. When detected that a message was not accepted, the result element is present in the header. The message may not be accepted when the data is malformed, or when the recipient encounters a session fatal condition. A non-OK status value indicates that the preceding message body was not processed, none of the message's commands were performed, and the session should be terminated. For example, a header status value of E BadRequest (703) indicates that the previous message was malformed. A header status value of EJJmitExceeded (61 1 ) indicates that the previous message size exceeded the recipient's capability. Also, header status values of E ServiceBusy (700), E ServiceUnavailable (701 ), and E RetryLater (704) indicate that the server 120 is experiencing difficulties in processing the request. [00109] FIG. 3 shows an example plist 300. The example plist 300 includes a header 310 and a body 320. The header 310 includes various example header elements 312, 314, 316, 318 and 319. For example, an example deviceid element 312 having a string value of "f1234567a0745a890a86b5556d9e020202bRX8" is shown. Also, an example msisdn element having a string value of "14155338207" is shown. In addition, an example sequence element having a value of "1 " is shown. The plist 300 also includes an example service element with a string value of sync. The plist 300 further includes an example version element with a string value of "1.0."
[00110] The body of the message includes an array of command requests and/or command responses to be processed by the recipient. The body element is a required element of the message, and the value of the body is represented as an array of command or command response dictionaries. The body element may be empty when the sender has no commands to send. Commands in the body are processed in command sequence order.
[00111] Both the device 1 10 and the server 120 may send command requests and responses within the same message. This may depend on the state of the current session.
[00112] The commands in the synchronization protocol can fall into two general categories: (1 ) commands that affect the state of the sender, the recipient and the processing of other commands in the message or the session; and (2) commands ATTORNEY DOCKET NO. 18814-104WO1 / P6130WO1
that do not. Whether a given stateless command successfully executes may not implicitly affect other commands in the message. Stateful commands begin with a "command family" prefix (e.g. "sync-" for all data synchronization commands). The command family prefix also provides a useful command namespace mechanism that allows the server 120 to support an arbitrary set of services for different client devices 1 10. In a given message, the commands in a given "command family" are processed in series, and if any command returns a nonsuccess status, subsequent commands in that family may not be processed at all. For example, a command response with a status code that indicates that the command has not been processed (e.g., E CommandNotProcessed) can be returned in this case. [00113] The recipient of a non-final message includes one or more command responses for each command in the session's next message. The recipient of a final message includes one or more command responses for each command when the final message was sent on a transport layer request (i.e. a transport response is expected.) The recipient of a final message may include one or more command responses for each command when the final message was sent on a transport layer response.
[00114] Three stateless primitive commands can be defined: "get", "put" and "delete". These stateless commands may be used to implement arbitrary object exchange or Representational State Transfer (RESTful) semantics within the synchronization protocol 140. This can be used, for example, to perform management actions, to transfer device settings or capabilities, or to reference binary large objects or other meta data without requiring the server 120 to perform data synchronization operations.
[00115] When detected that the data for a given command or command response is a priori too large, the sender may split it into multiple fragments which are sent in consecutive messages. A given command may be split for various reasons and/or constraints including memory constraints, transport constraints, etc. [00116] FIG. 4 is a table showing example command elements included in a command request. Each command request or command response is represented by a dictionary. For a command request, various command elements 410 can be provided. The example command elements can include the "name" element, the "sequence" element and the "params" element. These command elements 410 should be present for all commands. The values 420 for the "name" and "sequence" ATTORNEY DOCKET NO. 18814-104WO1 / P6130WO1
elements are strings. The value for the "params" element should be a dictionary. A dictionary is a map of key/value pairs. The keys are strings, and the values are other types, depending on the specific command. In addition, for each command element, the value type 420 is shown in the second column of the table. The third column 430 indicates whether the command element is required. Further, a short description
440 of each command element is shown in the last column.
[00117] Similar to the messages, the commands can assign an integral value to the sequence element that monotonically increases for each session. For example, the integral value can start at "1 " and monotonically increase for each session.
Based on the detected value of the sequence element, the recipient processes the commands in the sequence order.
[00118] The name element is a required element that indicates the command's name. The value of the name element is a string.
[00119] Command requests use the params element to pass the parameters for the command to the recipient. The params element is a required element having a value that includes a dictionary. Specific parameter elements and values may vary depending on the specific command as shown in FIG. 4.
[00120] The more element is required to be in the command when the sender needs to indicate that the command is split into fragments. Each fragment reuses the original command's "sequence" value. When present, the value of the more element is the Boolean value "TRUE".
[00121] FIG. 5 is a table showing example command response elements. The command response elements include "name", "sequence", "params", "more", "result" and "response." For each command response element, a value type 520 is provided. The values of the name and sequence elements are strings, for example.
The value of the params element is a dictionary. The values of the more and response elements are the Boolean value "TRUE", and the value of the result element is an array.
[00122] The third column 530 of the table shows whether the command response elements are required. In addition, for each command response, a short description
540 is presented in the fourth column of the table. For example, the name element describes the name of the command, such as "get." Also, the sequence element for a command response corresponding to a command request should have an identical sequence value as the parent command request. Similar to the command, the ATTORNEY DOCKET NO. 18814-104WO1 / P6130WO1
params element is used by the command response to pass the parameters for the command response to the recipient. The params element is a required element having a value that includes a dictionary. Specific parameter elements and values may vary depending on the specific command response as shown in FIG. 5. In addition, the command responses use the same parameter values as their associated command requests.
[00123] The response element indicates that a message body item is a command response. Absence of the response element indicates that the body is a command request. The value of the response element is a Boolean with the value "TRUE". [00124] Command responses use the sequence element assigned with integral values. As described above, the values assigned to the sequence element correspond to a command sequence previously sent by the recipient. The recipient processes the command responses in sequence order based on the sequence values. Normally, the sender sends exactly one command response per command received in a given message. However, if the status for the command response is S_NotCompleted (indicating that processing of the command has not yet completed), the sender may send another command response for the command in a subsequent message. Alternatively one command response can be sent per command fragment if the command was split into various fragments. [00125] The result element is a required element included in the command responses. The value of the result element is an array of one or more status items indicating the results of the command request. When a command could not be completed in a timely manner, for example before the client's transport request times out, the recipient may return a status, such as S_NotCompleted (602) to indicate that the command was not completed. This status does not indicate success or failure of the command, but instead informs the sender of the command that results will be available later in the session. When the session terminates before a final status is received, a failure status, such as E Failed staus is assumed. Unknown command requests result in an unknown status value, such as E UnknownCommand (608). Also, unexpected commands for stateful commands result in a state error value, such as E_StateError (610). ATTORNEY DOCKET NO. 18814-104WO1 / P6130WO1
[00126] When the recipient encounters an error while processing a stateful command, subsequent stateful commands for the same command family in the message may not be processed at all. In this case, the status, such as E CommandNotProcessed (609) is returned for these commands to indicate that the commands were not processed. Depending on the situation, the sender may reattempt those commands. [00127] Command Definitions
[00128] FIGS. 6, 7, 8, 9, 10, 1 1 , 12, 13, 14, 15, 16, 17, 18 and 19 are tables showing examples of commands and command definitions. The synchronization protocol 140 defines these commands that are available to send during a sync session. This listing of commands is not an inclusive list. Additional commands can be added to scale and extend the synchronization protocol to provide other services. [00129] Primitive commands
[00130] The commands listed in FIGS. 6, 7, 8, 9, 10 and 1 1 are stateless commands that can modify an arbitrary resource on the recipient. The available stateless commands include "get", "put" and "delete". These stateless commands can implement object exchange or RESTful semantics within the synchronization protocol 140. Each command can include one or more parameters, such as "uri", "value", "item-type", "items", "idmap", "userid", "authtype", "auth", "version", "anchors", etc. Some of these parameters are required, while others are optional. [00131] For example, the "uri" parameter is a required parameter with a string value assigned. The "uri" parameter can specify the desired resource to access. The synchronization protocol 140 does not specify whether the "uri" parameter represents an actual resource on the client device 1 10 or server 120, for example a file system path or a virtual resource. The type of the "value" parameter is determined by the client device 1 10 and the server 120. In addition, the type of the "value" parameter is not specified by the synchronization protocol 140. The logical type of the "value" parameter may be explicitly specified using the "item-type" parameter. Regardless, the representation of the "value" parameter must be a valid property list type.
[00132] The recipient may use the message's "userid" as the authorized principal for the purposes of limiting access to the indicated URI. If the session authorization is insufficient, the "userid" , "authtype" and "auth" elements may optionally be included in the command. ATTORNEY DOCKET NO. 18814-104WO1 / P6130WO1
[00133] FIG. 6 is a table showing the get command with its associated parameters 610 that includes "uri", "userid", "authtype" and "auth". Each of these parameters is assigned a string value 620. The table also shows whether any of the parameters are required 630. While the uri parameter is required (indicated by the check mark), the rest of the parameters may be optionally included with the get command. Also, the descriptions 640 of the parameters are provided. The value of the uri parameter describes the URI of a data object to retrieve. The value of the optional userid parameter describes whether to optionally override the message's userid. The value of the optional authtype parameter can describe the optional authentication type. The value of the optional auth string value can describe the optional authentication credential.
[00134] FIG. 7 is a table showing example parameters 710 for the get command response. The example parameters include "uri", "value" and "item-type." The associated parameter value 720 is a string for these parameters. The fourth column 730 shows that the uri and value parameters are required while the item-type is optional. The descriptions 740 of the parameters are also shown. Similar to the get command, the uri parameter of the get command response describes the URI of the data object requested by the get command. The value parameter describes the value of the URI. For example, the get command enables the sender to request a desired data object or value from the recipient. In response, the recipient sends a get command response to the sender of the get command. The get command response includes a value parameter to return the result value for the URI indicated by the get command. Further, the optional item-type parameter for the get command response describes the type of the value.
[00135] FIG. 8 is a table showing example parameters for the put command. The put command enables the sender to transfer an arbitrary data object to the recipient. The example parameters 810 include "uri", "value", "item-type", "userid", "authtype" and "auth". The table shows that each of these parameters 810 is assigned a string parameter type 820. Also, the tables show whether the parameters are required 830. For example, the uri and value parameters are required while the rest are optional. The last column shows the description 840 of each parameter 810. The value of the uri parameter represents the URI of the data object to replace. The value parameter specifies the value to be put to the recipient. The item-type parameter describes the logical type of the value. The value of the optional userid ATTORNEY DOCKET NO. 18814-104WO1 / P6130WO1
parameter describes whether to optionally override the message's userid. The value of the optional authtype parameter can describe the optional authentication type. The value of the optional auth string value can describe the optional authentication credential.
[00136] FIG. 9 is a table showing example parameters 910 for the put command response. In response to the put command, the recipient sends a put command response that includes the uri parameter. The uri parameter is a required parameter as shown by the check mark in the fourth column 930. The parameter type 920 is a string for the uri parameter. Similar to the put command, the uri parameter describes 940 the URI of the data object that was replaced in response to the put command. [00137] FIG. 10 is a table showing example parameters for the delete command. The delete command includes various parameters 1010 such as "uri", "userid", "authtype" and "auth." The parameter type 1020 is a string for these parameters. The uri parameter is required as shown by the check mark in the fourth column 1030. The rest of the parameters are optional. The descriptions 1040 of the parameters 1010 are similar to those described for the get and put commands. The delete command enables the sender to request removal of the specified URI. [00138] FIG. 1 1 is a table showing an example parameter 1 1 10 for the delete command response. The delete command response includes a uri parameter. The table shows that the uri parameter type 1 120 is a string. The uri parameter is required 1 130 and thus included in the delete command response. The table also includes a description 1 140 of the parameters. For example, the string type uri parameter describes the URI of the object deleted in response to the delete command.
[00139] The commands listed in FIGS. 12, 13, 14, 15, 16, 17, 18 and 19 are stateful commands. The synchronization protocol 70 also provides stateful sync- family commands and command responses. The stateful command includes sync- start, sync-changes, sync-commit and sync-cancel. These stateful commands enable structured data synchronization between the protocol client device 1 10 and server 120. Each of the stateful commands and command responses include the "uri" parameter to identify a dataclass state machine to be affected by a given command.
[00140] FIG. 12 is a table showing example parameters 1210 for the sync-start command. The sync-start command enables the creation of a sync state machine ATTORNEY DOCKET NO. 18814-104WO1 / P6130WO1
for a given dataclass with the recipient. The example parameters 1210 include "uri" and "anchors." The parameter type 1220 is a string for the uri parameter. The parameter type 1220 is a dictionary for the anchors parameter. The "uri" and "anchors" parameters are required parameters as shown by the check mark in the third column 1230.
[00141] The table also includes a description 1240 for each parameter. For example, the uri parameter indicates the dataclass names, such as the string "com. apple. Contacts" for contacts or the string "com. apple. Calendars" for calendars. When detected that the recipient does not support the dataclass, the status E NotSupported (612) is returned. When detected that the dataclass is not enabled, the status E NotAllowed (604) returned. In both these cases, the status "param- name" element should be present and should have the value "uri" to indicate that the uri parameter was the cause of the returned status. The anchors parameter contain information used during the sync negotiation phase. The information can include the requested sync mode ("mode"); the datastore versions ("device_version","server_version"); and sync anchors
("last_device_anchor","next_device_anchor","last_server_anchor","next_server_anch or"). The "device_version" parameter for the anchor element describes the version of the client device 1 10. The "server version" parameter for the anchor element describes the version of the server process 120. The anchors parameter can include device, server, filter and reset anchors. The anchors can be used to request a sync mode. The default sync mode is the fast sync mode. The anchors can be used to specify a sync direction. The default sync direction is "twoway", which indicates that changes will be sent from the client device 1 10 to the server process 120 as well as from the server process 120 to the client device 1 10.
[00142] FIG. 13 is a table that shows example parameters for the sync-start command response. The example parameters 1310 for the sync-start command response can include the "uri" and "anchors" parameters. The parameter types 1320 for the uri and anchors parameters are a string and a dictionary respectively. The table also shows whether these parameters are required parameters 1330. The descriptions 1340 of the parameters are also shown in the table. The uri parameter describes the dataclass names, such as contacts, calendars, etc. The anchors parameter can be provided for the client device 1 10, server 120, filter and reset. In addition, the anchors parameter can be used to indicate the requested sync mode, ATTORNEY DOCKET NO. 18814-104WO1 / P6130WO1
such as fast, slow, and reset. The default sync mode is fast. [00143] When the recipient is willing to sync using the submitted information, the recipient returns a OK status S_OK (600) with the sync-start command response. When the recipient is willing to sync with adjusted parameters (e.g. using a different sync mode than the client requested), the recipient returns a failed-negotiation status, such as E NegotiationFailed (613). When the recipient does not support the supplied sender's version (e.g. "device_version") the recipient returns a status, such as the E VersionNotSupported (612) status to indicate that the version is not supported. When the recipient does not support the desired sync direction (e.g. "direction"), the recipient returns a status, such as the E NotSupported (614) to indicate that desired sync direction is not supported. In all these cases, the status includes the "param-name" parameter with the value "anchors" indicating that elements in the "anchors" parameter of the command were the cause of the unsuccessful status. In addition, the recipient can indicate the desired sync mode and anchors in the command response's "params" dictionary. [00144] When the client device 1 10 wishes to sync multiple dataclasses in parallel, the client device 1 10 sends a separate "sync-start" command request for each dataclass as shown in FIG. 28 below. These commands are included in the same message to enable the server 120 to process the commands within the same sync job. When the server 120 accepts the "sync-start" command received from the client device 1 10, the client device 1 10 begins sending "sync-changes" commands. Sending the "sync-start" command during a session which has already started syncing results in a state error status such as E StateError (610) status. [00145] When syncing multiple dataclasses in a single session, commands for each dataclass operate on distinct state machines. Usually, the server 120 waits until all dataclasses have completed the pull phase or cancelled before mingling the changed data.
[00146] FIG. 14 is a table showing example parameters for the sync-changes command. The parameters 1410 can include "uri", "itemtype", "items", "anchors" and "idmap." The parameter type 1420 for the uri and itemtype parameters is a string. The parameter type for the anchors, items and idmap parameters is a dictionary. The table shows in column four 1430 that the uri, itemtype and items parameters are required while the idmap and anchors are optional. The table also includes descriptions 1440 of these parameters. The uri parameter describes the dataclass ATTORNEY DOCKET NO. 18814-104WO1 / P6130WO1
for the changes requested. The itemtype parameter describes type of the item or data identified in the sync-changes command. The items parameter describes a dictionary of items, such as format/type that depends on the itemtype. The associated keys for the items parameter can be device recordids. The idmap parameter describes a dictionary of GUID-LUID pairs. The associated keys are server record ids and the values are device record ids. The anchors parameter may be included as a "checkpoint anchor". When present, the receiver updates its anchors with the supplied value. Should the session become interrupted, the recipient may start a subsequent sync session with the check point anchors and continue to sync normally without falling into slow sync mode. [00147] The sync-changes command enables the client device 1 10 to send changes to the server 120. Alternatively, the server 120 can send updates to the client device 1 10. The uri parameter indicates the dataclass of the data items to be updated or changed. The type of data item being sent is indicated by the itemtype parameter. The itemtype parameter can indicate that the item parameter represents either full records ("records") or field-level changes ("changes"). When detected that the client device 1 10 requires id mapping, data items are keyed by the device LUID in the items parameter. The format of the dictionaries for the items parameter depends on the item-type. The values of the items parameter are of homogeneous item-type. The items parameter can be an empty array to indicate that no more items need to be sent. For example, the empty array can indicate that there are no changes, or there are no records.
[00148] When detected that there are no device changes or the sync mode is "reset", the client device 1 10 sends a "sync-changes" command with an empty array for the "items" parameter. The "more" Boolean flag element is also included if all appropriate data items for the dataclass are not included in the command params. The "more" Boolean flag element can be used to break up large amounts of synchronization data into smaller chunks. This is useful when the size of the data to be exchanged is larger than the capability of the recipient. For example, the recipient may have message size limitations. Alternatively, the "more" Boolean flag element can enable exchange of multiple item-types for a given dataclass in a single session. When the server 120 has received the last "sync-changes" chunk for all dataclasses from the client device 1 10, the server 120 synchronizes all supplied data with the central database. Then the client-server roles within the protocol session ATTORNEY DOCKET NO. 18814-104WO1 / P6130WO1
become reversed.
[00149] At this point, the client device 1 10 begins processing commands from the server 120. The client device 1 10 can also return command responses to the server 120. Any synchronization data updates from the server are then sent in "sync- changes" commands. When no updates are needed, the server 120 sends a "sync- changes" command with an empty array for the "items" parameter. While processing "sync-changes" command requests from the server 120, the client device 1 10 responds to these commands, and includes any required mapping information for add transactions in the command response's "params" using the "idmap" parameter. The "idmap" parameter is sent in a "sync-changes" command from the client device to update existing mappings. For example, id mappings may be updated independent of the server 120 changing the data entities. Sending the "sync- changes" command during a session before the "sync-start" or after the "sync- commit" or the "sync-cancel" results in an error status, such as the E StateError (610) status. The device 1 10 may omit sending "sync-changes" command response and defer sending the "idmap" parameter until the "sync-changes" command of the subsequent sync session. This may be done in order to reduce the number of transport roundtrips necessary to complete the sync session. [00150] FIG. 15 is a table showing example parameters for the sync-changes command response. The parameters 1510 includes "uri", "anchors" and 'idmap." The table includes the parameter types 1520 for these parameters. The uri parameter is a string type and the anchors and idmap parameters are dictionaries. The table also includes an indication of whether the parameters are required 1530. The uri parameter is required while the anchors and idmap parameters are optional. The table also includes descriptions 1540 of these parameters. The uri parameter indicates the dataclass for the requested changes. The anchors parameter is checkpoint anchors used to indicate specific points where the last sync session left off. The idmap parameter is a dictionary of GUID-LUID pairs with keys that include server record ids. The values of the keys can include device record ids. [00151] FIG. 16 is a table showing example parameters for the sync-commit command. The parameters 1610 for the sync-commit command include "uri" and "anchors." The sync-commit command is used to commit the sync operation. The command indicates that the sender has already committed and is telling the recipient to commit as well. The table shows whether the parameters are required 1630. For ATTORNEY DOCKET NO. 18814-104WO1 / P6130WO1
example, the "uri" parameter is required while the anchors parameter is optional. [00152] The table also shows the parameter type 1620 for the parameters. The uri parameter is a string type, and the anchors parameter is a dictionary. The table also shows the descriptions 1640 of the parameters. The uri parameter indicates the dataclass to commit the sync changes. The anchors parameter is used by the client device 1 10 to send "next_device_anchor" for the server 120 to store. In response, the server 120 sends the "next_server_anchor" to the device 1 10 in the sync-commit command. In addition, the sync mode to use in the next sync is indicated and returned in the sync-commit command. Sending the "sync-commit" command during a session before the final "sync-changes" or after "sync-commit" or "sync-cancel" results in an error status, such as E StateError (601 ) error status. [00153] FIG. 17 is a table showing example parameters for the sync-commit command response. The parameter 1710 includes the "uri" parameter. The parameter type 1720 for the uri parameter is a string. As shown in the fourth column 1730 of the table, the uri parameter is a required parameter that is included in the sync-commit command response. The description 1740 of the uri parameter shows that the uri parameter indicates the dataclass committed during the sync session. The device 1 10 may omit sending "sync-commit" command response in order to reduce the number of transport roundtrips necessary to complete the sync session. By submitting the sync anchor received in the "sync-commit" command as the anchors parameter in the "sync-start" command of the next session, the server 120 can infer that the previous "sync-commit" was received. [00154] FIG. 18 is a table showing example parameters for the sync-cancel command. The sync-cancel command is used to cancel the sync operation. The sync-cancel command indicates that the sender has already cancelled and is telling the recipient to cancel as well. The recipient should rollback any changes it has made for the dataclass to the state represented by the last received sync anchor. The table shows that the parameters 1810 for the sync-cancel command include the "uri" parameter and the anchors parameter. The parameter type 1820 for the uri parameter is a string and the anchors parameter is a dictionary. The table also shows in column four 1830 whether the parameters are required. The uri parameter is required while the anchors parameter is optional. The table also shows the descriptions 1840 of the parameters. The uri parameter indicates the dataclass to cancel the sync. The anchors parameter may be used to specify the anchors and/or ATTORNEY DOCKET NO. 18814-104WO1 / P6130WO1
sync mode to use for the next sync session. Sending the "sync-cancel" command during a session before "sync-start" or after "sync-commit" or "sync-cancel" results in an error status, such as the E StateError (610) error status. The device 1 10 may omit sending "sync-cancel" command response in order to reduce the number of transport roundtrips necessary to complete the sync session. By submitting the sync anchor received in the "sync-cancel" command as the anchors parameter in the "sync-start" command of the next session, the server 120 can infer that the previous "sync-cancel" was received.
[00155] FIG. 19 is a table showing example parameters for the sync-cancel command response. The available parameter 1910 for the command response includes the "uri" parameter. The parameter type 1920 for the uri parameter is a string. The table also shows in the fourth column 1930 an indication of whether the parameter is required. The uri parameter is required to be included in the command response as indicated by the check mark. The table also includes a description 1940 of the uri parameter. The uri parameter indicates the dataclass to cancel the sync.
[00156] Status
[00157] FIG.20 is a table showing example status elements. The example status elements are show in the first column 2010 with the corresponding values shown in the second column 2020. The third column 2030 of the table shows whether the status element is required. Also, the last column 2040 of the table shows a short description for each status element.
[00158] The status resulting from the processing of a given command or message is represented by the "status" element. A single status element may appear in the message header. When the message was not processed, the corresponding status element is included in the message header. An array of "status" elements is included in the "results" parameter of command responses. [00159] Status elements indicate the results of a command request. A status item is a Dictionary. The dictionary may contain the "status" element and contain the "code" elements to indicate the result status of the corresponding command request. The value for the "status" element is a string. The value for the "code" element includes an integer string or an integer. The "description" element is an optional element that may be present in the command. The value of the "description" element is a string. The "description" element is purely informational and has no ATTORNEY DOCKET NO. 18814-104WO1 / P6130WO1
effect on the processing of the command.
[00160] The "param-name", "param-key" and "param-index" elements MAY be present. They are used to provide multi-status responses for certain commands. The " param-name" value MUST be a String and indicates to which parameter in the command request this Status item corresponds. The "param-index" value MUST be either a String or an Integer. It MUST be present if the "param-name" element is present and it's value in the command request was an Array. The value of the "param-index" indicates the index of the "param-name" item in the command request to which this Status item corresponds. Index values are zero-based. The "param- key" value MUST be a String. It MUST be present if the "param-name" element is present and it's value in the command request was a Dictionary. The value of the "param-key" indicates the value of the key of the "param-name" item in the command request to which this Status item corresponds.
[00161] The "param-name" "param-key" and "param-index" elements may also be present. They are not required elements and can be used to provide multi-status responses for certain commands. The value of the "param-name" status element is a string that indicates to which parameter in the command request this status element corresponds. The value of the "param-index" element can be either a string or an integer. The "param-index" status element is included in the status dictionary when the "param-name" status element is present and the value of the parameter matching the value of the "param-name" status element in the command request was an array. The value of the "param-index" status element indicates the index in the array parameter item for the parameter whose name corresponds to the value of the "param-name" status element in the command request to which the status element corresponds. The value of the index status element is zero-based. The value of the "param-key" element is a string that indicates to which parameter in the command request this status element corresponds. The value of the "param-key" status element is a string. The "param-key" status element is included in the status dictionary when the "param-name" status element is present and the value of the parameter matching the value of the "param-name" status element in the command request was a dictionary. The value of the "param-index" status element indicates the key in the dictionary parameter item for the parameter whose name corresponds to the value of the "param-name" status element in the command request to which the status element corresponds. ATTORNEY DOCKET NO. 18814-104WO1 / P6130WO1
[00162] The indices in a status refer to the index of the param which resulted in the status, if the original param was an Array. Indices start counting from a zero-basis.
This zero-basis mechanism enables the a sparse array of statuses to be returned.
For example, consider a command (named "examplecommand") shown below that has a parameter "items" which is an array. Suppose that all but two of the items in the command are well formed with the second and fifth items having values ("bad").
<dict>
<key>name</key>
<string>examplecommand</string>
<key>sequence</key> <string>3</string>
<key>params</key>
<dict>
<key>items</key>
<array>
<string>good</string>
<string>bad</string>
<string>good</string>
<string>good</string>
<string>bad</string>
<string>good</string>
<string>good</string>
</array>
</dict>
</dict>
[00163] The command response to the above "examplecommand" may be presented as follows:
<dict>
<key>name</key>
<string>examplecommand</string>
<key>sequence</key> <string>3</string>
<key>response</key> <true/>
<key>result</key> ATTORNEY DOCKET NO. 18814-104WO1 / P6130WO1
<array>
<dict>
<key>codθ</kθy>
<string>602</string>
<key>status</key>
<string>S_Ok</string>
</dict>
<dict>
<key>codθ</kθy>
<string>607</string>
<kθy>param-namθ</kθy>
<string>items</string>
<kθy>param-indθx</kθy>
<string>1 </string>
</dict>
<dict>
<key>code</key>
<string>607</string>
<kθy>param-namθ</kθy>
<string>itθms</string>
<kθy>param-indθx</kθy>
<string>4</string>
</dict>
</array>
</dict>
[00164] This shows that there are multiple statuses to be returned for the command with all but the ones indicated being successful. However, the value supplied for the param "items" at index 1 (counting from zero, so, the second item in the command list) was a bad value (status code 607). The same case for the 5th item (index 4). This mechanism enables non-reporting of statuses for every other item that succeeded. This mechanism can significantly decrease the bandwidth usage requirement when numerous items are sent to the server and only a few fail. [00165] When multiple statuses need to be returned in a single command ATTORNEY DOCKET NO. 18814-104WO1 / P6130WO1
response, a sparse array of statuses may be represented by including a status, such as S_MultiStatus (601 ) as the first element of the status array. Subsequent status elements may then indicate the parameter index value and a distinct status for any failed parameter elements for which the parameter type was an array. Alternatively, subsequent status elements may indicate the parameter key value and distinct status for any failed parameter elements for which the parameter type was a dictionary.
[00166] Status codes in a certain range, such as the status code range 600-699 can be reserved for general statuses. Status codes in another range, such as the range 700-799, can be reserved for errors returned by the server and generally lead to termination of the current session.
[00167] FIG. 21 is a table showing example status codes for the statuses available to be included in the commands and the command responses. The first column 21 10 describes the available statuses. The associated status codes are shown in the second column 2120. The third column 2130 shows a description for each status. The last column 2140 shows the parent element or parameter for each status.
[00168] The table describes success statuses and error statuses. In the example shown in FIG. 21 , the "S_OK" status is assigned the code 600 to indicate a success. The parent element may be a message header or command response. The other success status is the "S-MultiStatus" status assigned to code 601 to indicate a success with multi-valued statuses. The parent element is a command response. [00169] The error statuses include the "E-NotCompleted" status assigned to code 602 to indicate that command processing for the command has not yet completed. The parent element is a command response. The "E NotFound" error status is assigned to code 603 to indicate that the indicated data object or URI was not found. The parent element is a command response. The "E NotAllowed" error status is assigned to code 604 to indicate that the operation is not permitted that may be due to insufficient access rights, for example. The parent element is a command response. The "E MissingParam" error status is assigned to code 605 to indicate that the command was missing a required parameter. The "E ParamError" error status is assigned to code 606 to indicate that a supplied parameter was incorrect. The parent element is a command response. The "E BadValue" error status is assigned to code 607 to indicate that a bad value was supplied. The parent element ATTORNEY DOCKET NO. 18814-104WO1 / P6130WO1
is a message header or command response. The "E UnknownCommand" is assigned to code 608 to indicate that an unknown command was issued and ignored. The parent element is a command response. The "E CommandNotProcessed" error status is assigned to code 609 to indicate that a command was not processed due to errors processing a previous command. The parent element is a command response. The "E StateError" is an error status assigned to code 610 to indicate that an unexpected command was received based on the command family's current state machine. The parent element is a command response. The "EJJmitExceeded" error status is assigned to code 61 1 to indicate that too many items were supplied. The parent element is a command response. The "E VersionNotSupported" error status is assigned to code 612 to indicate that the protocol or command version is not supported. The parent element is a message header or command response. The "E NegotiationFailed" error status is assigned to code 613 to indicate that the sync mode negotiation failed. The parent element is a command response. The "E NotSupported" error status is assigned to code 614 to indicate that an unsupported or unimplemented operation was attempted. The parent element is a message header or command response. The "E Failed" error status is assigned to code 615 to indicate a generic failure. The parent element is a message header or command response. The "E Canceled" error status is assigned to code 616 to indicate that the current state machine has been cancelled. The parent element is a command response. The "E ServiceBusy" error status is assigned to code 700 to indicate that the server 120 is too busy and could not process the message. This status code also indicates that the device 1 10 should retry the command again soon. The parent code is a message header. The "E ServiceUnavailable" error status is assigned to code 701 to indicate that the serve 120 is unavailable and could not process the message. This status code also indicates that the device 1 10 should retry again soon. The parent element is a message header. The "E ServiceError" error status is assigned to code 702 to indicate that the server 120 had an internal error. The parent element is a message header or command response. The "E BadRequest" error status is assigned to code 703 to indicate that the server 120 could not understand the message. The parent element is a message header. The "E RetryLater" error status is assigned to code 704 to indicate that the server 120 needs the client device 1 10 to retry at a later time. The parent element is a message header. ATTORNEY DOCKET NO. 18814-104WO1 / P6130WO1
[00170] FIG. 22 is a table showing the effects of receiving a given status for a command. The indicator "C" indicates that a failure for that command receiving the status only. The indicator "F" indicates a termination of the command family state machine. An example of the termination of the state machine for "sync" commands is an indication that a "sync-cancel" is forthcoming. The indicator "M" indicates that the message was not processed. The indicator "S" indicates that the session will terminate.
[00171] The effect of receiving the "E NotFound" error status is a failure for the get, put and delete commands. For the sync-start, sync-changes, sync-cancel and sync-commit commands, the dataclass state machine is terminated. The effect of receiving the "E NotAllowed" error status is a failure for the get, put and delete commands. For the sync-start, sync-changes, sync-cancel and sync-commit commands, the dataclass state machine is terminated. The effect of receiving the "E MissingParam" error status is a failure for the get, put and delete commands. For the sync-start, sync-changes, sync-cancel and sync-commit commands, the dataclass state machine is terminated. In addition, the message is not processed. The effect of receiving the "E Param Error" error status is a failure for the get, put and delete commands. For the sync-start, sync-changes, sync-cancel and sync- commit commands, the dataclass state machine is terminated. The effect of receiving the "E BadValue" error status is a failure for the get, put and delete commands. For the sync-start, sync-changes, sync-cancel and sync-commit commands, the dataclass state machine is terminated. In addition, the message is not processed. The effect of receiving the "E UnknownCommand" is a failure for the get, put and delete commands. For the sync-start, sync-changes, sync-cancel and sync-commit commands, the dataclass state machine is terminated. The effect of receiving the "E CommandNotProcessed" error status is a failure for the get, put and delete, sync-start, sync-changes, sync-cancel and sync-commit commands. The effect of receiving the "E StateError" error status is that for the sync-start, sync- changes, sync-cancel and sync-commit commands, the dataclass state machine is terminated. The effect of receiving the "E LimitExceeded" error status is a failure for the get, put and delete commands. For the sync-start, sync-changes, sync-cancel and sync-commit commands, the dataclass state machine is terminated. In addition, the message is not processed. The effect of receiving the "E VersionNotSupported" error status is a failure for the get, put and delete commands. For the sync-start, ATTORNEY DOCKET NO. 18814-104WO1 / P6130WO1
sync-changes, sync-cancel and sync-commit commands, the dataclass state machine is terminated. In addition, the session will terminate. The effect of receiving the "E NegotiationFailed" error status is a failure for the sync-start command. The effect of receiving the "E NotSupported" error status is a failure for the get, put and delete commands. For the sync-start, sync-changes, sync-cancel and sync-commit commands, the dataclass state machine is terminated. The effect of receiving the "E Failed" error status is a failure for the get, put and delete commands. For the sync-start, sync-changes, sync-cancel and sync-commit commands, the dataclass state machine is terminated. In addition, the session will terminate. The effect of receiving the "E Canceled" error status is that the dataclass state machine is terminated for the sync-start, sync-changes, sync-cancel and sync- commit commands. The effect of receiving the "E ServiceBusy" error status is that the session will be terminated. The effect of receiving the "E ServiceUnavailable" error status is that the session will be terminated. The effect of receiving the "E ServiceError" error status is that the session will be terminated for all commands. The effect of receiving the "E BadRequest" error status is that the session will be terminated. The effect of receiving the "E RetryLater" error status is that the session will be terminated. [00172] Anchors
[00173] Synchronization state information such as the sync mode, sync direction, agent versions, and sync anchors are exchanged between the device and server at various times. The "anchors" element included in the commands and command responses, as shown in FIGS. 12-20, is used to bundle this information. The "anchors" element is implemented as a Dictionary.
[00174] FIG. 23 is a table showing example keys for the anchors element. The table includes columns that show examples of sync anchor keys 2310, the associated key types 2320 and descriptions 2330 of the keys. The "mode" key represents the desired or negotiated sync mode. The mode key can optionally be present in the anchors element. When present, the value of the mode key is implemented as a String, and the string value includes "slow", "fast", or "reset" to represent the sync mode. When the value of the mode key is not present, the receiver of the message infers the value to be "fast". Thus, in absence of the mode key value indicated by the sender, the fast sync mode is assumed by the recipient. [00175] The "direction" key represents the desired or negotiated sync direction. ATTORNEY DOCKET NO. 18814-104WO1 / P6130WO1
The value of the direction key can optionally be present in the anchors element. When present, the value of the direction key is implemented as a String, and the string value can include "to_server", "to_device", or "twoway". Thus, these values indicate the sync direction as syncing from the device 1 10 to the server 120, syncing from the server 120 to the device 1 10 or both. When the value of the direction key is not present, the receiver infers the value as "twoway.
[00176] The "device_version" key is sent by the device 1 10 and represents the device datasource agent version. When present, the value of the device_version key is implemented as a String. This information can be used by the server 120 to infer behaviors or capabilities specific to a given version of the device software. The server 120 can determine that synchronization is not permitted with a given device agent version, for example.
[00177] The "server version" key is sent by the server 120 and represents the server's datasource agent version. When present, the value of the server version key is implemented as a String. This information can be used by the device 1 10 to infer behaviors or capabilities specific to a given version of the server software. The device 1 10 can determine that synchronization is not permitted with a given server agent version, for example.
[00178] The actual anchors are exchanged using the keys "last_device_anchor", "next_device_anchor", "last_server_anchor" and "next_server_anchor". The value for each of these keys can be present in the "anchors" dictionary. When present, the value for each of these keys is implemented as a String. When not present, the recipient infers the last known value for the keys.
[00179] The values of the keys for the anchors element are considered opaque, and an entity should not attempt to decode or infer meaning from another entity's anchor keys. For example, a client device should not make any assumptions regarding the "next_server_anchor" or the "last_server_anchor". [00180] Synchronization Protocol Features
[00181] When the client device 1 10 sends the differences (i.e., the changed, deleted or new data) to the server 120, the client device 1 10 indicates whether "record level differences" (RLD) or "field level differences" (FLD) is used via the "item-type" parameter of the "sync-changes" command. The value "change" in the "item-type" parameter indicates FLD, while the value "record" indicates RLD. Devices that support RLD send the entire data set for a given changed record for a ATTORNEY DOCKET NO. 18814-104WO1 / P6130WO1
particular dataclass. In contrast, devices that support FLD send only the changed properties for changed records in the data set for the dataclass. [00182] An optimization is supported for RLD, which enables the client device 1 10 to send a special value, such as "+**no--change**+" indicating that a given property has not changed, and has not been deleted. This helps to avoid sending large data items, such as contacts images that have not changed. [00183] Id mapping
[00184] When detecting that the datastore, in the client device 1 10 for example, for a dataclass wishes to use id mapping, the "idmap" parameter can be included in the command or the command response for a "sync-changes" command from the server 120. The value of the "idmap" parameter is a dictionary that maps server universal unique identifications (UUIDs) to client device 1 10 local unique identifications (LUIDs). Thereafter, the server 120 refers to the mapped entity using the client device 1 10 LUID. [00185] Optimizations
[00186] Broken sessions can cause message/packet loss for wireless communications. The synchronization protocol 140 enables recovery from broken sessions without falling out of "fast" sync. By maintaining "fast" sync even in the event of a broken session, the number of communication round trips are reduced. The reduced number of roundtrips can reduce or minimize message/packet loss. [00187] The synchronization protocol 140 is designed to minimize the number of transport messages (HTTP request/response roundtrips) in normal circumstances. The ability to remain in "fast" sync mode can minimize the bandwidth usage and effort for each sync process by exchanging smaller amounts of data. Moreover, frequent fast syncs mean the device 1 10/server 120 pair never drift much from one another. In other words, the device 1 10 and the server 120 remain more in sync than possible without fast sync. Also, this wireless "trickle syncing" can yield a better user experience.
[00188] Certain events can cause a fast syncing pair (e.g., client device 1 10 and server 120 pair) to resort to a less efficient sync mode (e.g., slow sync mode). These events can include device data corruption, interrupted sync sessions, failure to agree on consistent sync anchors, data structure reset (e.g., when a user pushed an entirely new data set for the dataclass from another machine). The synchronization protocol 140 can avoid being pessimistic and minimize ore eliminate ATTORNEY DOCKET NO. 18814-104WO1 / P6130WO1
the need to fall back to slow sync whenever a problem occurs. [00189] The synchronization protocol 140 implements various techniques to optimize data sync between the client device 1 10 and the server 120. For example, optimization techniques include sync phase compression that enables optimistic negotiation and commit; implementing multiple dataclass state machines in parallel; using sync anchor checkpoints; and enable session robustness. [00190] FIG. 24 shows an example of a sync session. A sync session between the client device 1 10 and the server 120 includes exchange of various messages 2410, 2420, 2430, 2440, 2450 and 2460. For example, message 1 2410 is sent by the sender to the recipient. In the example shown in FIG. 24, the sender is the client device 1 10 and the recipient is the server 120. Message 1 2410 includes the sync- start command to negotiate a sync mode for the sync session. In response to message 1 2310, the recipient sends message 2 2420 that includes a command response, such as sync-start command response. The command response includes a status to indicate whether the command included in message 1 2410 was successful, failed, etc. End the end of message 2 2420, a first round trip is concluded. As needed, additional messages n, n+1 , n+2, etc. can be exchanged to complete a sync session. The sync session can end at the receipt of the final message n+1 , for example. In some implementations, additional optional messages 2450, 2460, etc. can be exchanged.
[00191] FIG. 25 shows an example of an optimal fast or reset data sync between the client device 1 10 and the server 120. Sync phase compression enables the client device 1 10 to compress distinct sync state machine phases. For example, when the client device 1 10 believes the likely sync mode will be "fast" or "reset", the client device 1 10 sends negotiation ("sync-start") and pull phase commands ("sync- changes") in the first message 2510 to the server 120. Sync phase compression can minimize or eliminate wasted network traffic in case the server 120 rejects the requested sync mode. In the example shown in FIG. 25, the client device 1 10 sends a first message 2510 that includes the "sync-start" and "sync-change" commands. However, the server 120 may not send a "sync-commit" command in the second message 2520. Instead, the server 120 sends a "sync-start" response, a "sync- changes" response, and a "sync-changes" command in the second message 2520. In the second round trip 2530, the client device 1 10 sends a sync-change response and a "sync-commit" command. The server 120 responds with a "sync-commit" ATTORNEY DOCKET NO. 18814-104WO1 / P6130WO1
response.
[00192] FIG. 26 shows another example of an optimal fast or reset sync between the client device 1 10 and the server 120. The client device 1 10 sends negotiation ("sync-start") and pull phase commands ("sync-changes") in the first message 2610 to the server 120. The sync-start negotiation command can include parameters that indicate the dataclass, the anchors and the sync mode. In the example shown in FIG. 26, the fast sync mode is indicated.
[00193] In the example shown in FIG. 26, the sync server 120 compresses the push and commit phases by sending its "sync-changes" and "sync-commit" commands for a given dataclass in the same message. In response to sync-start and sync-change commands, the server 120 replies with a sync-start command response (OK, dataclass, anchors) and sync-change command response (OK, dataclass) in the second message 120. In addition, the server 120 can include a sync-changes command (dataclass, changes) and a sync-commit command (dataclass anchors) in the second message 2620 to complete one round trip. Thus, the optimistic approach can complete data synchronization in a single HTTP roundtrip.
[00194] A data sync can be completed in two roundtrips when the client device 1 10 responds to the server's 120 "sync-changes" command in the second message 2620 with an optional message for id mapping in the second round trip 2630. The client device 1 10 can also send a sync-commit response in the optional message. [00195] In some implementations, the client device 1 10 may defer sending id mappings to the server 120 until a subsequent session and may omit sending the sync-commit response, since the server 120 can infer that the commands were received and processed by comparing the sync anchors sent in the subsequent session. FIG. 27 shows an example data synchronization between a client and a server, where the device omits sending the command response to "sync-changes" or "sync-commit" when the server's previous message was final. In that case, any pending id mappings (if necessary) is sent to the server 120 in the subsequent sync session.
[00196] In the first message 2710, the client device 1 10 compresses the negotiation and pull phases as described with respect to FIG. 25. In response, the server 120 sends a second message 2720 with the push and commit phases compressed as described with respect to FIG. 26. The first session is completed in ATTORNEY DOCKET NO. 18814-104WO1 / P6130WO1
one round trip.
[00197] A second sync session is initiated by the client device 1 10 with the pull and negotiation phases compressed in the third message 2730. In addition, the pending id mappings leftover from the first session is sent to the server 120. The server 120 responds in the fourth message 2740 with sync-changes and sync- commit commands.
[00198] FIG. 28 illustrates an example of a slow sync. When the client device 1 10 believes the next sync mode will be "slow" sync mode, the client device 1 10 does not compress the negotiate and pull phase because sending it's entire data set in the initial request message 2810 to the server 120 can be expensive with respect to processing cost, for example. In addition, when detecting that the server 120 has negotiated to a "reset" sync mode, sending the data would have been wasted bandwidth.
[00199] In this slow sync mode, the client device 1 10 sends a sync-start command with the dataclass, anchors and the slow sync mode identified in the first message 2810. The server 120 responds in the second message 2820 with a sync-start response. In the third message 2830 (second round trip), the client device 1 10 sends a sync-changes command for a dataclass. The server 120 responds in the next message 2840 by including a sync-changes response (OK, dataclass), sync- changes command (dataclass) and sync-commit command (dataclass, anchors). In the third round trip 2850, the client device 1 10 sends a sync-changes response (OK, dataclass, idmap) and a sync-commit response (OK).
[00200] FIG. 29 shows an example of syncing multiple data classes in parallel. Implementing multiple dataclass state machines in parallel ("parallelism") enables multiple dataclasses to sync in parallel. Each dataclass, as specified by the "uri" required parameter in all "sync" family commands, operates its own distinct state machine. Thus, in the optimal case, all dataclasses can fast sync in a single transport roundtrip. In comparison, other synchronization protocols such as Open Mobile Alliance - Data Synchronization protocol (formerly known as the SyncML protocol) OMA DS/SyncML sync in series and can require 5 or more roundtrips per dataclass.
[00201] In the example shown in FIG. 29, multiple dataclasses, such as contacts, calendars and bookmarks are synced in parallel. In the first message 2810, the client device 1 10 sends sync-start commands for these dataclasses in parallel. In ATTORNEY DOCKET NO. 18814-104WO1 / P6130WO1
the same message 2910, the client device 1 10 also sends sync-changes command for the multiple dataclasses. The server 120 sends a response 2920 with sync-start responses and sync-changes responses for the multiple dataclasses. For example, the sync-start response from the server 120 states that the calendars dataclass is reset on the server 120 due to a failed negotiation. In addition, the sync-changes response for the calendars states that the changes have not been processed for the calendars dataclass. The sync-start commands for contacts and bookmarks are successful as shown by the OK status of the sync-start response. The sync-changes commands for contacts and bookmarks have not completed, as shown by the S_NotCompleted status of the sync-changes responses.
[00202] In the next message 2930, the client device 1 10 sends another sync-start command requesting a reset sync (the sync mode requested by the server in the previous calendars sync-start command response) and sync-changes command for the calendar dataclass with an empty items parameter. The server 120 responds in the next message 2940 with a sync-start response and a sync-changes response for the contacts, calendars and bookmarks dataclasses; a sync-changes response for the contacts and bookmarks; sync changes command for calendars indicating that more changes are pending; and sync-commit command for contacts and bookmarks. These two message 2930 and 2940 make up the second round trip. [00203] The third round trip begins with a message 2950 from the client device with sync-changes response for contacts, calendars and bookmarks. The message 2950 includes sync-commit responses for the contacts and bookmarks. To complete the third round trip, the server 120 sends a sync-changes command for dataclasses and sync-commit commands to the client device 1 10 in the next message 2960. Thus, in just three transport protocol roundtrips, multiple dataclasses syncing, sync mode renegotiation (calendars were reset on the server), and split sync-changes (calendar changes from the server were sent in message 2940 and message 2960) can be completed.
[00204] An optional fourth roundtrip 2970 can be implemented to enable the client device 1 10 to send a sync-changes response for the calendars with idmap and a sync-commit response to the server 120. ATTORNEY DOCKET NO. 18814-104WO1 / P6130WO1
[00205] The server 120 does not perform the mingle phase until all dataclasses have completed the pull phase (i.e. upon receipt of the third message). This enables the server 120 to perform all work in a single sync job. The server sends S_NotCompleted for the dataclasses other dataclasses until all the client 1 10 changes for all dataclasses has been received by the server 120. [00206] Sync Anchor Checkpoints
[00207] The synchronization protocol uses the "sync anchors" parameter in the commands and command responses to organize and maintain trackable sync sessions. The server 120 can manage the anchors in the commands and the command responses vis-a-vis its internal versioning methods. [00208] Sync anchors are opaque data that the client device 1 10 and the server 120 exchange during the sync process. The anchors can be exchanged during the negotiation phase to determine the sync session's sync mode. Then, during the commit phase, a new set of anchors can be exchanged and persisted for use during the following sync sessions. By comparison, other sync protocols use the anchors at the beginning of the sync session, and the anchors are updated only when the sync session completes successfully, or are rolled back if the session is cancelled or terminates unexpectedly.
[00209] Any discrepancy between expected and actual anchors during negotiation (known as anchor mismatch) can result in a slow sync, or at the very least, retransmission of all data from the failed sync session. On an unreliable data- network, this can lead to a situation where no progress can be made and synchronization with the server is effectively blocked from successfully completing a sync until external conditions change. Unexpected session failures can also lead to anchor mismatches on the next sync session.
[00210] The OTA synchronization protocol 140 enables the server 120 to optionally return updated anchors at various checkpoints during a sync session. The "anchor" parameter may be present in any sync family command or command response. A checkpoint anchor contains the "next_server_anchor" element and may contain the "mode" element. This enables fine-grained updating of sync anchors to reduce the likelihood and impact of anchor mismatches. Each server anchor is encoded with information that provides the server 120 with precise information regarding the internal server state at the time the anchor was generated. For example, the server anchor can be encoded with information on whether the ATTORNEY DOCKET NO. 18814-104WO1 / P6130WO1
changes requested from the client device 1 10 have been mingled with the central database. The server anchor can also be encoded with information on which updates have been accepted by the client device 1 10. Further, the server anchor can be encoded with information on whether the sync session was completed normally. Other internal server states can be encoded in the server anchor. [00211] Example anchor checkpoints can include the "end of server mingle phase" in response to the client device's final "sync-changes" command. The anchor checkpoints can also include the point during a split "sync-changes" and the commit phase among others.
[00212] The server 120 can intelligently decide the time and location to add the checkpoint anchors. When the checkpoint anchors are placed in a "sync-changes" command, the checkpoint anchors guarantee that the received data set enforces the data integrity requirements of the dataclass's schema. For example, the data integrity requirements can include having no references to unknown entities in a check pointed data set. After the pull phase is complete, the most recent checkpoint anchors may be saved by the client device 1 10, even if the sync session is cancelled.
[00213] The sync server 120 will expire the checkpoint anchors when they are no longer needed, or when the server needs to release associated server-side resources used to maintain the checkpoint state. When the client device 1 10 supplies an unknown or expired checkpoint anchor, the sync session will still fall into slow sync mode.
[00214] During the next sync session's negotiation phase, the "sync-start" command, the client device 1 10 sends its last saved anchors to the server 120. The server 120 uses the information encoded in these anchors to start a sync session from the most recent saved checkpoint, even if the previous sync session terminated unexpectedly or a "sync-commit" command response was not explicitly returned to the server 120. When the client device 1 10 receives such anchors during a sync session, the client device 1 10 retains the most recent anchor from the server, and save its value to send in the "sync-start" command for the next sync session. [00215] FIG. 30 shows an example sync session that uses checkpoint anchors. The client device 1 10 initiates a sync session by sending a message 3010. The client device 1 10 uses an anchor, aθ, in the message 3010. This anchor, aO can be the last server anchor value from the previous sync session. The client device 1 10 ATTORNEY DOCKET NO. 18814-104WO1 / P6130WO1
and the sync server 120 exchange other messages 3020, 3030, 3040, 3050 and 3060 as needed. At various points during the sync session, the sync server 120 returns checkpoint anchors a1 , a2, and a3 using these messages 3020, 3030, 3040, 3050 and 3060.
[00216] Upon receiving and processing each message containing an "anchors" element from the sync server 120, the client device 1 10 updates its anchor. When the sync session become interrupted or a message lost, the client device supplies the last anchor it successfully processed in the "sync-start" command of the next session. Depending on which anchor value is received, the sync server 1 10 can infer which actions must be taken to complete the previous sync as necessary. Thus, incremental synchronization progress can be made even on extremely fragile wireless networks or when large data sets need to be sent. [00217] FIG. 31 is a table showing example checkpoint anchors. The table includes columns that describe the possible checkpoint anchors 31 10, the associated sync phases 3120 and server state 3130 associated with the checkpoint anchors. For example, the anchor aO can represent the negotiation phase, which cause no change in the sever state. The anchor a1 can represent the push phase. The server 120 applies the changes requested by the client device 1 10, and the server 120 sends part 1 of its changes to the client device 1 10. The anchor a2 can represent the push phase initiated by the server 1 10. The server sends part 2 of its changes to the client device 1 10. The anchor a3 can represent the commit phase and signal that committing the changes has been completed. This anchor signals that the synchronization session has been completed. [00218] Device Settings
[00219] The synchronization protocol 120 provides a mechanism for the server 120 to dynamically request device settings and capabilities. The "get" and "put" commands may be used to exchange information. At anytime, the server 120 may send a "get" command with the "uri" parameter having the value "deviceinfo" to request device settings and capabilities, for example. Alternatively, the client device 1 10 may send a "put" command with the same "uri" parameter to the server 120. The value of the "uri" parameter is a dictionary containing various key-value pairs. When present, the value for "userid" represents the authenticating principle and is implemented as a String. When present, the value for "authtype" represents the authentication scheme and is implemented as a String. When present, the value for ATTORNEY DOCKET NO. 18814-104WO1 / P6130WO1
"auth" represents the authentication credential and is represented as a String. When the recipient is willing to perform the operation, the recipient returns a success status, such as status S_OK (600). When the requested URI is unknown, the recipient returns a status, such as the status E NotFound (603) to indicate the URI was not found and is unknown. When the requested operation is not permitted , for example the authorized principle is not allowed to delete the URI, the recipient returns a status, such as the status E NotAllowed (604) to indicate that the requested operation is not permitted. When the requested operation could not be performed because the supplied data was incorrect, the recipient returns a status, such as the status E BadValue (607) to indicate that the requested operation could not be performed. When the requested operation could not be performed because the supplied "itemtype" was incorrect, the recipient returns a status, such as the status E NotSupported (614) to indicate that the requested operation is not supported.
[00220] FIG. 32 shows a table of example key-value pairs for the "uri" parameter. The available keys 3210 for the "uri" parameter includes version, msisdn, deviceid, name, model, carrier and dataclasses. The associated values 3220 for the version, msisdn, deviceid, name, model and carrier keys are string values. The value 3220 for the dataclasses key is a dictionary. The table also shows the associated description 3230 for these keys. For example, the version key-value can describe the product version, such as version 1 .1 .4. The msisdn key-value can describe the phone number of a currently installed SIM card. The deviceid key-value can describe the ICCID. The name key-value can describe the user's device name, such as EctoPhone. The model key-value can describe the model of the client device 1 10, such as iPhone®, iPod Touch®, etc. The carrier key-value can describe the carrier name, such as AT&T®, Verizon®, etc. The dataclasses key-value can describe
[00221] When the client device 1 10 first syncs with the server 120, the server 120 requests for device information by sending a "get" command. Thereafter, when the device information changes, the client device 1 10 sends the changed device information to the server 120 by sending a "put" command. [00222] Filtering ATTORNEY DOCKET NO. 18814-104WO1 / P6130WO1
[00223] Filtering is the ability to constrain a set of data items synchronized with the client device 1 10 based on the values in the data items. For example, a user may want to sync only the contacts contained within a certain set of groups, or the calendar events within a certain time window surrounding the current date. [00224] In a data sharing/managing application, such as iTunes® filter settings are enforced by the computer during cable syncing to constrain or filter the set of data items sent to the client device 1 10, such as iPhone®. The synchronization protocol 140 provides similar filtering functionality in a wireless sync solution. The same filter settings from iTunes® is enforced by the server 120 without requiring any user action. Thus, the filtering can be performed automatically. Alternatively, a user interface (Ul) on the client device 1 10 can be presented to the user to enable the user to display and edit the filter settings to be enforced. [00225] The synchronization protocol 140 enables the filter settings to be exchanged between the client device 1 10 and the server 120 using primitive commands. The filter information is specified using a "uri" parameter of the form "dataclass/<dataclassname>/filter" . The value of the filter information is a dictionary. [00226] FIG. 33 is a table showing example key-value pairs for filter settings. The available keys 3310 for the filter settings include default_container, constrain containers, and discard_after_days. The values 3320 of these filter setting keys are string, array and string respectively. The dataclass 120 of the default_container key includes contacts and calendars. Also, the dataclass 120 of the constrain containers key includes contacts and calendars. The dataclass 120 of the discard_after_days key includes calendar.
[00227] The default_container key describes the identification (LUID) of the container entity, such as the group ID for contacts and calendar ID for events. The constrain containers key describes the set of LUIDs of container entities to include, such as the set of Groups to include. The discard_after_days key describes the number of days after which events older than the described number of days should be deleted.
[00228] FIG. 34 is an example of a diagram in pseudo Backus-Naur Form (BNF). The pseudo Backus-Naur Form is a handy way of describing syntax. BNF is a metasyntax that enables expression of context-free grammars. Context-free grammars can define the syntax of a programming language by using two sets of rules: Lexical rules and Syntactic rules. Augmented BNF is a modified version of ATTORNEY DOCKET NO. 18814-104WO1 / P6130WO1
BNF that uses different naming rules, repetition, alternative, order-independence, and value ranges.
[00229] FIG. 35 shows an example sync session. The example sync session shown in FIG. 35 includes split sync-changes and put filter information. The client device 1 10 sends a negotiation phase command ("sync-start") and a pull phase command ("sync-changes") in the first message 3510 to the server 120. The put command is used to send data items for a specific dataclass. In the example shown in FIG. 35, the dataclass indicated in the put command is contacts. Also, the data items are filtered to constrain the data to be synced for the dataclass. [00230] In the second message 3520, the server 120 responds by sending a sync- start command response with the status "S_OK" to indicate a successful negotiation for the contacts dataclass. In addition, anchors are used to indicate the checkpoint. Also, the server 120 sends a sync-changes command for the contacts dataclass with the "more" Boolean flag indicate that not all appropriate data items for the dataclass are included in the command params. Further, the second message 3520 can be include a put command response with a "S_OK" status indicating a successful put. [00231] In the third message 3530, the client device 1 10 includes a sync-changes command response with the "S_OK" status for the contacts dataclass indicated by the uri parameter. Also, idmap is included to provide GUID-LUID mapping, for example. In the fourth message 3540, the server 120 sends a sync changes command with the uri parameter indicating the contacts dataclass. Also, the "more" Boolean is included to indicate that more data will follow. In the fifth message 3550, the client device 1 10 sends a sync-changes command response with a status "S_OK" to indicate a successful update for the contacts dataclass. In the sixth message 3560, the server 120 sends a sync-changes command and a sync-commit command for the contacts dataclass. The client device 1 10 responds in the seventh message 3570 with a sync-changes command response indicating a successful update. The client device 1 10 also includes a sync-commit response (OK) to indicate the client device has committed the changes. The last message 3580 has an empty message body to indicate a sync session's final message. [00232] FIGS. 36, 37a, 37b, 38a, 38b, 38c, 38d, 39a, 39b, 39c, 40a and 40b represent wiretrace examples for a sync session. FIG. 36 shows a summary of four example messages for a reset sync session. FIGS. 37a and 37b show an example message sent from the client device 1 10 to the server 120. The sync-start command ATTORNEY DOCKET NO. 18814-104WO1 / P6130WO1
includes the uri parameter with the value "com.apple.Contacts" indicate the dataclass. Also, the sync mode is indicated as "reset." The message also includes a sync-changes command with the same dataclass (com.apple.Contacts), and empty changes.
[00233] FIGS. 38a, 38b, 38c and 38d show an example message sent from the server 120 to the client device 1 10. The server 120 sends a sync-start command response with the status "S_OK" to indicate a successful negotiation. The message also includes a sync-changes command response with the status "S_OK" to indicate a successful data update. In addition, the server 120 sends a sync-changes command that sends one contact, phone number and email address. The server 120 also sends a get command to pull device information from the client device 1 10. [00234] FIGS. 39a, 39b and 39c show an example message sent from the client device 1 10. The message includes a sync-changes command response with the status "S_OK" to indicate a successful update of the data items changed. The idmap parameter is provided to indicate the GUID to LUID mapping. The message also includes a get command response with the status "S_OK" to indicate a successful get operation in returning the device information. Further, the message includes a sync-commit command to indicate that the client device 1 10 has committed and the server 120 should commit also.
[00235] FIGS. 40a and 40b shown an example message sent from the server 120. The server 120 sends a sync-commit command response with the status "S_OK" to indicate the server 120 had committed the changes also.
[00236] FIGS. 41 , 42a, 42b, 43a, 43b and 43c show example messages for a fast sync. The client device 1 10 and the server 120 each have one delete. FIG. 41 shows a summary of the two example messages for a fast sync. FIGS. 42a and 42b show an example message sent from the client device 1 10 for a fast sync. The message includes a sync-start command for the negotiation phase. The uri parameter indicates the dataclass as com.apple.Contacts. The sync mode is indicated as fast. The message also includes a sync-changes command to delete a data record for the indicated com.apple.Contacts dataclass. [00237] FIGS. 43a, 43b and 43c show an example message sent from the server 120 in response to the message sent by the client device 1 10. The message ATTORNEY DOCKET NO. 18814-104WO1 / P6130WO1
includes a sync-start command response with the status "S_OK" to indicate a successful negotiation. The message also includes a sync-changes command response with the status "S_OK" to indicate a successful delete of the data record indicated by the client device 1 10. In addition, the server 120 sends a sync-changes command to request another data record delete. The same dataclass, com. apple. Contacts is indicated by the uri parameter in the sync-changes command. Thus, another data record from the com. apple. Contacts is requested to be deleted, this time by the server 120. The message from the server 120 also includes a sync- commit command to indicate that the server 120 has committed the sync and that the client device 1 10 should also commit.
[00238] FIGS. 44a and 44b show an example process for syncing a client device 1 10 and a server 120. The sender initiates 4402 a negotiation phase with the recipient. In this example, the sender is the client device 1 10 and the recipient is the server 120. The negotiation phase is initiated 4402 by sending a message with a stateful sync-family command, such as sync-start. The sync-start command includes a uri parameter that indicates a particular dataclass and an anchors parameter that can include the requested sync mode, datastore versions and/or sync anchors. When syncing multiple dataclasses in parallel, a separate "sync-start" command request is sent for each dataclass. These parallel sync-start commands included in the same message to enable the server to process them within the same sync job. [00239] The server 120 responds 4404 to the negotiation phase by sending a message to the client device 1 10 with a sync-start command response. A determination 4406 is made on whether the negotiation is a success. The dataclass indicated by the uri parameter is detected and analyzed to determine whether the server 120 supports and enables 4424 the dataclass. When detected that the dataclass is not supported, an error status such as "E NotSupported (612)" is generated 4432. The generated error status can be included in the sync-start command response to indicate that the dataclass is not supported. When detected that the server 120 does not enable the dataclass, an error status such as "E NotAllowed (604)" is generated 4432. The generated status is included in the sync-start command response to indicate that the dataclass is not enabled. When detected that the dataclass is supported and enabled, a success status such as "S_OK" is generated 4426. The generated status is included in the sync-start command response to indicate that the server 120 supports and enables the ATTORNEY DOCKET NO. 18814-104WO1 / P6130WO1
dataclass.
[00240] When the anchors parameter of the sync-start command includes a requested sync mode, the requested sync mode is analyzed to determine whether the server 120 accepts 4428 the sync mode. When the sync mode is not accepted by the server 120, an error status such as "E NegotiationFailed (613)" is generated 4434. The generated status is included in the sync-start command response to indicate that the requested sync mode is not accepted. The server 120 may decide 4436 whether to suggest a different sync mode to use. When the server 120 is willing to sync in a different mode, the suggested different mode is included 4438 in the anchors parameter in the sync-start command response. [00241] When the requested sync mode is accepted, a success status such as "S_OK" is generated 4430. The generated success status is included in the sync- start command response.
[00242] When detected that the negotiation is successful, as indicated by the "S_OK" status, the sync session proceeds 4408 to a pull phase. When the sync mode is fast, the client device 1 10 sends the changed records to the server 120. When the sync mode is "slow", all records are sent to the server 120. The changes are sent using the sync-changes stateful commands. The server 120 responds to the sync-changes command with the corresponding sync-changes command response to indicate whether the changes have been accepted. The success status "S_OK" indicates that the changes have been accepted.
[00243] When all changes have been received, the server 120 proceeds 4410 to the mingle phase. When syncing multiple dataclasses in a single session, the sync- changes commands for each dataclass will have distinct state machines. However, the server 120 waits until all dataclasses have completed the pull phase or cancelled before proceeding to the mingling phase. Any detected invalid changes may be rejected by the server 120.
[00244] During the mingle phase, the server decides 4412 whether any conflicts exists for the dataclass. When detected that conflicts exist, the server 120 decides 4416 whether to resolve the conflicts itself or whether to let the user or client device 1 10 resolve the conflicts. When the server 120 resolves the conflicts, the server 120 can rely on heuristics to resolve the conflicts. For example, the client device 1 10 initiating the most recent sync may be selected as the winner. [00245] For some instances such as the dataclass and/or data item, the user/client ATTORNEY DOCKET NO. 18814-104WO1 / P6130WO1
device 1 10 may be selected as the one to resolve the conflicts. Then the detected conflicts are sent to the client device 1 10 to enable the client device 1 10 to resolve the conflicts. Also, the detected conflicts can be presented to the user by displaying the conflicts on a display unit on the client device 1 10, for example. The user can resolve the conflict manually. The result of the conflict resolution may then be sent from the device 1 10 to the server 120 during the next sync session. [00246] The changes from the server 120 (recipient) can be sent to the client device 1 10 during the push phase 4414. The server 120 can send a message to the client device with sync-changes commands to push the changes to the client device 1 10.
[00247] Finally, once all updates have been received, the commit phase is entered 4416. Both sides agree that the sync was successful, persist their current sync anchors, and commit the exchanged data to their respective data stores. In the commit phase, messages are sent with sync-commit commands and command responses.
[00248] Embodiments of the subject matter and the functional operations described in this specification can be implemented in digital electronic circuitry, or in computer software, firmware, or hardware, including the structures disclosed in this specification and their structural equivalents, or in combinations of one or more of them. Embodiments of the subject matter described in this specification can be implemented as one or more computer program products, i.e., one or more modules of computer program instructions encoded on a tangible program carrier for execution by, or to control the operation of, data processing apparatus. The tangible program carrier can be a propagated signal or a computer readable medium. The propagated signal is an artificially generated signal, e.g., a machine-generated electrical, optical, or electromagnetic signal, that is generated to encode information for transmission to suitable receiver apparatus for execution by a computer. The computer readable medium can be a machine-readable storage device, a machine- readable storage substrate, a memory device, a composition of matter effecting a machine-readable propagated signal, or a combination of one or more of them. [00249] The term "data processing apparatus" encompasses all apparatus, devices, and machines for processing data, including by way of example a programmable processor, a computer, or multiple processors or computers. The apparatus can include, in addition to hardware, code that creates an execution ATTORNEY DOCKET NO. 18814-104WO1 / P6130WO1
environment for the computer program in question, e.g., code that constitutes processor firmware, a protocol stack, a database management system, an operating system, or a combination of one or more of them.
[00250] A computer program (also known as a program, software, software application, script, or code) can be written in any form of programming language, including compiled or interpreted languages, or declarative or procedural languages, and it can be deployed in any form, including as a stand alone program or as a module, component, subroutine, or other unit suitable for use in a computing environment. A computer program does not necessarily correspond to a file in a file system. A program can be stored in a portion of a file that holds other programs or data (e.g., one or more scripts stored in a markup language document), in a single file dedicated to the program in question, or in multiple coordinated files (e.g., files that store one or more modules, sub programs, or portions of code). A computer program can be deployed to be executed on one computer or on multiple computers that are located at one site or distributed across multiple sites and interconnected by a communication network.
[00251] The processes and logic flows described in this specification can be performed by one or more programmable processors executing one or more computer programs to perform functions by operating on input data and generating output. The processes and logic flows can also be performed by, and apparatus can also be implemented as, special purpose logic circuitry, e.g., an FPGA (field programmable gate array) or an ASIC (application specific integrated circuit). [00252] Processors suitable for the execution of a computer program include, by way of example, both general and special purpose microprocessors, and any one or more processors of any kind of digital computer. Generally, a processor will receive instructions and data from a read only memory or a random access memory or both. The essential elements of a computer are a processor for performing instructions and one or more memory devices for storing instructions and data. Generally, a computer will also include, or be operatively coupled to receive data from or transfer data to, or both, one or more mass storage devices for storing data, e.g., magnetic, magneto optical disks, or optical disks. However, a computer need not have such devices. Moreover, a computer can be embedded in another device. [00253] Computer readable media suitable for storing computer program instructions and data include all forms of non volatile memory, media and memory ATTORNEY DOCKET NO. 18814-104WO1 / P6130WO1
devices, including by way of example semiconductor memory devices, e.g., EPROM, EEPROM, and flash memory devices; magnetic disks, e.g., internal hard disks or removable disks; magneto optical disks; and CD ROM and DVD-ROM disks. The processor and the memory can be supplemented by, or incorporated in, special purpose logic circuitry.
[00254] To provide for interaction with a user, embodiments of the subject matter described in this specification can be implemented on a computer having a display device, e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor, for displaying information to the user and a keyboard and a pointing device, e.g., a mouse or a trackball, by which the user can provide input to the computer. Other kinds of devices can be used to provide for interaction with a user as well; for example, input from the user can be received in any form, including acoustic, speech, or tactile input.
[00255] Embodiments of the subject matter described in this specification can be implemented in a computing system that includes a back end component, e.g., as a data server, or that includes a middleware component, e.g., an application server, or that includes a front end component, e.g., a client computer having a graphical user interface or a Web browser through which a user can interact with an implementation of the subject matter described is this specification, or any combination of one or more such back end, middleware, or front end components. The components of the system can be interconnected by any form or medium of digital data communication, e.g., a communication network. Examples of communication networks include a local area network ("LAN") and a wide area network ("WAN"), e.g., the Internet. [00256] The computing system can include clients and servers. A client and server are generally remote from each other and typically interact through a communication network. The relationship of client and server arises by virtue of computer programs running on the respective computers and having a client-server relationship to each other.
[00257] While this specification contains many specifics, these should not be construed as limitations on the scope of any invention or of what may be claimed, but rather as descriptions of features that may be specific to particular embodiments of particular inventions. Certain features that are described in this specification in the context of separate embodiments can also be implemented in combination in a single embodiment. Conversely, various features that are described in the context of ATTORNEY DOCKET NO. 18814-104WO1 / P6130WO1
a single embodiment can also be implemented in multiple embodiments separately or in any suitable subcombination. Moreover, although features may be described above as acting in certain combinations and even initially claimed as such, one or more features from a claimed combination can in some cases be excised from the combination, and the claimed combination may be directed to a subcombination or variation of a subcombination.
[00258] Similarly, while operations are depicted in the drawings in a particular order, this should not be understood as requiring that such operations be performed in the particular order shown or in sequential order, or that all illustrated operations be performed, to achieve desirable results. In certain circumstances, multitasking and parallel processing may be advantageous. Moreover, the separation of various system components in the embodiments described above should not be understood as requiring such separation in all embodiments, and it should be understood that the described program components and systems can generally be integrated together in a single software product or packaged into multiple software products. [00259] Only a few implementations and examples are described and other implementations, enhancements and variations can be made based on what is described and illustrated in this application.

Claims

ATTORNEY DOCKET NO. 18814-104WO1 / P6130WO1CLAIMS What is claimed is:
1. A method of synchronizing data, the method comprising: receiving a request to initiate a sync session, wherein the request includes a proposed sync mode for each of one or more dataclasses, and one or more changes to the one or more dataclasses; generating one or more status codes to indicate whether the proposed sync mode for each dataclass is accepted; based on the generated status code, using the accepted sync mode for each dataclass to selectively update one or more data items associated with the one or more changes to the one or more dataclasses; and selectively committing the updated one or more data items at the server.
2. The method of claim 1 , wherein generating the one or more status codes comprises accessing information saved from a previous sync session to determine whether to use the proposed sync mode to synchronize the one or more data items.
3. The method of claim 1 , wherein receiving the request comprises receiving the proposed sync mode for two or more dataclasses in parallel.
4. The method of claim 1 , wherein receiving the request comprises receiving the proposed sync mode that includes a fast sync mode, a slow sync mode or a reset sync mode.
5. The method of claim 1 , wherein the receiving the request comprises receiving the proposed sync mode that includes a fast sync mode that enables exchange of data items to be updated only.
6. The method of claim 5, further comprising reaccepting the fast sync mode after the sync session is interrupted.
7. The method of claim 1 , further comprising completing the sync session in one round trip that includes two messages. ATTORNEY DOCKET NO. 18814-104WO1 / P6130WO1
8. The method of claim 1 , wherein receiving the request comprises: receiving the proposed sync mode and the one or more changes to the one or more dataclasses in a single message from a client device.
9. The method of claim 1 , wherein selectively committing comprises: selectively committing the updated one or more data items at the server when a client device sends a command to commit the updated one or more data items.
10. The method of claim 1 , further comprising: rejecting the proposed sync mode; and responding to the request with a different sync mode.
1 1 . A computer program product, embodied on a computer readable medium, operable to cause a data processing apparatus to perform operations comprising: receiving a request to initiate a sync session, wherein the request includes a proposed sync mode for each of one or more dataclasses, and one or more changes to the one or more dataclasses; generating a status code to indicate whether the proposed sync mode for each dataclass is accepted; based on the generated status code, using the accepted sync mode for each dataclass to selectively update one or more data items associated with the one or more changes to the one or more dataclasses; and selectively committing the updated one or more data items at a data repository.
12. The computer program product of claim 1 1 , further operable to cause a data processing apparatus to access information saved from a previous sync session to generate the one or more status codes.
13. The computer program product of claim 1 1 , further operable to cause a data processing apparatus to receive the proposed sync mode for two or more dataclasses in parallel. ATTORNEY DOCKET NO. 18814-104WO1 / P6130WO1
14. The computer program product of claim 1 1 , further operable to cause a data processing apparatus to receive the proposed sync mode that includes a fast sync mode, a slow sync mode or a reset sync mode.
15. The computer program product of claim 1 1 , further operable to cause a data processing apparatus to receive the proposed sync mode that includes a fast sync mode that enables exchange of data items to be updated only.
16. The computer program product of claim 15, further comprising reinitiating a fast sync mode when the sync session is interrupted.
17. The computer program product of claim 1 1 , further operable to cause a data processing apparatus to complete the sync session in one round trip that includes two messages.
18. The computer program product of claim 1 1 , further operable to cause a data processing apparatus to receive the proposed sync mode and the one or more changes to the one or more databases in a single message from a client device.
19. The computer program product of claim 1 1 , further operable to cause a data processing apparatus to selectively commit the updated one or more data items at the server when a client device sends a command to commit the updated one or more data items.
20. The computer program product of claim 1 1 , further operable to cause a data processing apparatus to perform operations comprising: reject the proposed sync mode; and respond to the request with a different sync mode. ATTORNEY DOCKET NO. 18814-104WO1 / P6130WO1
21 . A synchronization server comprising: a processor configured to operate a transport protocol that enables opening of one or more connections to one or more client devices; and a sync protocol that enables data synchronization between the server and the one or more client devices over the opened one or more connections, wherein the sync protocol enables the server to receive a request to initiate a sync session, wherein the request includes a proposed sync mode for each of one or more dataclasses, and one or more changes to the one or more dataclasses, generate one or more status codes to indicate whether the proposed sync mode for each dataclass is accepted, based on the generated status code, using the accepted sync mode for each dataclass to selectively update one or more data items associated with the one or more changes to the one or more data classes, and selectively commit the updated one or more data items.
22. The server of claim 21 , wherein the processor is configured to access a data repository to update one or more data items based on the received one or more changes.
23. The server of claim 21 , wherein the processor is configured to operate the sync protocol to accept or reject the proposed sync mode for each dataclass based on information saved from a previous sync session.
24. The server of claim 21 , wherein the processor is configured to operate the sync protocol to received the proposed sync mode for two or more dataclasses in parallel.
25. The server of claim 21 , wherein the processor is configured to operate the sync protocol to receive the proposed sync mode that includes a fast sync mode, a slow sync mode or a reset sync mode. ATTORNEY DOCKET NO. 18814-104WO1 / P6130WO1
26. The server of claim 21 , wherein the processor is configured to operate the sync protocol to receive the proposed sync mode that includes a fast sync mode that enables the one or more client devices to send data items to be updated only.
27. The server of claim 26, wherein the processor is configured to operate the sync protocol to receive request to reinitiate a fast sync when the sync session is interrupted.
28. The server of claim 21 , wherein the processor is configured to operate the sync protocol to complete the sync session in one round trip that includes two messages.
29. The server of claim 21 , wherein the processor is configured to operate the sync protocol to receive the proposed sync mode and the one or more changes to the one or more dataclasses in a single message from at least one of the one or more client devices.
30. The server of claim 21 , wherein the processor is configured to operate the sync protocol to selectively commit the updated one or more data items at the server when one of the one or more client devices sends a command to commit the updated one or more data items.
31 . The server of claim 21 , wherein the processor is configured to operate the sync protocol to rejecting the proposed sync mode; and responding to the request with a different sync mode.
32. A method of synchronizing data, the method comprising: sending a request to a server to initiate a sync session, wherein the request includes a proposed sync mode for each of one or more dataclasses, and one or more changes to the one or more dataclasses; receiving one or more status codes indicative of whether the proposed sync ATTORNEY DOCKET NO. 18814-104WO1 / P6130WO1
mode for each dataclass has been accepted by the server; based on the received status code, using the accepted sync mode to receive from the server additional changes to the one or more dataclasses; and committing at a client device the additional changes received from the server.
33. The method of claim 32, further comprising: receiving the one or more status codes that indicate that the proposed sync mode for at least one of the one or more data classes has been rejected by the server; and sending another request that includes a different sync mode than the rejected sync mode.
34. The method of claim 32, further comprising: sending the proposed sync mode and the one or more changes in a single message to the server.
35. The method of claim 32, further comprising: sending the proposed sync mode for two or more dataclasses in parallel.
36. The method of claim 35, wherein sending the proposed sync mode for two or more dataclasses in parallel comprises sending a different proposed sync mode for each of the two or more dataclasses in parallel.
37. The method of claim 35, wherein sending a different proposed sync modes for each of the two or more dataclasses in parallel comprises sending a proposed fast sync mode for one of the dataclasses and a proposed slow sync mode for another of the dataclasses.
38. The method of claim 32, further comprising reinitiating the sync session using the accepted sync protocol after the sync session is interrupted.
39. A computer program product, embodied on a computer-readable medium, operable to cause a data processing apparatus to perform one or more operations comprising: ATTORNEY DOCKET NO. 18814-104WO1 / P6130WO1
sending a request to a server to initiate a sync session, wherein the request includes a proposed sync mode for each of one or more dataclasses, and one or more changes to the one or more dataclasses; receiving one or more status codes indicative of whether the proposed sync mode for each dataclass has been accepted by the server; based on the received status code, using the accepted sync mode to receive from the server additional changes to the one or more dataclasses; and committing at a client device the additional changes received from the server.
40. The computer program product of claim 39, further operable to cause a data processing apparatus to perform operations comprising: receiving the one or more status codes that indicate that the proposed sync mode for at least one of the one or more data classes has been rejected by the server; and sending another request that includes a different sync mode than the rejected sync mode.
41 . The computer program product of claim 39, further operable to cause a data processing apparatus to send the proposed sync mode and the one or more changes in a single message to the server.
42. The computer program product of claim 39, further operable to cause the data processing apparatus to send the proposed sync mode for two or more dataclasses in parallel.
43. The computer program product of claim 42, further operable to cause the data processing apparatus to send a different proposed sync mode for each of the two or more dataclasses in parallel.
44. The computer program product of claim 42, further operable to cause the data processing apparatus to send a proposed fast sync mode for one of the dataclasses and a proposed slow sync mode for another of the dataclasses. ATTORNEY DOCKET NO. 18814-104WO1 / P6130WO1
45. The computer program product of claim 39, further operable to cause the data processing apparatus to reinitiate the sync session using the accepted sync protocol after the sync session is interrupted.
46. A client device comprising: a processor configured to operate a transport protocol that enables opening of one or more connections to a server; and a sync protocol that enables data synchronization between the client device and the server over the opened one or more connections, wherein the sync protocol enables the client device to send a request to a server to initiate a sync session, wherein the request includes a proposed sync mode for each of one or more dataclasses, and one or more changes to the one or more dataclasses; receive one or more status codes indicative of whether the proposed sync mode for each dataclass has been accepted by the server; based on the received status code, use the accepted sync mode to receive from the server additional changes to the one or more dataclasses; and commit at a client device the additional changes received from the server.
47. The client device of claim 46, wherein the processor is configured to operate the sync protocol to: receive the one or more status codes that indicate that the proposed sync mode for at least one of the one or more data classes has been rejected by the server; and send another request that includes a different sync mode than the rejected sync mode.
48. The client device of claim 46, wherein the processor is configured to operate the sync protocol to: ATTORNEY DOCKET NO. 18814-104WO1 / P6130WO1
send the proposed sync mode and the one or more changes in a single message to the server.
49. The client device of claim 46, wherein the processor is configured to operate the sync protocol to send the proposed sync mode for two or more dataclasses in parallel.
50. The client device of claim 49, wherein the processor is configured to operate the sync protocol to send the proposed sync mode for two or more dataclasses in parallel comprising sending a different proposed sync mode for each of the two or more dataclasses in parallel.
51 . The client device of claim 49, wherein the processor is configured to operate the sync protocol to send a proposed fast sync mode for one of the dataclasses and a proposed slow sync mode for another of the dataclasses.
52. The client device of claim 49, wherein the processor is configured to operate the sync protocol to reinitiate the sync session using the accepted sync protocol after the sync session is interrupted.
PCT/US2009/035909 2008-03-04 2009-03-03 Data synchronization protocol WO2009111492A1 (en)

Priority Applications (8)

Application Number Priority Date Filing Date Title
AU2009221998A AU2009221998B2 (en) 2008-03-04 2009-03-03 Data synchronization protocol
CA2717535A CA2717535C (en) 2008-03-04 2009-03-03 Data synchronization protocol
KR1020107022191A KR101167833B1 (en) 2008-03-04 2009-03-03 Data synchronization protocol
GB1016416A GB2471227A (en) 2008-03-04 2009-03-03 Data synchronization protocol
KR1020127004382A KR101343202B1 (en) 2008-03-04 2009-03-03 Data Synchronization Protocol
JP2010549823A JP5280462B2 (en) 2008-03-04 2009-03-03 Data synchronization protocol
KR1020117026597A KR101186042B1 (en) 2008-03-04 2009-03-03 Data synchronization protocol
CN2009801160698A CN102016846B (en) 2008-03-04 2009-03-03 Data synchronization protocol

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US12/042,283 2008-03-04
US12/042,283 US7747784B2 (en) 2008-03-04 2008-03-04 Data synchronization protocol

Publications (2)

Publication Number Publication Date
WO2009111492A1 true WO2009111492A1 (en) 2009-09-11
WO2009111492A4 WO2009111492A4 (en) 2009-11-05

Family

ID=40720000

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2009/035909 WO2009111492A1 (en) 2008-03-04 2009-03-03 Data synchronization protocol

Country Status (9)

Country Link
US (3) US7747784B2 (en)
EP (2) EP2098963A1 (en)
JP (5) JP5280462B2 (en)
KR (3) KR101343202B1 (en)
CN (3) CN103327073B (en)
AU (1) AU2009221998B2 (en)
CA (2) CA2717535C (en)
GB (1) GB2471227A (en)
WO (1) WO2009111492A1 (en)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101923571A (en) * 2010-07-29 2010-12-22 中兴通讯股份有限公司 Method and device for managing terminal data logging
JP2011118771A (en) * 2009-12-04 2011-06-16 Sony Corp Information processor, information processing method, data management server, and data synchronization system

Families Citing this family (55)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7437484B2 (en) 2003-12-29 2008-10-14 International Business Machines Corporation Method for optimizing synchronization
US8495244B2 (en) * 2005-06-29 2013-07-23 Jumpstart Wireless Corporation System and method for dynamic automatic communication path selection, distributed device synchronization and task delegation
CN101494534A (en) * 2008-01-21 2009-07-29 华为技术有限公司 Method, apparatus and system for synchronizing data
US8572965B2 (en) 2008-02-06 2013-11-05 Ihi Corporation High-temperature radiator storage yard generating apparatus
KR101490266B1 (en) * 2008-02-22 2015-02-05 엘지전자 주식회사 Terminal and method for storing and retrieving messages in a converged ip messaging service
US7747784B2 (en) * 2008-03-04 2010-06-29 Apple Inc. Data synchronization protocol
US8621108B2 (en) * 2008-05-08 2013-12-31 Dialogic Corporation System and method for monitoring user interface connectivity state
US8112537B2 (en) * 2008-09-29 2012-02-07 Apple Inc. Trickle sync protocol
US8073887B2 (en) * 2008-10-09 2011-12-06 International Business Machines Corporation Representational state transfer (REST) service import editor
KR20100050072A (en) * 2008-11-05 2010-05-13 삼성전자주식회사 Method for digesting data and data communication system thereby
US9002787B2 (en) * 2009-01-30 2015-04-07 Blackberry Limited Method and apparatus for tracking device management data changes
EP2227047A1 (en) * 2009-03-05 2010-09-08 BRITISH TELECOMMUNICATIONS public limited company Device determination
US8161195B2 (en) * 2009-03-25 2012-04-17 Microsoft Corporation Adaptable management in sync engines
US20100268784A1 (en) * 2009-04-17 2010-10-21 Marc Henness Data synchronization system and method
US8417765B2 (en) * 2009-06-09 2013-04-09 International Business Machines Corporation Method and apparatus to enable protocol verification
US20110196973A1 (en) * 2010-02-05 2011-08-11 Interdigital Patent Holdings, Inc. Method and apparatus for inter-device session continuity (idsc) of multi media streams
US9467338B2 (en) 2010-04-01 2016-10-11 Blackberry Limited Method for communicating device management data changes
US20120023065A1 (en) * 2010-07-20 2012-01-26 Deweese William System and method for managing data on an occasionally connected mobile device
US8438246B2 (en) * 2010-09-15 2013-05-07 Sony Mobile Communications Ab Device management using a RESTful interface
TW201216656A (en) * 2010-10-01 2012-04-16 Interdigital Patent Holdings Method and apparatus for media session sharing and group synchronization of multi media streams
US8799378B2 (en) * 2010-12-17 2014-08-05 Microsoft Corporation Non-greedy consumption by execution blocks in dataflow networks
JP2014510480A (en) * 2011-02-28 2014-04-24 インタラクティブ・ソーシャル・インターネットワークス・エルエルシー Network communication system and method
US8850516B1 (en) 2011-06-22 2014-09-30 Emc Corporation Virtual private cloud that provides enterprise grade functionality and compliance
US9213718B1 (en) 2011-06-22 2015-12-15 Emc Corporation Synchronized file management across multiple disparate endpoints
US9537891B1 (en) 2011-09-27 2017-01-03 Palo Alto Networks, Inc. Policy enforcement based on dynamically attribute-based matched network objects
US8930529B1 (en) * 2011-09-27 2015-01-06 Palo Alto Networks, Inc. Policy enforcement with dynamic address object
US9047109B1 (en) 2012-06-20 2015-06-02 Palo Alto Networks, Inc. Policy enforcement in virtualized environment
US20130097116A1 (en) * 2011-10-17 2013-04-18 Research In Motion Limited Synchronization method and associated apparatus
JP5910171B2 (en) * 2012-03-01 2016-04-27 日本電気株式会社 Synchronization target data processing device, data synchronization system, synchronization target data processing method, and computer program
US10452084B2 (en) * 2012-03-14 2019-10-22 Ademco Inc. Operation of building control via remote device
US10210480B2 (en) 2012-05-31 2019-02-19 Apple Inc. Avoiding a redundant display of a notification on multiple user devices
US20130339160A1 (en) * 2012-05-31 2013-12-19 AppNexus Inc. Application marketplace for online advertising applications
US20140089619A1 (en) * 2012-09-27 2014-03-27 Infinera Corporation Object replication framework for a distributed computing environment
CN102932439A (en) * 2012-10-26 2013-02-13 华为终端有限公司 Method and device for synchronizing content
US9268833B2 (en) 2012-12-05 2016-02-23 Microsoft Technology Licensing, Llc Recurring calendar item master and instance synchronization
CN103916409B (en) * 2012-12-30 2017-11-21 中国移动通信集团公司 A kind of method of data syn-chronization, terminal and system
US9712508B2 (en) * 2013-03-13 2017-07-18 Intel Corporation One-touch device personalization
BR102013017941B1 (en) * 2013-07-12 2022-06-28 Samsung Eletrônica Da Amazônia Ltda SYSTEM AND METHOD TO ACTIVATE AND CONTROL THE EXECUTION OF MANAGEMENT POLICIES
WO2015035396A1 (en) * 2013-09-09 2015-03-12 Layer, Inc. Federated authentication of client computers in networked data communications services callable by applications
US10303658B2 (en) * 2013-11-25 2019-05-28 Dropbox, Inc. Generating and sharing metadata for indexing synchronized content items
US10275765B2 (en) * 2013-12-11 2019-04-30 Ebay Inc. Omni-channel state preservation
US10795910B2 (en) * 2013-12-31 2020-10-06 Sybase, Inc. Robust communication system for guaranteed message sequencing with the detection of duplicate senders
US10831731B2 (en) * 2014-03-12 2020-11-10 Dell Products L.P. Method for storing and accessing data into an indexed key/value pair for offline access
JP6611594B2 (en) * 2015-03-16 2019-11-27 キヤノン株式会社 Information processing apparatus for synchronizing data, data synchronization method, and program
EP3070619B1 (en) 2015-03-16 2023-08-16 Canon Kabushiki Kaisha Information processing apparatuses performing synchronization of data and data synchronization methods
CN105025568A (en) * 2015-06-16 2015-11-04 山东大学(威海) Large-scaled wireless sensor network synchronizer based on frequency offset bidding and dynamic topology
US10805078B2 (en) * 2015-09-03 2020-10-13 Signify Holding B.V. Network node
US10425477B2 (en) * 2015-09-15 2019-09-24 Microsoft Technology Licensing, Llc Synchronizing file data between computer systems
US10417254B2 (en) * 2016-02-01 2019-09-17 Vmware, Inc. Intelligent content synchronization between content libraries
CN106131085B (en) * 2016-08-31 2019-09-17 江苏蓝创智能科技股份有限公司 The communication means of remote intelligent control system
US10802853B2 (en) * 2016-10-14 2020-10-13 Seagate Technology Llc Active drive
CN106547485B (en) * 2016-10-20 2020-09-08 Oppo广东移动通信有限公司 Data migration method and device
CN111295597A (en) * 2017-08-31 2020-06-16 阿维瓦软件有限公司 Data array of object index
WO2021221637A1 (en) * 2020-04-30 2021-11-04 Hewlett-Packard Development Company, L.P. Stored client state
CN112084153A (en) * 2020-09-09 2020-12-15 南京烽火星空通信发展有限公司 Method and system for fuzzily and rapidly transforming node data of plist file according to view angle

Family Cites Families (54)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6173335B1 (en) 1993-07-30 2001-01-09 Apple Computer, Inc. Structure and protocol for routing information in a system
JPH07325771A (en) * 1994-05-31 1995-12-12 Ricoh Co Ltd File transfer device
US5684984A (en) 1994-09-29 1997-11-04 Apple Computer, Inc. Synchronization and replication of object databases
US5706509A (en) 1995-04-28 1998-01-06 Intel Corporation Application independent record level synchronization
US5728335A (en) 1996-06-26 1998-03-17 Union Carbide Chemicals & Plastics Technology Corporation Process for extrusion
US5884325A (en) 1996-10-09 1999-03-16 Oracle Corporation System for synchronizing shared data between computers
US6182141B1 (en) * 1996-12-20 2001-01-30 Intel Corporation Transparent proxy server
US6253228B1 (en) 1997-03-31 2001-06-26 Apple Computer, Inc. Method and apparatus for updating and synchronizing information between a client and a server
US5987376A (en) 1997-07-16 1999-11-16 Microsoft Corporation System and method for the distribution and synchronization of data and state information between clients in a distributed processing system
US6341291B1 (en) 1998-09-28 2002-01-22 Bentley Systems, Inc. System for collaborative engineering using component and file-oriented tools
US6477543B1 (en) 1998-10-23 2002-11-05 International Business Machines Corporation Method, apparatus and program storage device for a client and adaptive synchronization and transformation server
US6247135B1 (en) 1999-03-03 2001-06-12 Starfish Software, Inc. Synchronization process negotiation for computing devices
US6430576B1 (en) 1999-05-10 2002-08-06 Patrick Gates Distributing and synchronizing objects
US6823456B1 (en) 1999-08-25 2004-11-23 International Business Machines Corporation System and method for providing trusted services via trusted server agents
US6694336B1 (en) 2000-01-25 2004-02-17 Fusionone, Inc. Data transfer and synchronization system
US8156074B1 (en) * 2000-01-26 2012-04-10 Synchronoss Technologies, Inc. Data transfer and synchronization system
US20050055382A1 (en) 2000-06-28 2005-03-10 Lounas Ferrat Universal synchronization
JP2002149464A (en) * 2000-08-17 2002-05-24 Fusionone Inc Base rolling engine for data transfer and synchronization system
US20020026474A1 (en) 2000-08-28 2002-02-28 Wang Lawrence C. Thin client for wireless device using java interface
WO2002075539A2 (en) 2001-03-16 2002-09-26 Novell, Inc. Client-server model for synchronization of files
US7177866B2 (en) 2001-03-16 2007-02-13 Gravic, Inc. Asynchronous coordinated commit replication and dual write with replication transmission and locking of target database on updates only
US6829655B1 (en) * 2001-03-28 2004-12-07 Siebel Systems, Inc. Method and system for server synchronization with a computing device via a companion device
US6970876B2 (en) 2001-05-08 2005-11-29 Solid Information Technology Method and arrangement for the management of database schemas
US7149813B2 (en) 2001-08-14 2006-12-12 Microsoft Corporation Method and system for synchronizing mobile devices
US7761535B2 (en) 2001-09-28 2010-07-20 Siebel Systems, Inc. Method and system for server synchronization with a computing device
US20040064480A1 (en) * 2002-07-19 2004-04-01 Bartlett Troy L. System and method for utilizing profile information
US6983293B2 (en) * 2002-07-24 2006-01-03 International Business Machines Corporation Mid-tier-based conflict resolution method and system usable for message synchronization and replication
KR100728076B1 (en) * 2002-09-03 2007-06-13 노키아 코포레이션 Method, device and system for synchronizing of data providing for the handling of an interrupted synchronization process
US7359991B2 (en) 2002-11-05 2008-04-15 Microsoft Corporation Folder synchronization
US20060259524A1 (en) 2003-03-17 2006-11-16 Horton D T Systems and methods for document project management, conversion, and filing
KR100491541B1 (en) * 2003-08-01 2005-05-25 니트젠테크놀러지스 주식회사 A contents synchronization system in network environment and a method therefor
US20050033811A1 (en) * 2003-08-07 2005-02-10 International Business Machines Corporation Collaborative email
FI20031258A0 (en) * 2003-09-04 2003-09-04 Nokia Corp Location privacy in the communication system
US7080104B2 (en) 2003-11-07 2006-07-18 Plaxo, Inc. Synchronization and merge engines
US7676562B2 (en) * 2004-01-20 2010-03-09 Microsoft Corporation Computer system for accessing instrumentation information
KR100547896B1 (en) 2004-03-05 2006-01-31 삼성전자주식회사 Data Synchronization System and Data Synchronization Method of Server and Client
AU2005248741B2 (en) 2004-05-24 2011-03-24 Apple Inc. Methods for sharing groups of objects, synchronising, and synchronising between three or more devices
EP1812848A4 (en) 2004-09-15 2009-04-29 Adesso Systems Inc System and method for managing data in a distributed computer system
CN1753359B (en) * 2004-09-24 2011-01-19 华为技术有限公司 Method of implementing SyncML synchronous data transmission
US8069226B2 (en) * 2004-09-30 2011-11-29 Citrix Systems, Inc. System and method for data synchronization over a network using a presentation level protocol
US20060074996A1 (en) * 2004-10-05 2006-04-06 International Business Machines Corporation System and method for synchronizing data
JP4568576B2 (en) * 2004-10-26 2010-10-27 株式会社デンソーアイティーラボラトリ Data sharing system, communication terminal, and data sharing method
US8230326B2 (en) 2004-12-17 2012-07-24 International Business Machines Corporation Method for associating annotations with document families
US7908247B2 (en) 2004-12-21 2011-03-15 Nextpage, Inc. Storage-and transport-independent collaborative document-management system
US9020887B2 (en) 2004-12-21 2015-04-28 Proofpoint, Inc. Managing the status of documents in a distributed storage system
CN100531265C (en) * 2004-12-21 2009-08-19 华为技术有限公司 Method for displaying information of calling party on terminal of called user
NO20052719D0 (en) 2005-06-06 2005-06-06 Ericsson Telefon Ab L M Synchronization of information units with associated references
US7600030B2 (en) * 2005-08-31 2009-10-06 Microsoft Corporation Compounding of HTTP authoring protocol
CN101005428A (en) * 2006-01-19 2007-07-25 华为技术有限公司 Realizing method for detecting and resolving data synchronous conflict
CN101047707A (en) * 2006-03-30 2007-10-03 华为技术有限公司 Method and system for initiating equipment ability information consultation
US7756829B2 (en) 2006-04-18 2010-07-13 Sandeep Bhanote Method and apparatus for mobile data collection and management
US8108388B2 (en) 2006-04-26 2012-01-31 Microsoft Corporation Significant change search alerts
US20080155112A1 (en) 2006-12-22 2008-06-26 Nokia Corporation System and method for updating information feeds
US7747784B2 (en) * 2008-03-04 2010-06-29 Apple Inc. Data synchronization protocol

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
APPLE: "Sync Services Framework Reference", COCOA > SYNCING, 31 October 2007 (2007-10-31), XP002532279, Retrieved from the Internet <URL:http://developer.apple.com/documentation/Cocoa/Reference/SyncServicesRef_ObjC/SyncServicesRef_ObjC.pdf> [retrieved on 20090615] *
APPLE: "Sync Services Programming Guide", COCOA > SYNCING, 31 October 2007 (2007-10-31), Cupertino, CA95014, XP002532278, Retrieved from the Internet <URL:http://developer.apple.com/documentation/Cocoa/Conceptual/SyncServices/SyncServices.pdf> [retrieved on 20090615] *

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2011118771A (en) * 2009-12-04 2011-06-16 Sony Corp Information processor, information processing method, data management server, and data synchronization system
CN101923571A (en) * 2010-07-29 2010-12-22 中兴通讯股份有限公司 Method and device for managing terminal data logging

Also Published As

Publication number Publication date
KR101167833B1 (en) 2012-07-27
CA2833511C (en) 2016-11-15
JP5753596B2 (en) 2015-07-22
JP5280462B2 (en) 2013-09-04
US20090228606A1 (en) 2009-09-10
EP2439660A2 (en) 2012-04-11
JP2011514602A (en) 2011-05-06
KR20110125681A (en) 2011-11-21
KR20120030594A (en) 2012-03-28
CN103259864A (en) 2013-08-21
JP5475909B2 (en) 2014-04-16
GB2471227A (en) 2010-12-22
CN102016846B (en) 2013-06-26
CA2717535C (en) 2014-05-06
JP2014078284A (en) 2014-05-01
EP2098963A1 (en) 2009-09-09
KR101343202B1 (en) 2013-12-20
CN103259864B (en) 2016-09-07
US20100223400A1 (en) 2010-09-02
CA2717535A1 (en) 2009-09-11
US8224918B2 (en) 2012-07-17
US8046498B2 (en) 2011-10-25
AU2009221998B2 (en) 2012-01-12
JP2013178819A (en) 2013-09-09
CN103327073A (en) 2013-09-25
JP5753597B2 (en) 2015-07-22
CA2833511A1 (en) 2009-09-11
CN102016846A (en) 2011-04-13
JP2014102852A (en) 2014-06-05
US20120036212A1 (en) 2012-02-09
JP2013211037A (en) 2013-10-10
GB201016416D0 (en) 2010-11-10
KR101186042B1 (en) 2012-09-27
US7747784B2 (en) 2010-06-29
KR20100123897A (en) 2010-11-25
CN103327073B (en) 2016-09-07
JP5475908B2 (en) 2014-04-16
AU2009221998A1 (en) 2009-09-11
WO2009111492A4 (en) 2009-11-05
EP2439660A3 (en) 2012-11-07

Similar Documents

Publication Publication Date Title
US7747784B2 (en) Data synchronization protocol
KR101217389B1 (en) Synchronization server process
EP2180663A1 (en) Trickle sync protocol
CN102594874B (en) Synchronization processing method and device
AU2015201041B2 (en) Data synchronization protocol
AU2012201747B2 (en) Data synchronization protocol

Legal Events

Date Code Title Description
WWE Wipo information: entry into national phase

Ref document number: 200980116069.8

Country of ref document: CN

121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 09716513

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 2717535

Country of ref document: CA

WWE Wipo information: entry into national phase

Ref document number: 2010549823

Country of ref document: JP

NENP Non-entry into the national phase

Ref country code: DE

ENP Entry into the national phase

Ref document number: 1016416

Country of ref document: GB

Kind code of ref document: A

Free format text: PCT FILING DATE = 20090303

WWE Wipo information: entry into national phase

Ref document number: 1016416.8

Country of ref document: GB

WWE Wipo information: entry into national phase

Ref document number: 2009221998

Country of ref document: AU

Ref document number: 6261/CHENP/2010

Country of ref document: IN

ENP Entry into the national phase

Ref document number: 20107022191

Country of ref document: KR

Kind code of ref document: A

ENP Entry into the national phase

Ref document number: 2009221998

Country of ref document: AU

Date of ref document: 20090303

Kind code of ref document: A

122 Ep: pct application non-entry in european phase

Ref document number: 09716513

Country of ref document: EP

Kind code of ref document: A1