(19) United States
`(12) Patent Application Publication (η» Pub. No.: US 2012/0310882 Al
`Dec. 6,2012
`Werner et al.
`(43) Pub. Date:
`
`US 20120310882A1
`
`(54) KEY VALUE DATA STORAGE
`
`Publication Classification
`
`(75) Inventors:
`
`Jeremy M. Werner, Burlingame,
`CA (US); Julien Jacques Jalon,
`San Francisco, CA (US); Naveen
`Nalam, San Carlos, CA (US); Toby
`Charles Wood Paterson, San
`Francisco, CA (US)
`
`(73) Assignee:
`
`Apple Inc., Cupertino, CA (US)
`
`(21)
`
`Appl.No
`.:
`
`13/486,516
`
`(22) Filed:
`
`Jun. 1, 2012
`
`Related U.S. Application Data
`(60) Provisional application No. 61/493,333, filed on Jun.
`3,2011.
`
`(51) Int.Cl.
`(2006.01)
`G06F 7/00
`G06F 17/30
`(2006.01)
`(52) U.S. Cl. .. 707/624; 707/691; 707/610; 707/E17.005;
`707/E17.032
`
`(57)
`ABSTRACT
`Methods, systems, and apparatus, including computer pro­
`grams encoded on a computer storage medium, for data syn­
`chronization. In general, one aspect of the subject matter
`described in this specification can be embodied in methods
`that include the actions of receiving a key-value pair from a
`first device, the key-value pair including a value correspond­
`ing to particular application data of the first device; notifying
`one or more other devices associated with the first device of
`the key value pair; receiving a request from a second device
`for the key-value pair; and sending the key-value pair to the
`second device.
`
`APPLE 1007
`
`1
`
`

`

`Patent Application Publication
`
`Dec. 6, 2012 Sheet 1 of 6
`
`US 2012/0310882 Al
`
`FIG. 1
`
`KV Storage
`
`2
`
`

`

`Patent Application Publication Dec. 6, 2012 Sheet 2 of 6
`
`US 2012/0310882 Al
`
`200
`
`FIG. 2
`
`3
`
`

`

`Patent Application Publication Dec. 6, 2012 Sheet 3 of 6
`
`US 2012/0310882 Al
`
`300
`
`FIG. 3
`
`4
`
`

`

`Patent Application Publication Dec. 6, 2012 Sheet 4 of 6
`
`US 2012/0310882 Al
`
`400'
`
`FIG. 4
`
`5
`
`

`

`Patent Application Publication Dec. 6, 2012 Sheet 5 of 6
`
`US 2012/0310882 Al
`
`500'
`
`FIG. 5
`
`6
`
`

`

`Patent Application Publication Dec. 6, 2012 Sheet 6 of 6
`
`US 2012/0310882 Al
`
`FIG. 6
`
`600
`
`7
`
`

`

`US 2012/0310882 Al
`
`Dec. 6, 2012
`
`1
`
`KEY VALUE DATA STORAGE
`
`CROSS-REFERENCE TO RELATED
`APPLICATIONS
`[0001] This application claims the benefit under 35 U.S.C.
`§119(e) of the filing date of U.S. Patent Application No.
`61/493,333, for Key Value Data Storage, which was filed on
`Jun. 3, 2011, and which is incorporated here by reference.
`
`BACKGROUND
`[0002] This specification relates to data storage.
`[0003] Users can store data in a remote location, e.g., a
`network storage location, and retrieve the stored data at a later
`time. Users can also transfer data between devices. Typically,
`users share data with others through file transfer or sharing.
`For example, a user can identify a particular file to send to
`others, e.g., by e-mail or using a file transfer protocol. File
`sharing allows other users, e.g., on a network, to access files,
`however the files typically remain at their original location.
`Alternatively, files can be checked out from their original
`storage location by others, but typically the only user that can
`modify the file is the one that checked the file out.
`[0004] Conventional systems also allow for users to syn­
`chronize data between the user’s devices (e.g., a laptop com­
`puter and a mobile device). Often, only particular types of
`data are synchronized between devices or the synchroniza­
`tion has to be initiated by the user.
`
`SUMMARY
`[0005] This specification describes technologies relating to
`key value data storage.
`[0006] In general, one aspect of the subject matter
`described in this specification can be embodied in methods
`that include the actions of receiving a key-value pair from a
`first device, the key-value pair including a value correspond­
`ing to particular application data of the first device; notifying
`one or more other devices associated with the first device of
`the key value pair; receiving a request from a second device
`for the key-value pair; and sending the key-value pair to the
`second device.
`[0007] Other embodiments of this aspect include corre­
`sponding systems, apparatus, and computer programs
`recorded on computer storage devices, each configured to
`perform the operations of the methods.
`[0008] These and other embodiments can each optionally
`include one or more of the following features. The method
`further includes storing the received key-value pair. Prior to
`notifying the one or more other devices, determining whether
`the received key-value pair raises a conflict with one or more
`other stored key-value pairs. If a conflict is determined, send­
`ing a conflict notification to the first device along with data
`associated with one or more conflicting key value pairs. The
`method further includes receiving a conflict resolution from
`the first device.
`[0009] In general, one aspect of the subject matter
`described in this specification can be embodied in methods
`that include the actions of receiving a first key-value pair from
`a running application, the first key-value pair including a
`value corresponding to particular application data; sending
`the first key-value pair to a remote location for storage accord­
`ing to a specified schedule; receiving a second key-value pair
`from the remote location for the application; and providing
`the second key-value pair to the application. Other embodi­
`
`ments of this aspect include corresponding systems, appara­
`tus, and computer programs recorded on computer storage
`devices, each configured to perform the operations of the
`methods.
`[0010] These and other embodiments can each optionally
`include one or more of the following features. Providing the
`new key-value pair to the application includes storing the new
`key-value pair if the application is not currently running
`[0011] In general, one aspect of the subject matter
`described in this specification can be embodied in methods
`that include the actions of sending a key-value pair for an
`application to a remote location for storage; receiving notifi­
`cation of a conflict with another stored key-value pair includ­
`ing receiving information about the conflicting key-value
`pair; resolving the conflict; and notifying the remote location
`of a conflict winner. Other embodiments of this aspect include
`corresponding systems, apparatus, and computer programs
`recorded on computer storage devices, each configured to
`perform the operations of the methods.
`[0012] These and other embodiments can each optionally
`include one or more of the following features. Resolving the
`conflict includes: determining that the key-value pairs do not
`represent an initial synchronization between devices; com­
`paring timestamps for each key-value pair, the timestamp
`indicating the time the key-value pair was generated on a
`respective device; and selecting the key-value pair having the
`latest timestamp as the conflict winner. Resolving the conflict
`includes: determining that one of the key-value pairs repre­
`sent an initial synchronization between devices; and selecting
`the key-value pair that is not identified as associated with an
`initial synchronization as the conflict winner.
`[0013] In general, one aspect of the subject matter
`described in this specification can be embodied in apparatus
`including a computing device configured to provide: one or
`more applications; a key-value daemon for managing appli­
`cation key-value pairs including providing key-value pairs to
`a remote storage location, receiving key-value pairs from
`other devices for synchronization, and performing conflict
`resolution between key-value pairs; and a key-value cache for
`storing key-value pairs to be sent to remote storage or
`received from remote storage. Other embodiments of this
`aspect include corresponding systems, method, and computer
`programs recorded on computer storage devices.
`[0014] Particular embodiments of the subject matter
`described in this specification can be implemented so as to
`realize one or more of the following advantages. Small pieces
`of data can be stored and synched with other devices as
`key-value pairs instead of separate files. Application specific
`key-value pairs can be securely stored and synchronized.
`Conflict resolution logic depends on whether the key-value
`pair is associated with an initial synchronization. Initial
`device synchronizations are processed to preserve applica­
`tion data on other devices.
`[0015] The details of one or more embodiments of the
`subject matter described in this specification are set forth in
`the accompanying drawings and the description below. Other
`features, aspects, and advantages of the subject matter will
`become apparent from the description, the drawings, and the
`claims.
`
`BRIEF DESCRIPTION OF THE DRAWINGS
`
`[0016] FIG. 1 is a diagram illustrating an example system
`for storing and synchronizing key value pairs.
`
`8
`
`

`

`US 2012/0310882 Al
`
`Dec. 6, 2012
`
`2
`
`[0017] FIG. 2 is a flow chart of an example process for
`synchronizing key-value pairs.
`[0018] FIG. 3 is a flow chart of an example client process
`for storing and receiving updated key-value pairs.
`[0019] FIG. 4 is a flow chart of an example process for
`conflict notification.
`[0020] FIG. 5 is a flow chart of an example process for
`client side conflict resolution.
`[0021] FIG. 6 is an example system architecture.
`[0022] Like reference numbers and designations in the
`various drawings indicate like elements.
`
`DETAILED DESCRIPTION
`[0023] Key-value pairs including particular application
`data as values can be stored and synchronized between
`devices (e.g., devices associated with a particular user or
`account). For example, the key-value pairs for an application
`can be stored externally to any user devices, e.g., a cloud or
`network storage. Additionally, the key-value pairs can be
`synchronized across one or more other user devices such that
`the key-value data can be incorporated into corresponding
`applications on multiple user devices. A user can have mul­
`tiple devices having the same application, for example, a
`mobile device and a tablet device. When a user makes a
`change to the application instance on one device (e.g., modi­
`fying a setting), the same change can be synchronized to the
`application instance on the tablet device.
`[0024] The external storage can identify conflicts between
`key-value pairs pushed to the external storage from different
`devices. Once notified of a conflict, a particular user device
`can resolve the conflict according to one or more conflict
`resolution processes to identify a winning key-value pair.
`[0025] FIG. 1 is a diagram illustrating an example system
`100 for storing and synchronizing key value pairs. The system
`100 includes a first device 102, a second device 104, and a
`remote storage location 106.
`[0026] The first device 102, second device 104, and remote
`storage location 106 are coupled together using one or more
`networks 108. Each of the first device 102 and the second
`device 104 can include, for example, one or more computing
`devices including desktop or laptop computing devices,
`mobile devices, tablet devices, personal data assistants, or
`other computing devices. In particular, each of the devices
`102 and 104, for illustration, can be associated with a particu­
`lar user or user account 101. However, the remote storage
`location 106 can be coupled to many other devices, not
`shown, that are associated with one or more different users or
`different user accounts.
`[0027] The remote storage location 106 can be a single
`storage location or multiple storage locations. The remote
`storage location can include one or more computing devices
`including, for example, a server, a network addressed storage
`location, or a collection of computing devices, or as part of a
`cloud storage system presenting virtualized network storage.
`[0028] The one or more networks 108 can include both
`wired and wireless networks. A network 108 can be, for
`example, part of a local area network, wide area network, or
`the Internet.
`[0029] The first device 102 includes one or more applica­
`tions 114, a key-value daemon 110, and a key-value cache
`112. The second device 104 similarly includes one or more
`applications 120, a key-value daemon 116, and a key-value
`cache 118. The applications 114 and application 120 can
`include one or more of the same applications. The applica­
`
`tions 114 can generate new key-value pairs based on changes
`to a running application. For example, a user can modify
`particular settings or configuration information for an appli­
`cation. Alternatively, a user can save particular data associ­
`ated with the application (e.g., scores, ratings, etc.). While not
`limited to small pieces of data, the key-value pairs are typi­
`cally small pieces of data not stored as files like documents or
`other larger pieces of data.
`[0030] For example, the first device 102 can be a mobile
`device that includes as one of the applications 114 a stocks
`application. The stocks application provides stock informa­
`tion including, for example, stock price quotes, for various
`companies. A user can modify a listing of companies being
`presented. For example, the user can add a new stock to the
`listing. If the user modifies the listing, a new key-value pair
`can be generated that represents the new listing or the change
`in the listing. Other types of key-value data include listings of
`cities for a weather application, data identifying a last page
`read of an electronic book, etc.
`[0031] A key-value pair is a data structure expressed in the
`form <key, value>, where the key is an identifier and the value
`is the data being stored in the key-value pair. The key can
`identify, for example, the application and the type of data
`stored in the associated value (e.g., that it is a stocks applica­
`tion stock listing). The value encodes the actual stocks listing
`in a form interpretable by the application. The key can also
`identify a particular user or user account. Consequently, key­
`value pairs can be stored separately by application and/or by
`user or user account.
`[0032] When a new key-value pair is generated by an appli­
`cation 114, it is provided to the key-value daemon 110. The
`key-value daemon 110 can be a background application that
`operates continuously while the device is running The key­
`value daemon 110 receives key-value pairs from applications
`114 as well as from the remote storage location 106. The
`key-value daemon 110 can include logic for as well as for
`resolving conflicts between key-value pairs from different
`devices, which will be described in greater detail below.
`[0033] The key-value cache 112 allows the key-value dae­
`mon 110 to store both notifications and received key-value
`pairs. In some implementations, the key-value cache stores
`received key-value pairs from the applications 114 for a
`period of time according to particular storage criteria. Once
`the criteria have been satisfied, a group of one or more key­
`value pairs can be sent to the remote storage location 106.
`Key-value pairs can be sent as a group or batch, for example,
`to improve performance or to reduce network traffic. The
`criteria can include, for example, a period of time or a number
`of pending key-value pairs. The key-value cache 112 can be
`used to regulate the number and frequency of transactions
`between the key-value daemon 110 and the remote storage
`location 106. In some implementations, when updated key­
`value pairs are received from an application 114, the cache
`112 can discard earlier received key-value pairs for that appli­
`cation stored in the cache 112. In some implementations, the
`cache 112 is sandboxed to protect the stored key-value data.
`The communication of key-value pairs between the applica­
`tions 114 and the key-value daemon 110 can be encrypted.
`[0034] Additionally, the key-value cache 112 can store key­
`value pairs received from the remote storage location 106. For
`example, if the corresponding application 114 is not running
`when a new key-value pair for that application is received, the
`key-value cache can store the key-value pair until the appli­
`cation is available (e.g., the application is running)
`
`9
`
`

`

`US 2012/0310882 Al
`
`Dec. 6, 2012
`
`3
`
`[0035] The key-value cache 112 can maintain a journal of
`last change for each key and the related “generation count”
`that provides an indication as to when the changes occurred as
`well as tracking which changes have already been incorpo­
`rated. When the key-value daemon 110 notifies an application
`that the contents of the key-value cache 112 has changed, the
`application receives the journal and only consider changes
`that have a generation count greater than its last known gen­
`eration count.
`[0036] The remote storage location 106 receives key-value
`pairs from devices, e.g., the first device 102 and the second
`device 104 for storage and to provide synchronization. The
`key-value pairs can be securely stored. For example, contain­
`ers for particular accounts can be generated on the remote
`storage location 106. Additionally, secure containers can fur­
`ther be generated for each application or application family
`according to specified permissions such that application spe­
`cific key-value pairs are only provided to devices associated
`with the user account and having permission to access that
`application data.
`[0037] The remote storage location 106 also provides noti­
`fications to the first device 102 and the second device 104. For
`example, when the first device 102 pushes a new key-value
`pair to the remote storage location 106, the remote storage
`location 106 can notify the second device 104 of the new
`key-value pair (e.g., if the second device 104 is associated
`with the same account and has the same application). The
`second device 104 can then request the corresponding key­
`value pair (e.g., immediately or at some later time) for incor­
`poration with the corresponding application 120 of the sec­
`ond device 104.
`[0038] For example, the notification can be sent to the key­
`value daemon 116 of the second device 104. The key-value
`daemon 116 can then request the key-value pair in response to
`the notification. The received key-value pair can be stored in
`the key-value cache 118 until provided to the corresponding
`application 120.
`[0039] Thus, using the previous stocks application
`example, a key-value pair indicating a new stock listing can
`be sent from the first device 102 to the remote storage location
`106. The remote storage location 106 both stores the key­
`value pair and sends a notification to the second device 104.
`The second device 104 can then request the key-value pair, for
`example using the key value daemon 116. They key-value
`pair can then be used to synchronize the stocks listing in the
`corresponding stocks application of the second device 104.
`[0040] In some implementations, a conflict check is run
`when a new key-value pair is received to determine whether
`there is a conflicting key-value pair that has been received.
`[0041] In some other implementations, key-value pairs are
`sent to the other devices in place of the notification. For
`example, key-value pairs can be automatically sent according
`to a particular policy or schedule. The key-value pairs can be
`sent only to those devices having permission to receive them,
`for example, belonging to the same user account, and having
`the same application. Permissions can be controlled by one or
`more policies that identify, for example, particular applica­
`tion access keys.
`[0042] FIG. 2 is a flow chart of an example process 200 for
`synchronizing key-value pairs. The process 200 can be per­
`formed by one or more computing devices, for example, by
`the remote storage location 106 of FIG. 1.
`[0043] A key-value pair is received from a device (step
`202). Upon receipt the key-value pair can be stored and pro­
`
`cessed. The processing can include determining whether the
`newly received key-value pair results in a conflict. The pro­
`cessing can also include determining whether the key-value
`pair is authorized for storage. In some implementations, stor­
`ing the key-value pair includes determining whether or not
`prior key-value pairs have been stored for the application or
`for the user account. For example, when no prior key-value
`pair has been stored, appropriate containers can be generated
`for storing application key-value pairs. When key-value pairs
`have been stored for the application, the key-value pair can be
`stored in an existing container.
`[0044] A notification is sent to other devices (step 204). In
`particular, a notification of the newly available key-value pair
`is sent to one or more devices associated with the user or user
`account. For example, these can include other user devices
`such as mobile devices, tablet devices, etc. In some imple­
`mentations, the notification includes an identification of the
`application for which the key-value pair is associated. The
`notification can indicate that a new key-value pair is available.
`These notifications can be limited to those devices having an
`application that has permission to read the key-value pairs
`(e.g., the same application). Additionally, only the applica­
`tion or applications with permission to read a particular key­
`value pair will be made aware of the new key-value pair. Thus,
`individual applications are prevented from seeing key-value
`pairs except those to which the application has permission to
`read. These permissions can be enforced, for example, by
`policies that require particular identifiers to establish access
`(e.g., each application can be assigned a particular identifier,
`for example, of the form “[developer].[application name]”
`that identifies which key-value pairs the application can read).
`[0045] In some implementations, an identifier for an appli­
`cation can vary across platforms (e.g., an application can have
`a first identifier on a laptop and a second identifier on a mobile
`phone). However, when adding an application, permissions
`can be established allowing the application to read key-value
`pairs from corresponding applications having these alterna­
`tive identifiers. One or more security policies can be used
`when adding applications to ensure that the permissions do
`not allow applications to access key-value information from
`applications that are not associated with the application.
`[0046] A request is received for the key-value pair from one
`or more of the other devices (step 206). The request can
`specify one or more key-value pairs, e.g., from one or more
`prior notifications. Alternatively, the request can be for all
`available key-value pairs. For example, a particular device
`can request a number of key-value pairs based on specific
`retrieval criteria, for example, based on network connectivity
`to the remote storage location. In some implementations, the
`key-value daemon throttles updates with the remote storage
`location to control the amount and flow of data. Additionally,
`in some implementations, the remote storage location can
`request a delay from the device. The requested key-value pair
`is sent to the one or more requesting devices (step 208).
`[0047] FIG. 3 is a flow chart of an example client process
`300 for storing and receiving updated key-value pairs. The
`process 300 can be performed by one or more computing
`devices, for example, by the first device 102 of FIG. 1.
`[0048] A first key-value pair is received from a first appli­
`cation (step 302). For example, a key-value daemon (e.g.,
`key-value daemon 110) can receive key-value pairs from one
`or more applications (e.g., applications 114) on a device
`including the first application. The first application can be, for
`example, a stocks application where the first key-value pair
`
`10
`
`

`

`US 2012/0310882 Al
`
`Dec. 6, 2012
`
`4
`
`was generated in response to a user modifying a stocks list.
`The key-value cache (e.g., key-value cache 112) maintains a
`generation count and a journal of last change for each key and
`the related generation count. Thus, the key-value daemon and
`key-value cache maintain an ordered record of changes to
`each key.
`[0049] The first key-value pair is sent for storage (step 3 04).
`The first key-value pair can, for example, be pushed to a cloud
`storage or other remote storage location (e.g., remote storage
`location 106). In some implementations, the first key-value
`pair is sent for storage according to particular criteria. The
`first key-value pair can be placed in a cache (e.g., cache 112)
`until the criteria have been satisfied. For example, the criteria
`can include a schedule in which key-value pairs stored in the
`cache are pushed to the storage location periodically, for
`example, every hour, every four hours, etc. In another
`example, the criteria can include a threshold number of key­
`value pairs stored in the cache. Thus, a group of key-value
`pairs can be pushed to the storage location once a certain
`threshold number of key-value pairs have been added to the
`cache.
`[0050] In some implementations, a combination of criteria
`is used. For example, a quantity threshold number of key­
`value pairs needed to trigger sending the key-value pairs can
`be overridden by an amount of time being reached without
`hitting the quantity threshold. For example, the criteria can be
`to send key-value pairs once 10 have been added to the cache,
`but if this threshold number is not reached within 6 hours, the
`key-value pairs are sent.
`[0051] A notification is received for a second key-value pair
`for a second application (step 306). The notification can be
`received, for example, by the key-value daemon from the
`remote storage location. The remote storage location can send
`the notification in response to receiving the second key-value
`pair from another device.
`[0052] The second application can be the same as the first
`application or a different application. For example, the sec­
`ond application can be a weather application. The second
`key-value pair can indicate a change in a listing of cities for
`which weather information is presented by the second appli­
`cation.
`[0053] In some implementations, the key-value daemon
`notifies to the application that the key-value cache has
`changed. The application receives the journal from the key­
`value cache. In particular, only changes that have a generation
`count greater than its last known generation count are con­
`sidered. The corresponding key-value pairs for these later
`changes can be requested from the key-value daemon.
`[0054] The second key-value pair is requested (step 308).
`The key-value daemon can request the key-value pair accord­
`ing to specified criteria. In some implementations, to reduce
`network traffic, the key-value pair is requested once a speci­
`fied number of notifications have been received. In some
`other implementations, to reduce latency, the request can be
`based on network connectivity of the device. For example, the
`key-value daemon can delay the request until within a Wi-Fi
`network rather than a cellular network.
`[0055] The second key-value pair is provided to the second
`application (step 310). The key-value daemon provides the
`second key-value pair to the second application. The second
`application interprets the key-value pair in order to make
`appropriate changes to the second application (e.g., modify­
`ing a listing of cities or stocks based on the value). In some
`implementations, the second key-value pair is held in a cache
`
`until the second application is running and available to
`receive the second key-value pair. In particular, when the
`application is launched, it will read the key-value cache and
`retrieve the change journal if any. Once the application has
`acknowledged the changes, it asks the key-value daemon to
`discard the journal.
`[0056] FIG. 4 is a flow chart of an example process 400 for
`conflict notification. The process 400 can be performed by
`one or more computing devices, for example, by the remote
`storage location 106 of FIG. 1.
`[0057] A key-value pair is received from a device (step
`402). The key-value pair can be received, for example, from a
`key-value daemon on the device that manages key-value pairs
`from applications on the device. In some implementations,
`there is a delay in sending the key-value pair. For example, the
`cache can hold key-value pairs until specified criteria are
`satisfied. In another example, the key-value pair can be
`received from an application while the device is not con­
`nected to the remote storage location (e.g., working offline,
`airplane mode, or because of reception or away from a net­
`work). In that scenario, the new key-value pairs cannot be sent
`to the remote storage location until a connection has been
`restored.
`[0058] A determination is made that a conflict exists with
`another received key-value pair (step 404). Conflicts can be
`detected per key. A received key-value pair at the remote
`storage location includes a sequence value or other incremen­
`tal identifier. This identifies a relative position of the particu­
`lar key-value pair to other key-value pairs for the application.
`For example, each time the application generates a new key­
`value pair the identifier is incremented.
`[0059] In some implementations, key-value pairs for an
`application are sent to the remote storage location from dif­
`ferent devices contemporaneously with each other. For
`example, a key-value pair generated when the device is online
`can be sent to the remote storage location after the user has
`made another change to the application on another device. As
`a result, the remote storage location receiving the later sent
`key-value pair determines that the identifier indicates the
`key-value pair is out of sequence. This results in a conflict
`being determined for the respective key-value pairs. In some
`implementations, the sequence numbers are provided by the
`remote storage location after each change (e.g., key-value
`pair) is received.
`[0060] A notification is sent to the device (step 406). The
`notification to the device indicates that the key-value pair sent
`to the remote storage location is out of sequence from another
`key-value pair received for the application. In some imple­
`mentations, the remote storage location does not send any
`other notifications for the key-value pair to other devices until
`the conflict is resolved.
`[0061] A conflict resolution is received from the device
`(step 408). The conflict resolution can identify a winning
`key-value pair that is to be synchronized across other devices.
`Notification is sent to other devices based on the conflict
`resolution (step 410). The notification of the winning key­
`value pair can supersede any prior notifications sent for a
`non-winning key-value pair from the conflict. The key-value
`pair can be provided to devices in response to a received
`request.
`[0062] FIG. 5 is a flow chart of an example process 500 for
`client side conflict resolution. The process 500 can be per­
`formed by one or more computing devices, for example, by
`the first device 102 of FIG. 1.
`
`11
`
`

`

`US 2012/0310882 Al
`
`Dec. 6, 2012
`
`5
`
`[0063] A key-value pair is sent for storage (step 502). For
`example, a particular device can send the key-value pair using
`a key-value daemon that received the key-value pair from a
`particular application as described above.
`[0064] A notification of a conflict is received (step 504).
`The notification indicates that the sent key-value pair is out of
`sequence relative to a key-value pair received from another
`device.
`[0065] A determination is made as to whether one of the
`conflicting key-value pairs represents an initial synchroniza­
`tion (step 506). For example, when a new device is associated
`with the user or user account (e.g., the user purchases a new
`mobile device), the device has never been synchronized with
`other user devices. When sending key-value pairs to the
`remote storage location for the first time, an indication that it
`is an initial synchronization is included. The initial synchro­
`nization presents a problem because the new device may have
`default settings to applications that could override user modi­
`fications to applications if synchronized.
`[0066] If the conflicting key-value pairs do not include a
`key-value pair from an initial synchronization, the times­
`tamps associated with each respective key value pair are
`compared (step 508). The timestamps indicate the time in
`which the key-value pair was generated by the application, for
`example, when the user entered the change. This is in contrast
`to a time in which the key-value pair was uploaded to the
`remote storage location.
`[0067] The key-value pair with the latest timestamp is
`selected as the co