Source: http://www.google.com/patents/US8224918?dq=6011510
Timestamp: 2017-04-23 14:12:20
Document Index: 637502956

Matched Legal Cases: ['Application No. 08161817', 'Application No. 08161817', 'Application No. 09154256', 'Application No. 08161817', 'Application No. 09154249', 'Application No. 09171413']

Patent US8224918 - Data synchronization protocol - Google PatentsSearch Images Maps Play YouTube News Gmail Drive More »Sign inPatentsAmong 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...http://www.google.com/patents/US8224918?utm_source=gb-gplus-sharePatent US8224918 - Data synchronization protocolAdvanced Patent SearchTry the new Google Patents, with machine-classified Google Scholar results, and Japanese and South Korean patents.Publication numberUS8224918 B2Publication typeGrantApplication numberUS 13/276,861Publication dateJul 17, 2012Filing dateOct 19, 2011Priority dateMar 4, 2008Fee statusPaidAlso published asCA2717535A1, CA2717535C, CA2833511A1, CA2833511C, CN102016846A, CN102016846B, CN103259864A, CN103259864B, CN103327073A, CN103327073B, EP2098963A1, EP2439660A2, EP2439660A3, US7747784, US8046498, US20090228606, US20100223400, US20120036212, WO2009111492A1, WO2009111492A4Publication number13276861, 276861, US 8224918 B2, US 8224918B2, US-B2-8224918, US8224918 B2, US8224918B2InventorsBrendan A. McCarthy, Carsten GuentherOriginal AssigneeApple Inc.Export CitationBiBTeX, EndNote, RefManPatent Citations (44), Non-Patent Citations (21), Referenced by (6), Classifications (15), Legal Events (2) External Links: USPTO, USPTO Assignment, EspacenetData synchronization protocol
US 8224918 B2Abstract
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 exchange 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.
a non-transitory computer storage medium encoding instructions that when executed by the one or more hardware processors cause the computer server system to perform operations comprising:
receiving a single message requesting to sync data associated with multiple dataclasses with at least one client device, wherein the message includes a proposed sync mode for each of the multiple dataclasses,
negotiating the proposed sync mode for each of the multiple dataclasses in parallel responsive to receiving the message, and
sending a reply message that includes one or more status codes indicative of whether the proposed sync mode for each dataclass has been accepted by the computer server system.
2. The computer server system of claim 1, where the operations further comprise using, based on the one or more status codes, an accepted sync mode negotiated for each dataclass to selectively update the data associated with the multiple dataclasses.
3. The computer server system of claim 2, where the accepted sync mode uses field level differencing.
4. The computer server system of claim 2, where the accepted sync mode uses record level differencing.
5. The computer server system of claim 1, where the operations further comprise:
rejecting the proposed sync mode for at least one of the multiple dataclasses, and
6. The computer server system of claim 1, where the single message requesting to sync data is represented as a binary property list file (plist).
7. The computer server system of claim 1, where the reply message is represented as a plist.
8. A non-transitory computer storage medium storing instructions that when executed by a processor of a server system causes the server system to perform operations comprising:
initiating, by the server system, a sync session to sync data associated with multiple dataclasses with at least one client device responsive to a first message from the at least one client device, wherein the message includes a proposed sync mode for each of the multiple dataclasses; and
sending, from the server system, a second message to the at least one client device to complete the sync session, the second message comprising a status code to indicate acceptance or rejection of each proposed sync mode.
9. The non-transitory computer storage medium of claim 8, where the operations further comprise syncing, based on the status code, the data using an accepted proposed sync mode or a replacement sync mode for each dataclass.
10. The non-transitory computer storage medium of claim 8, where the operations further comprise negotiating, at the server system, the proposed sync mode for each of the multiple dataclasses in parallel responsive to receiving the first message.
a non-transitory computer storage medium encoding instructions that when executed by the one or more hardware processors cause the server system to perform operations comprising:
initiating a sync session to sync data associated with multiple dataclasses with at least one client device responsive to a message from the at least one client device, wherein the message includes a proposed sync mode for each of the multiple dataclasses;
negotiating the proposed sync mode for each of the multiple dataclasses in parallel responsive to receiving the first message;
generating a status code indicating whether the proposed sync mode for each of the multiple dataclasses is accepted or rejected;
detecting an interruption in a network connection between the server and the at least one client device that interrupts the sync session; and
12. The server system of claim 11, where the operations further comprise sending a reply message to the at least one client device, the reply message including the generated status code.
13. The server system of claim 11, where the message from the at least one client device comprises a header and a body, and the body comprises a sequence of command elements.
14. The server system of claim 13, where the reply message comprises a header and a body, and the body comprises a sequence of command response elements.
15. The server system of claim 14, where the operations further comprise assigning a unique label to each of the message, the reply message, command elements and command response elements to ensure proper ordering and loss detection.
16. The server system of claim 13, where the operations further comprise setting a flag in the header of the message or the reply message, and the flag indicates that the sync session is complete.
17. The server system of claim 13, where the head of the message or the reply message or both comprises a version number.
18. The server system of claim 11, where the operations further comprise assigning an anchor that keeps track of a state of the sync session.
19. The server system of claim 18, where said resuming the sync session comprises using the assigned anchor to identify the state of the sync session before the interruption.
20. The server system of claim 11, where the operations further comprise:
identifying a conflict associated with the data to be synced, and
resolving the identified conflict.
This application is a continuation and claims the benefit of priority under 35 USC 120 of U.S. application Ser. No. 12/779,754 filed May 13, 2010, which is a continuation of U.S. Pat. No. 7,747,784 issued Jun. 29, 2010, the entire contents of which are hereby incorporated by reference.
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 receive 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 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.
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 “relationships”. Relationships between entities in discrete dataclasses are 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 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 status 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).
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_anchor”). The “device_version” parameter for the anchor element describes the version of the client device 110. 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 110 to the server process 120 as well as from the server process 120 to the client device 110.
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.
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.
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 its 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.
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 is implemented as a String. When not present, the recipient for each of these keys is implemented as a String. When not present, the recipient infers the last known value for the keys.
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 is reduced. The reduced number of roundtrips can reduce or minimize message/packet loss.
In some implementations, the client device 110 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) are sent to the server 120 in the subsequent 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 changes requested from the client device 110 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 110. 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.
FIG. 32 shows a table of example key-value pairs for the “uri” parameter. The available keys 3210 for the “uri” parameter include 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 110, 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
FIGS. 40 a and 40 b 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.
Patent CitationsCited PatentFiling datePublication dateApplicantTitleUS5684984Sep 29, 1994Nov 4, 1997Apple Computer, Inc.Synchronization and replication of object databasesUS5706509Apr 28, 1995Jan 6, 1998Intel CorporationApplication independent record level synchronizationUS5728335Jun 26, 1996Mar 17, 1998Union Carbide Chemicals & Plastics Technology CorporationProcess for extrusionUS5884325Oct 9, 1996Mar 16, 1999Oracle CorporationSystem for synchronizing shared data between computersUS5987376Jul 16, 1997Nov 16, 1999Microsoft CorporationSystem and method for the distribution and synchronization of data and state information between clients in a distributed processing systemUS6173335Jul 30, 1993Jan 9, 2001Apple Computer, Inc.Structure and protocol for routing information in a systemUS6182141Dec 20, 1996Jan 30, 2001Intel CorporationTransparent proxy serverUS6247135Apr 6, 1999Jun 12, 2001Starfish Software, Inc.Synchronization process negotiation for computing devicesUS6253228Mar 31, 1997Jun 26, 2001Apple Computer, Inc.Method and apparatus for updating and synchronizing information between a client and a serverUS6341291Apr 22, 1999Jan 22, 2002Bentley Systems, Inc.System for collaborative engineering using component and file-oriented toolsUS6430576May 10, 1999Aug 6, 2002Patrick GatesDistributing and synchronizing objectsUS6823456Aug 25, 1999Nov 23, 2004International Business Machines CorporationSystem and method for providing trusted services via trusted server agentsUS6829655Apr 9, 2002Dec 7, 2004Siebel Systems, Inc.Method and system for server synchronization with a computing device via a companion deviceUS6910052May 16, 2002Jun 21, 2005Apple Computer, Inc.Distributing and synchronizing objectsUS6970876May 8, 2001Nov 29, 2005Solid Information TechnologyMethod and arrangement for the management of database schemasUS7149813Aug 14, 2001Dec 12, 2006Microsoft CorporationMethod and system for synchronizing mobile devicesUS7747784 *Mar 4, 2008Jun 29, 2010Apple Inc.Data synchronization protocolUS8046498 *May 13, 2010Oct 25, 2011Apple Inc.Data synchronization protocolUS20020026474Aug 28, 2001Feb 28, 2002Wang Lawrence C.Thin client for wireless device using java interfaceUS20020029227Jan 2, 2001Mar 7, 2002Multer David L.Management server for synchronization systemUS20040019614Jul 24, 2002Jan 29, 2004International Business Machines CorporationMid-tier-based conflict resolution method and system usable for message synchronization and replicationUS20040103174Aug 26, 2003May 27, 2004Balducci Juan V. EsteveFolder synchronizationUS20040133591Sep 17, 2003Jul 8, 2004Iti, Inc.Asynchronous coordinated commit replication and dual write with replication transmission and locking of target database on updates onlyUS20050055382Jun 21, 2001Mar 10, 2005Lounas FerratUniversal synchronizationUS20050102328Nov 7, 2003May 12, 2005Ring Cameron T.Synchronization and merge enginesUS20050198084Aug 26, 2004Sep 8, 2005Samsung Electronics Co., Ltd.System and method of synchronizing data between a server and a clientUS20060075105Sep 30, 2004Apr 6, 2006Gueorgui MomtchilovSystem and method for data synchronization over a network using a presentation level protocolUS20060112150Jan 5, 2006May 25, 2006Brown David KServer for synchronization of filesUS20060136511Dec 21, 2004Jun 22, 2006Nextpage, Inc.Storage-and transport-independent collaborative document-management systemUS20060136513Feb 8, 2005Jun 22, 2006Nextpage, Inc.Managing the status of documents in a distributed storage systemUS20060150079Dec 17, 2004Jul 6, 2006International Business Machines CorporationMethod for associating annotations with document familiesUS20060242210Jun 30, 2006Oct 26, 2006Plaxo, Inc.Contact management update protocolsUS20060259524Jul 14, 2006Nov 16, 2006Horton D TSystems and methods for document project management, conversion, and filingUS20070100834Sep 15, 2005May 3, 2007John LandrySystem and method for managing data in a distributed computer systemUS20070162518Dec 14, 2006Jul 12, 2007Huawei Technologies Co., Ltd.Method for Transmitting SyncML Synchronization DataUS20070226272May 24, 2007Sep 27, 2007Huang Xiao FMethod And System For Server Synchronization With A Computing DeviceUS20070255744Apr 26, 2006Nov 1, 2007Microsoft CorporationSignificant change search alertsUS20070260475Apr 17, 2007Nov 8, 2007Sandeep BhanoteMethod and apparatus for mobile data collection and managementUS20080155112Dec 22, 2006Jun 26, 2008Nokia CorporationSystem and method for updating information feedsEP1014266A2Sep 23, 1999Jun 28, 2000International Business Machines CorporationMethod, apparatus and program storage device for a client and adaptive synchronization and transformation serverEP1291770A2Aug 14, 2002Mar 12, 2003Microsoft CorporationMethod and system for sychronizing mobile devicesGB2421606A Title not availableWO2005116892A1Apr 27, 2005Dec 8, 2005Apple Computer, Inc.Methods for sharing groups of objects, synchronising, and synchronising between three or more devicesWO2006132534A1Jan 16, 2006Dec 14, 2006Telefonaktiebolaget Lm Ericsson (Publ)Synchronization of information items with references* Cited by examinerNon-Patent CitationsReference1Apple Inc., "Sync Services Framework Reference, Cocoa > Syncing," [Online] Oct. 31, 2007, XP002532279, © 2004, 2007 Apple Inc., URL:http://developer.apple.com/documentation/Cocoa/Reference/SyncServicesRef-ObjC/SyncServicesRef-ObjC.pdf, pp. 1-275.2Apple Inc., "Sync Services Framework Reference, Cocoa > Syncing," [Online] Oct. 31, 2007, XP002532279, © 2004, 2007 Apple Inc., URL:http://developer.apple.com/documentation/Cocoa/Reference/SyncServicesRef—ObjC/SyncServicesRef—ObjC.pdf, pp. 1-275.3Apple Inc., Sync Services Programming Guide, Cocoa > Syncing [Online], XP-002532278, Oct. 31, 2007, © 2004, 2007 Apple Inc., Cupertino, pp. 1-372, URL: http://developer.apple.com/documentation/Cocoa/Conceptual/SyncServices/SyncServices.pdf.4European Examination Report in EP Patent Application No. 08161817.5 dated Mar. 4, 2010.5European Search Report in Application No. 08161817.5 dated May 8, 2009.6Extended European Search Report in Application No. 09154256.3 dated Jul. 2, 2009.7Extended European Search Report in EP Patent Application No. 08161817.5 dated Aug. 3, 2009.8Extended European Search Report in EP Patent Application No. 09154249.8 dated Jun. 24, 2009.9Extended European Search Report in EP Patent Application No. 09171413.9 dated Feb. 18, 2010.10Luca Prati et al., "XDMS-Network Address Book enabler," Hewlett-Packard OpenCall Software, pp. 1-4.11Non-Final Office Action in U.S. Appl. No. 11/834,604 dated Nov. 27, 2009.12Non-Final Office Action in U.S. Appl. No. 12/042,305 dated Jun. 4, 2010.13Non-Final Office Action in U.S. Appl. No. 12/240,538 dated Jun. 18, 2010.14Non-Final Office Action in U.S. Appl. No. 12/607,921 dated Oct. 1, 2010.15Notification of Transmittal of the International Search Report and the Written Opinion of the International Searching Authority, or the Declaration in PCT/US2008/071812 dated Jul. 3, 2009.16OMA Open Mobile Alliance, "SyncML Data Sync Protocol, Candidate Version 1.2-Jun. 1, 2004," Open Mobile Alliance, OMA-SyncML-DataSyncProtocol-V1-2-200400601-C, 2004 Open Mobile Alliance Ltd., XP-002375712, pp. 1-77.17OMA Open Mobile Alliance, "SyncML Data Sync Protocol, Candidate Version 1.2—Jun. 1, 2004," Open Mobile Alliance, OMA-SyncML-DataSyncProtocol-V1—2-200400601-C, 2004 Open Mobile Alliance Ltd., XP-002375712, pp. 1-77.18PCT Invitation to Pay Additional Fees in PCT/US2008/071812 dated Apr. 28, 2009.19PCT Notification of Transmittal of the International Search Report and the Written Opinion of the International Search Authority, or the Declaration in PCT/US2009/035909 dated Jul. 14, 2009.20PCT Notification of Transmittal of the International Search Report and Written Opinion of the International Search Authority, or the Declaration in PCT/US2009/035912 dated Jun. 5, 2009.21PCT Notification of Transmittal of the International Search Report and Written Opinion of the International Search Authority, or the Declaration in PCT/US2009/058414 dated Feb. 23, 2010.Referenced byCiting PatentFiling datePublication dateApplicantTitleUS8443082 *Feb 28, 2012May 14, 2013Interactive Social Internetworks, LlcNetwork communication systems and methodsUS8930529 *Sep 27, 2011Jan 6, 2015Palo Alto Networks, Inc.Policy enforcement with dynamic address objectUS9047109Jun 20, 2012Jun 2, 2015Palo Alto Networks, Inc.Policy enforcement in virtualized environmentUS9537891Dec 20, 2013Jan 3, 2017Palo Alto Networks, Inc.Policy enforcement based on dynamically attribute-based matched network objectsUS20100287253 *Jul 20, 2010Nov 11, 2010Huawei Technologies Co., Ltd.Method, apparatus, and system for data synchronizationUS20120221726 *Feb 28, 2012Aug 30, 2012Hien Van NguyenNetwork communication systems and methods* Cited by examinerClassifications U.S. Classification709/206, 709/228, 709/248, 709/227, 370/503, 709/202, 709/223, 370/401, 709/219International ClassificationG06F15/16, G06F17/30Cooperative ClassificationH04L67/1097, G06F17/30575European ClassificationG06F17/30S7, H04L29/08N9SLegal EventsDateCodeEventDescriptionNov 27, 2012CCCertificate of correctionDec 30, 2015FPAYFee paymentYear of fee payment: 4RotateOriginal ImageGoogle Home - Sitemap - USPTO Bulk Downloads - Privacy Policy - Terms of Service - About Google Patents - Send FeedbackData provided by IFI CLAIMS Patent Services