System and method for synchronizing between a user device and a server in a communication network

CROSS-REFERENCE TO RELATED APPLICATIONS

0001This application is related to the following patent applications: U.S. application Ser. No. ______ (attorney docket number 32421-2000800), entitled “System and Method for Provisioning a User Device,” to Markus Meyer et al.; U.S. application Ser. No. ______ (attorney docket number 32421-2001700), entitled “System and Method for Servicing a User Device,” to Matthias Breuer et al.; U.S. application Ser. No. ______ (attorney docket number 32421-2002200), entitled “An Alert Mechanism for Notifying Multiple User Devices Sharing a Connected-Data-Set,” to Venkatachary Srinivasan et al.; U.S. application Ser. No. ______ (attorney docket number 32421-20021.00), entitled “Methods and Systems for Data Transer and Notification Mechanisms,” to Marco Boerris et al.; U.S. application Ser. No. ______ (attorney docket number 32421-2000900), entitled “Content Router,” to Torsten Schulz et al., which are filed concurrently herewith and are hereby incorporated by reference in their entirety.

FIELD OF THE INVENTION

0002The present invention relates generally to the field of providing services to one or more user devices in a communication network. In particular, the present invention relates to system and method for synchronizing between a user device and a server in a communication network.

BACKGROUND OF THE INVENTION

0003The recent proliferation of electronic devices for communication, information management and recreation has taken routine computing power far away from the desk-bound personal computer. Users are using devices such as cell phones, camera phones, personal digital assistants (PDAs) and navigation systems, not only in the office and in the home, but also in the field and on the road. There is a diverse range of possible applications for such devices, including communication, business, navigation, entertainment and even managing basic daily activities. Many users today only use a single device for a single task, for example, using cell phones for making and receiving phone calls. However, these devices are no longer single-function devices. They are capable of creating various types of data, for instance, electronic mail, voice messages, photos, video, etc. Increasing the number of functions of a device increases the level of personalization to the users. It is desirable to provide users a connected-service to connect and access their data wherever they are, with whatever device they are using and whatever service they are connected to.

0004One of the challenges of providing such a connected-service to a user is the need of provisioning a mobile device after the user has purchased the product. Traditionally, a user would have to provision the device through a cradle connected to a personal computer. This typically takes place in the home or in the office. Until the provisioning step is completed, the user cannot use the mobile device. Therefore, there is a need for provisioning a mobile device anytime and anywhere.

0005Another challenge of providing such a connected-service to a user is the need of connecting one or more user devices to a set of settings and data the user has already established in his PC, PDA, cell phone, or other devices. For example, there is a need for a user to clone the set of settings and data from an existing device to a new device upon acquiring the new device. There is a need for the user to repair or replace an existing device with the set of settings and data. There is a need for the user to terminate the service of a user device if the user device is lost, stolen, or temporarily misplaced.

0006Yet another challenge of providing such a connected-service to a user is the need of notifying the user status of communications to the one or more user devices that share a common set of settings and data. For example, there is a need for notifying the user when there is an overflow condition in the storage of emails, tasks, calendar events, or address book entries at the one or more user devices.

0007Yet another challenge of providing such a connected-service to a user is the need of maintaining consistency of data among the server and the one or more user devices that share a common set of settings and data. For example, when the service has been interrupted at a server for a period of time, there is a need to synchronize the data changes among the server and the one or more user devices.

SUMMARY

0008In one embodiment, a system for synchronizing a server and one or more user devices in a communication network includes a server for communicating with the user device, where the server includes a connected-data-set and the one or more user devices share portions of the connected-data-set, logic for creating a backup of the connected-data-set at the server in accordance with a predetermined backup interval, logic for generating a checkpoint marker for tracking the time intervals when the backup of the connected-data-set is created, and logic for sending the checkpoint marker to the one or more user devices for maintaining a first record of changes to the connected-data-set.

0009In another embodiment, a method for synchronizing a server and one or more user devices in a communication network includes providing a server for communicating with the user device, where the server includes a connected-data-set and the one or more user devices share portions of the connected-data-set, creating a backup of the connected-data-set at the server in accordance with a predetermined backup interval, generating a checkpoint marker for tracking the time intervals when the backup of the connected-data-set is created, and sending the checkpoint marker to the one or more user devices for maintaining a first record of changes to the connected-data-set.

BRIEF DESCRIPTION OF THE DRAWINGS

0010The aforementioned features and advantages of the invention as well as additional features and advantages thereof will be more clearly understandable after reading detailed descriptions of embodiments of the invention in conjunction with the following drawings.

0011<figref idref="DRAWINGS">FIG. 1</figref><i>a </i>illustrates a connected-life service according to an embodiment of the present invention.

0012<figref idref="DRAWINGS">FIG. 1</figref><i>b </i>illustrates a connected-life server in support of the connected-life service of <figref idref="DRAWINGS">FIG. 1</figref><i>a </i>according to an embodiment of the present invention.

0013<figref idref="DRAWINGS">FIG. 2</figref> illustrates an implementation of a device manager of a connected-life server according to an embodiment of the present invention.

0014<figref idref="DRAWINGS">FIG. 3</figref> illustrates a workflow for provisioning an un-configured account group according to an embodiment of the present invention.

0015<figref idref="DRAWINGS">FIG. 4</figref> illustrates a workflow for provisioning a pre-configured account group according to an embodiment of the present invention.

0016<figref idref="DRAWINGS">FIG. 5</figref> illustrates a workflow for provisioning Microsoft Outlook according to an embodiment of the present invention.

0017<figref idref="DRAWINGS">FIG. 6</figref> illustrates a workflow for provisioning a device via a pre-installed Loader according to an embodiment of the present invention.

0018<figref idref="DRAWINGS">FIG. 7</figref> illustrates a workflow for provisioning a device via a website according to an embodiment of the present invention.

0019<figref idref="DRAWINGS">FIG. 8</figref> illustrates a workflow of device provisioning via website with verified phone number according to an embodiment of the present invention.

0020<figref idref="DRAWINGS">FIG. 9</figref> illustrates a workflow of device provisioning via website without verified phone number according to an embodiment of the present invention.

0021<figref idref="DRAWINGS">FIG. 10</figref> illustrates a workflow of device provisioning via website for an ActiveX device according to an embodiment of the present invention.

0022<figref idref="DRAWINGS">FIG. 11</figref> illustrates a workflow of device provisioning via website using the client software according to an embodiment of the present invention.

0023<figref idref="DRAWINGS">FIG. 12</figref> illustrates a workflow of device provisioning via website using existing sync stack on the device according to an embodiment of the present invention.

0024<figref idref="DRAWINGS">FIG. 13</figref> illustrates a workflow of device provisioning via SMS according to an embodiment of the present invention.

0025<figref idref="DRAWINGS">FIG. 14</figref> illustrates a workflow of device provisioning via online shop according to an embodiment of the present invention.

0026<figref idref="DRAWINGS">FIG. 15</figref> illustrates an overview of the REx Protocol flow.

0027<figref idref="DRAWINGS">FIG. 16</figref> illustrates a flow diagram of interactions between a user device and a server using the different REx methods.

0028<figref idref="DRAWINGS">FIG. 17</figref> illustrates a sequence diagram for a query process according to an embodiment of the present invention.

0029<figref idref="DRAWINGS">FIG. 18</figref> illustrates a sync anchor protocol for synchronizing between a client device and a server according to an embodiment of the present invention.

0030<figref idref="DRAWINGS">FIG. 19</figref> illustrates a process flow diagram when the device exchanges device type identification settings according to an embodiment of the present invention.

0031<figref idref="DRAWINGS">FIG. 20</figref> illustrates a process flow diagram when the device tries to exchange settings other than device type identification in the zombie state according to an embodiment of the present invention.

0032<figref idref="DRAWINGS">FIG. 21</figref> illustrates a sequence diagram for normal settings exchange according to an embodiment of the present invention.

0033<figref idref="DRAWINGS">FIG. 22</figref> illustrates a sequence diagram for dump settings according to an embodiment of the present invention.

0034<figref idref="DRAWINGS">FIG. 23</figref> illustrates a sequence diagram of an application exchange process flow between a device and a server according to an embodiment of the present invention.

0035<figref idref="DRAWINGS">FIG. 24</figref> illustrates an application exchange state transition diagram according to an embodiment of the present invention.

DESCRIPTION OF EMBODIMENTS

0036Methods and systems are provided for synchronizing between a user device and a server in a communication network. The following descriptions are presented to enable any person skilled in the art to make and use the invention. Descriptions of specific embodiments and applications are provided only as examples. Various modifications and combinations of the examples described herein will be readily apparent to those skilled in the art, and the general principles defined herein may be applied to other examples and applications without departing from the spirit and scope of the invention. Thus, the present invention is not intended to be limited to the examples described and shown, but is to be accorded the widest scope consistent with the principles and features disclosed herein.

0037Some portions of the detailed description which follows are presented in terms of procedures, steps, logic blocks, processing, and other symbolic representations of operations on data bits that can be performed on computer memory. A procedure, computer-executed step, logic block, process, etc., are here conceived to be a self-consistent sequence of steps or instructions leading to a desired result. The steps are those utilizing physical manipulations of physical quantities. These quantities can take the form of electrical, magnetic, or radio signals capable of being stored, transferred, combined, compared, and otherwise manipulated in a computer system. These signals may be referred to at times as bits, values, elements, symbols, characters, terms, numbers, or the like. Each step may be performed by hardware, software, firmware, or combinations thereof.

0038<figref idref="DRAWINGS">FIG. 1</figref><i>a </i>illustrates a connected-life service according to an embodiment of the present invention. The connected-life service enables users to share and access their connected-data-set with any device at anytime from anywhere. User devices (also referred to as device or client) may include cellular phones, wireless personal digital assistants, navigation devices, personal computers, game consoles, Internet terminals, and Kiosks. A connected-data-set may include emails, contacts, calendar, tasks, notes, pictures, documents, music, videos, bookmarks, and links.

0039In different embodiments, the connected-life service provides the following functionalities: 1) repairing a user device, 2) cloning a first user device to a second user device, 3) replacing a first user device with a second user device, and 4) terminating services of a user device. The service of repairing a user device includes resetting states of the one or more user devices, and restoring configurations and settings of the one or more user devices, and restoring the connected-data-set onto the one or more user devices.

0040The service of cloning a first user device to a second user device includes transferring configurations and settings of the first user device to the second user device, and transferring portions of the connected-data-set to the second user device in accordance with the settings of the first user device.

0041The service of replacing a first user device with a second user device includes transferring a set of predetermined configurations and settings from the configuration database to the second user device, where the second user device has an identical model, make, and type of the first device, and transferring portions of the connected-data-set to the second user device according to the settings of the second user device. The service of replacing a first user device with a second user device further includes transferring a set of predetermined configurations and settings from the configuration database to the second user device, where the second user device has a different model, make, or type from the first device, and transferring portions of the connected-data-set to the second user device in accordance with the settings of the second user device.

0042The service of terminating services of a user device includes deleting the configurations and settings of the user device, terminating communications to the user device, and sending termination status to other devices of the user. Note that terminating service of a device not only applies to remove service from the device, it may also be utilized in a “device lost” or “device stolen” scenario. In such a scenario, not only the software and settings, but also the user data (such as mails, attachments, PIM, Photos, etc) may be removed.

0043In addition, another feature of the device termination service is device blocking. In this scenario, the user cannot find the device but he also does not know for sure if it is lost or just misplaced somewhere, assuming that there still is a good chance the device may be found. In this case, the service offers the user the ability to block the device or to block at least the data service to the device temporarily until further instructions from the user.

0044<figref idref="DRAWINGS">FIG. 1</figref><i>b </i>illustrates a connected-life server in support of the connected-life service of <figref idref="DRAWINGS">FIG. 1</figref><i>a </i>according to an embodiment of the present invention. The connected-life server <b>100</b> may be implemented by one or more computers/servers in different geographical locations. The connected-life server manages the connected-data-set among the different computing devices a user may create or store data, including personal computers <b>102</b> and <b>104</b>, mobile devices <b>106</b>, servers <b>108</b>, and web portals <b>110</b> and <b>112</b>.

0045<figref idref="DRAWINGS">FIG. 2</figref> illustrates an implementation of a device manager of a connected-life server according to an embodiment of the present invention. The device manager <b>200</b> includes a web front-end <b>202</b>, a device controller <b>204</b>, a device description storage <b>206</b>, and a set of protocol adapters <b>208</b>. The device manager communicates and manages the user devices <b>210</b> through the protocol adapters <b>208</b>. In addition, the device manager communicates with other portions of the connected-life server through a user management unit <b>212</b> and a smart content routing unit <b>214</b>. Note that the user management unit is used to manage user devices from different services. This unit is optional if all users are from the same Internet service provider, such as the SBC-Yahoo DSL service.

0046The device controller <b>204</b> further includes a software management unit <b>216</b>, a service manager <b>218</b>, a settings change dispatcher <b>220</b>, and a device state storage <b>222</b>. The software management unit <b>216</b> installs, updates, and de-installs records, settings, and applications for the user devices. The service manager <b>218</b> manages the types of services supported for the user devices. The service manager provides information to the smart content routing unit <b>214</b> for transferring the connected-date-set among the user devices and the connected-life server. The setting change dispatcher <b>220</b> provides changes in device settings from the device manager to the user devices. The device state storage <b>222</b> stores the information about the operating states of the user devices.

0047The device description storage <b>206</b> stores type descriptions <b>224</b>, transcodings <b>226</b>, account templates <b>228</b>, and service descriptions <b>230</b> of the user devices <b>210</b> supported by the connected-life service. The device manager transfers such device information between the device description storage <b>206</b> and a file server <b>230</b>. The device manager associates user devices with different combinations of type descriptions, transcodings, account templates, and service descriptions such that each of the combination may be tested and verified for a predefined group of user devices. As a result, different service lines contain corresponding device characteristics and services may be provided to different groups of users.

0048The protocol adapters <b>208</b> may include a provisioning unit <b>232</b>, a record exchange unit <b>234</b>, a setting exchange unit <b>236</b>, an application exchange unit <b>238</b>, a SyncML unit <b>240</b>, and other adaptor units <b>242</b>. Note that the functional units described above (i.e. logical blocks <b>200</b>-<b>244</b>) may be implemented in software, hardware, or a combination of software and hardware. The interactions among the functional units are further described in the following sections.

0000Provisioning a User Device

0049In general, these are two ways customers can subscribe to the connected-life service: 1) register account, followed by device provisioning; and 2) register device, whereby the registration of a connected-life service account is included in the procedure (if not already active).

0050Of the two choices when a user subscribes to the connected-life service, the first is to register an account. The connected-life service is to be offered through service providers who maintain accounts for their customers. This may include, but is not limited to, email accounts, PIM storage and management facilities, and “briefcase” functionality—storage for users' other files, such as photos, music, documents, and other data.

0051When users register for the services offered by the connected-life service, they are doing so as an already registered customer of the service provider offering them. As such, they already have accounts which are enabled for the connected-life service usage. An implementation of account provisioning is described below. It contains the following sections:

0052Account Groups <ul id="ul0001" list-style="none"><li id="ul0001-0001" num="0000"><ul id="ul0002" list-style="none"><li id="ul0002-0001" num="0053"> This section describes the different account groups, or account types. Knowing these groups is necessary in order to understand the different account provisioning use cases. </li></ul></li></ul>

0054Use Cases <ul id="ul0003" list-style="none"><li id="ul0003-0001" num="0000"><ul id="ul0004" list-style="none"><li id="ul0004-0001" num="0055"> There are three account provisioning use cases. Each is described in the following sections. </li></ul></li></ul>

0056Users also have the option to register an account by first registering their devices. Here, as part of the device provisioning process, an account is created automatically.

0000Account Groups

0057User accounts can be arranged into groups. Each account group may be provisioned using more than one method. Table 1 shows sample account groups supported by the connected-life service. <tables id="TABLE-US-00001" num="1"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="3"><colspec colname="1" colwidth="56PT" align="left" /><colspec colname="2" colwidth="56PT" align="left" /><colspec colname="3" colwidth="105PT" align="left" /><thead><row><entry namest="1" nameend="3" align="center">TABLE 1</entry></row><row><entry /></row><row><entry namest="1" nameend="3" align="center" rowsep="1" /></row><row><entry>Account Group</entry><entry>Access Protocol</entry><entry>Description</entry></row><row><entry namest="1" nameend="3" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry>Exchange</entry><entry>WebDAV</entry><entry>Any Microsoft Exchange account</entry></row><row><entry>WebDAV</entry><entry>(RFC 2518)</entry><entry>whose server exposes WebDAV.</entry></row><row><entry>IMAP</entry><entry>IMAP</entry><entry>A mail account located on any</entry></row><row><entry /><entry /><entry>IMAP server.</entry></row><row><entry>POP3</entry><entry>POP3</entry><entry>A mail account located on any</entry></row><row><entry /><entry /><entry>POP3 server.</entry></row><row><entry>Outlook</entry><entry>REx</entry><entry>A generic account group used to</entry></row><row><entry>Redirector</entry><entry /><entry>access the email and PIM data in</entry></row><row><entry /><entry /><entry>Microsoft Outlook.</entry></row><row><entry namest="1" nameend="3" align="center" rowsep="1" /></row></tbody></tgroup></table></tables><br /> Use Cases

0058Account groups can be provisioned for the connected-life service in three different ways. These use cases are explained on the following sections.

00591) Provisioning an Un-Configured Account Group <ul id="ul0005" list-style="none"><li id="ul0005-0001" num="0000"><ul id="ul0006" list-style="none"><li id="ul0006-0001" num="0060"> Here, the details of the account the user is registering are, for the most part, not known to the connected-life server (CLS). Therefore, the user enters these details manually, and as such it is only intended for experienced users. </li></ul></li></ul>

00612) Provisioning a Pre-Configured Account Group <ul id="ul0007" list-style="none"><li id="ul0007-0001" num="0000"><ul id="ul0008" list-style="none"><li id="ul0008-0001" num="0062"> When the technical specifications for an account group are already known to the CLS, then the provisioning of accounts can occur in an easy fashion, requiring the least amount of user effort. </li></ul></li></ul>

00633) Provisioning Microsoft Outlook <ul id="ul0009" list-style="none"><li id="ul0009-0001" num="0000"><ul id="ul0010" list-style="none"><li id="ul0010-0001" num="0064"> For users who wish to have accounts located on their own PC, and use their Microsoft Outlook application. </li></ul></li></ul>

0065The prerequisite for provisioning an un-configured account group is that the user already has an account from any account group other than Outlook Redirector. The applicable account groups are Exchange, WebDAV, IMAP, and POP3. In this use case, the user specifies all the information required by the CLS in order that it may register the account/data source. This includes such regular parameters as the account username and password, as well as the names of the servers and their respective port numbers.

0066This is the most complex of all three use cases and is therefore only recommended for experienced users. It may be implemented only when the service provider does not know these data source parameters, for example, if it is offering users to connect to data sources other than those of the service provider.

0067<figref idref="DRAWINGS">FIG. 3</figref> illustrates a workflow for provisioning an un-configured account group according to an embodiment of the present invention. The user 1) logs on to the service provider's website; 2) selects the appropriate account group; and 3) enters all the necessary parameters for the account. Once these steps have been completed, the CLS creates the account.

0068<figref idref="DRAWINGS">FIG. 4</figref> illustrates a workflow for provisioning a pre-configured account group according to an embodiment of the present invention. The prerequisite for provisioning a pre-configured account group is that the user already has an account from any account group other than Outlook Redirector. The applicable account groups are those offered by the service provider. This use case is based upon knowing most of the account's specifications before the user chooses to register. In contrast to the first use case, this one involves the provisioning of a pre-configured account group. That is, most of the specifications of the account are already known to the connected-life server, and the user merely enters its credentials for the service provider in order to register an account. Specifications like server names, port numbers, and so on are not required to be typed in.

0069This is an easy way to provision an account. The user is only required to provide a simple answer that “Yes, I want to subscribe to this service” and the rest is handled by the connected-life service. After users log on with their service provider, they select the account they wish to register with the connected-life service.

0070<figref idref="DRAWINGS">FIG. 5</figref> illustrates a workflow for provisioning Microsoft Outlook according to an embodiment of the present invention. The prerequisite for provisioning Microsoft Outlook is that the users have Microsoft Outlook installed on their PCs. The applicable account group is the Outlook Redirector.

0071With this option, the user can select to have their Microsoft Outlook application on their personal computer as a data source. In contrast to Use Cases I and II, where the account is located on the servers of the service provider, the provision of a Microsoft Outlook account means it is located locally, on the user's own PC.

0072Using this method, the user may still have their Exchange, IMAP, or POP account as a connected-life service account, but the CLS may connect to Microsoft Outlook and not to a provider's server(s). It may connect either to the locally stored data in Outlook's .pst file, or, in the case where Outlook is being used to connect to an Exchange account, to the Exchange profile and through it to the Exchange server. The latter scenario can be used to overcome firewall problems between the CLS and an Exchange server.

0073Provisioning Microsoft Outlook means installing the Outlook Redirector on the user's PC. The Redirector acts as the intermediary between the data in Outlook's .pst file/Exchange profile and the connected-life server. Note that Outlook can also be provisioned as a device, whose data may be sourced from an account. Details on how devices are provisioned are described in the sections below.

0074<figref idref="DRAWINGS">FIG. 5</figref> illustrates a workflow for registering Outlook as a data source according to an embodiment of the present invention. The workflow for registering Outlook as a data source is as follows: <ul id="ul0011" list-style="none"><li id="ul0011-0001" num="0000"><ul id="ul0012" list-style="none"><li id="ul0012-0001" num="0075"> 1. The user logs on to the service provider's website. </li><li id="ul0012-0002" num="0076"> 2. The user selects the Outlook Redirector account group. </li><li id="ul0012-0003" num="0077"> 3. The Loader is installed on the PC. </li><li id="ul0012-0004" num="0078"> 4. The user enters the username and password for the PC. </li><li id="ul0012-0005" num="0079"> 5. The account is activated, and the client software is installed. </li></ul></li></ul>

0080Users can provision a device after they have completed the registration of their account. Alternatively, the connected-life service gives users the possibility to register their device and account at the same time (that is, from a user's point of view). The aim is to make the provisioning process as easy and as simple as possible. At the conclusion of the provisioning, the user comes away with an account whose data is connected to their device(s). There are at least four entry points in the device provisioning process: <ul id="ul0013" list-style="none"><li id="ul0013-0001" num="0000"><ul id="ul0014" list-style="none"><li id="ul0014-0001" num="0081"> 1. The user receives the Loader software. </li><li id="ul0014-0002" num="0082"> 2. The user enters via a website. Either the user may log on to the service provider's website, or a sales assistant or customer service representative (CSR) registers the user (in a shop, over the telephone) on their behalf. </li><li id="ul0014-0003" num="0083"> 3. The user sends an SMS to a number specified by their service provider. </li><li id="ul0014-0004" num="0084"> 4. The user logs on to the online shop of their provider. </li></ul></li></ul>

0085In addition, the user can opt to restore their device, in those cases where the device has lost all or part of its data, or the user loses the device and replaces it with another of the same type. All of these scenarios assume that the customer is already a registered user with the service provider offering the connected-life service. They also assume that if the user has not yet subscribed to the connected-life service, he will be registered according to Use Case II for provisioning a pre-configured account group.

0086<figref idref="DRAWINGS">FIG. 6</figref> illustrates a workflow for provisioning a device via a pre-installed Loader according to an embodiment of the present invention. One way in which a user can register their device for the connected-life service is through the installation of the Loader application on their device. The Loader is an application that facilitates the provisioning of the device and the installation of the client software.

0087The Loader may be made available to users in a variety of ways, including via download, CD-ROM, SD or other memory card, or any other method of transmitting the loader to the device. Loaders are labeled (with version numbers) for specific device types. Hence, when the device connects to the CLS for registration, the server will automatically know the device type and whether the client software needs to be installed. The steps for provisioning a device via a pre-installed Loader are: <ul id="ul0015" list-style="none"><li id="ul0015-0001" num="0000"><ul id="ul0016" list-style="none"><li id="ul0016-0001" num="0088"> 1. The loader starts on the device. </li><li id="ul0016-0002" num="0089"> 2. The loader displays a service provider logon screen. </li><li id="ul0016-0003" num="0090"> 3. The user enters their account username, password, and a name for their device (e.g., My Phone). </li><li id="ul0016-0004" num="0091"> 4. If the user is not yet a customer of the service provider, a message is displayed asking the user to contact the provider. </li><li id="ul0016-0005" num="0092"> 5. If the user is not yet a subscriber to the connected-life service, their account will be automatically activated. </li><li id="ul0016-0006" num="0093"> 6. Once the user has provided their account credentials, the Loader will download the client software, which has been configured with pre-determined services (like the data types that will be exchanged) as well as default filters. The download can be either over-the-air or via a PC connection, or simply transferred from a local memory card. </li><li id="ul0016-0007" num="0094"> 7. The CLS activates the services on the device. It imports the existing data from the device (default operation) and connects the device to the account. It performs any duplicate handling necessary with records in the account, before sending records from it to the device. </li><li id="ul0016-0008" num="0095"> The device is now provisioned and ready to exchange data. </li></ul></li></ul>

0096<figref idref="DRAWINGS">FIG. 7</figref> illustrates a workflow for provisioning a device via a website according to an embodiment of the present invention. In this scenario, the user registers their device for the connected-life service using a web browser. This can be either: <ul id="ul0017" list-style="none"><li id="ul0017-0001" num="0000"><ul id="ul0018" list-style="none"><li id="ul0018-0001" num="0097"> Directly, via the service provider's website available to their customers. The user logs in. </li><li id="ul0018-0002" num="0098"> Via a CSR. Typical scenarios include the user calling a service/sales hotline or the user visiting one of the service provider's shops, where a sales assistant may proceed to register the customer on their behalf. </li></ul></li></ul>

0099There are two stages to provisioning a device using a web browser: 1) pre-provisioning, and 2) provisioning the device. Before the provisioning process begins, the CLS determines what kind of device is being provisioned and how it is currently connected (via PC, wireless). It also knows whether the provisioning is new or whether the user wishes to restore the device. A device restore is necessary when it has been lost and replaced by a new one, has been hard reset and lost its programs and data, or has lost data some other way.

0100Device restores are not necessary if the device has lost data of a type that it exchanges with the CLS, nor if the device has been backed up to a previous configuration. In the former case, a regular data exchange will occur and the lost data retrieved from the account. In the latter case, a slow sync will be initiated to get the device back to the current state of the account. In other words, if the client software is deleted, a restore is required. The server requests all data from the device in question, compares all records with the inventory to identify mismatches, and updates the device with the records from the inventory. Note that device restores do not apply to push devices.

0101In the event the server is out of sync with the user device and a backup of the server side inventory is restored, the slow sync process may be optimized by keeping a checkpoint marker (for example a time stamp) on the device every time a backup of the server side inventory is done. This allows the server to compare only those records that have changed after the checkpoint marker. This method reduces the amount of data need to be transferred to the user device. Thus, it shortens the duration and lightens the transmission bandwidth usage of the slow sync process.

0102The provisioning process itself is dependent on the type of device being registered. In this regard, it falls into five categories: <ul id="ul0019" list-style="none"><li id="ul0019-0001" num="0000"><ul id="ul0020" list-style="none"><li id="ul0020-0001" num="0103"> 1. Push device with verified phone number. </li><li id="ul0020-0002" num="0104"> 2. Push device without verified phone number. </li><li id="ul0020-0003" num="0105"> 3. ActiveX-enabled device. </li><li id="ul0020-0004" num="0106"> 4. Device using the client software. </li><li id="ul0020-0005" num="0107"> 5. Device using own sync stack. <br /> These processes are described in detail in the following sections. </li></ul></li></ul>

0108The steps for pre-provisioning a device via a website are: <ul id="ul0021" list-style="none"><li id="ul0021-0001" num="0000"><ul id="ul0022" list-style="none"><li id="ul0022-0001" num="0109"> 1. There are numbers of ways a user may start the provisioning of their device through a website. The user may call the service provider's call center, visit one of their shops, or browse their website directly. In all cases the provisioning is performed via the web. </li><li id="ul0022-0002" num="0110"> 2. As in the first use case where the user installs the Loader, if the user does not yet have a connected-life service account, then this is automatically created. </li><li id="ul0022-0003" num="0111"> 3. If the device is being restored (for example, due to a hard reset), then the device is provisioned according to the device category. </li><li id="ul0022-0004" num="0112"> 4. The rest of the pre-provisioning process depends on how the device is detected by the CLS, which is in many ways related to how the device is currently connected. <figref idref="DRAWINGS">FIG. 7</figref> shows three possibilities: <ul id="ul0023" list-style="none"><li id="ul0023-0001" num="0113"> a. User browsing using device. <ul id="ul0024" list-style="none"><li id="ul0024-0001" num="0114"> In this case, the CLS will detect the device type and can direct the user to the Loader download page. The loader is then started by the user, and the provisioning process continues as shown in <figref idref="DRAWINGS">FIG. 4</figref>. </li></ul></li><li id="ul0023-0002" num="0115"> b. Device type detected via PC connection (or device is PC). <ul id="ul0025" list-style="none"><li id="ul0025-0001" num="0116"> Here, either the device is connected to the PC, or the device being provisioned is the PC itself. The administration application can detect the device type through this connection, using an ActiveX control. For devices connected via a PC, the provisioning will occur over it. <ul id="ul0026" list-style="none"><li id="ul0026-0001" num="0117"> i. The account, services, and filters are configured (performed partly by the user or fully automatic). </li><li id="ul0026-0002" num="0118"> ii. If the service provider is not the carrier, the phone number for the device is entered. If the provider and carrier are the same, then the number is already known. </li></ul></li></ul></li><li id="ul0023-0003" num="0119"> c. User manually selects device type from menu. <ul id="ul0027" list-style="none"><li id="ul0027-0001" num="0120"> It is assumed here that the device either is connected wirelessly or, if connected to the PC, cannot be detected for some reason. The provisioning process can occur over the air, via the device's memory card, or through some other method. </li><li id="ul0027-0002" num="0121"> As the device cannot be automatically detected, the user manually selects the device type from a list. Once done, the pre-configuration of the account, services, and filters occurs (refer to 4.b.i., above), and the process continues from there. </li></ul></li></ul></li><li id="ul0022-0005" num="0122"> 5. The pre-provisioning process is now complete. The provisioning itself now begins, based on the device type and described in the following sections. </li></ul></li></ul>

0123In another example, the pre-provisioning is used to restore a device. The connected-life service offers the possibility of restoring a device in the event that: <ul id="ul0028" list-style="none"><li id="ul0028-0001" num="0000"><ul id="ul0029" list-style="none"><li id="ul0029-0001" num="0124"> The device is replaced with another of the same type (due to theft, damage, etc.). </li><li id="ul0029-0002" num="0125"> The device has been reset, or in some other way has lost its connected-life service configuration. </li></ul></li></ul>

0126In these cases, the device (or the replacement device) can be restored. The pre-provisioning process proceeds through the steps—the user, device, and its previous configuration are already known to the server. The provisioning process can commence based on the device category.

0127<figref idref="DRAWINGS">FIG. 8</figref> illustrates a workflow of device provisioning via website with verified phone number according to an embodiment of the present invention. The workflows described here and in the next section, “Workflow—push device without verified phone number,” apply to so-called “push” devices, or in other words, MMS devices. It offers the most basic level of data exchange, and is one-way. In essence, data is pushed to the device by the CLS. The data is not intended to be changed by the user on the device, and any changes made are not sent back to the CLS. Email is an example of one data type that may be pushed to devices.

0128These devices do not require any software to be installed for use with the connected-life service. In the provisioning process shown in FIG. DP<b>6</b>, once the pre-provisioning process is completed, it is just a matter of activating the services for the device and sending it data. In this use case, the device's phone number has already been verified by the CLS. Verification of the phone number is performed for security reasons, to ensure that data is sent to the right device.

0129<figref idref="DRAWINGS">FIG. 9</figref> illustrates a workflow of device provisioning via website without verified phone number according to an embodiment of the present invention. In this use case, the device is a push device (as above), but its phone number may still be verified. This process forms the main part of its provisioning, and once this has been done and its services activated, the device is ready to go. The phone number verification process is as follows: <ul id="ul0030" list-style="none"><li id="ul0030-0001" num="0000"><ul id="ul0031" list-style="none"><li id="ul0031-0001" num="0130"> 1. The user enters the phone number and clicks OK to send an SMS to it. </li><li id="ul0031-0002" num="0131"> 2. The SMS is sent to the device. It displays a 4-digit verification number. </li><li id="ul0031-0003" num="0132"> 3. At the same time, the browser opens a page for the user to enter this verification number. </li><li id="ul0031-0004" num="0133"> 4. The user enters the verification number. </li><li id="ul0031-0005" num="0134"> 5. Once confirmed, the CLS then proceeds to activate the services for the device, and the provisioning process is completed. </li></ul></li></ul>

0135<figref idref="DRAWINGS">FIG. 10</figref> illustrates a workflow of device provisioning via website for an ActiveX device according to an embodiment of the present invention. This provisioning workflow applies to the following devices:

0136PCs with ActiveX-enabled web browsers.

0137Handheld devices connected to such a PC.

0138The Loader includes an ActiveX control that allows the CLS to detect the device type and to install the client software. It also authenticates the device with the CLS, permitting the client software download.

0139<figref idref="DRAWINGS">FIG. 11</figref> illustrates a workflow of device provisioning via website using the client software according to an embodiment of the present invention. This workflow applies to devices that require installation of the client software. The procedure is as follows: <ul id="ul0032" list-style="none"><li id="ul0032-0001" num="0000"><ul id="ul0033" list-style="none"><li id="ul0033-0001" num="0140"> 1. The browser displays the URL of the Loader as well as a unique PIN for the user. In addition: <ul id="ul0034" list-style="none"><li id="ul0034-0001" num="0141"> a. For CSRs, the browser will also display the URLs of any other available binaries. </li><li id="ul0034-0002" num="0142"> b. For developers, the browser gives them the option of entering in the URLs of the CLS installation and the Loader, as well as those of other binaries that need to be installed. </li></ul></li><li id="ul0033-0002" num="0143"> 2. Regular users will jump straight to the Loader installation: <ul id="ul0035" list-style="none"><li id="ul0035-0001" num="0144"> a. If it is to be installed over the air, the CLS will send a configuration SMS to the device that includes the URL for the Loader. Opening it starts the download. </li><li id="ul0035-0002" num="0145"> b. If the device is connected to the PC, the Loader will download and start automatically. </li><li id="ul0035-0003" num="0146">  Both of these steps require the user to enter in the previously displayed PIN for authentication purposes. </li></ul></li><li id="ul0033-0003" num="0147"> 3. After the Loader is started, it will download, install, and start the client software. </li><li id="ul0033-0004" num="0148"> 4. The device services will be activated, data imported from the device (if selected), duplicate records handled by the CLS, and records from the account sent to the device. The provisioning process is complete. </li></ul></li></ul>

0149<figref idref="DRAWINGS">FIG. 12</figref> illustrates a workflow of device provisioning via website using existing sync stack on the device according to an embodiment of the present invention. This workflow applies to those devices that have their own synchronization stack, for example, SyncML devices. In this case the client software does not need to be installed. The workflow for most devices is quite simple. Only a configuration SMS needs to be sent to the device that specifies the server name, port number, and so forth. Once done, the provisioning continues in the normal way by activating services and starting the exchange of data.

0150In the case where a device needs additional software to be installed, the procedure followed is basically the same as that for the installation of the Loader shown in <figref idref="DRAWINGS">FIG. 9</figref>. That is: <ul id="ul0036" list-style="none"><li id="ul0036-0001" num="0000"><ul id="ul0037" list-style="none"><li id="ul0037-0001" num="0151"> 1. The browser displays the URLs of the binaries as well as a unique PIN for the user. In addition: <ul id="ul0038" list-style="none"><li id="ul0038-0001" num="0152"> a. For CSRs, the browser will also display the URLs any other available binaries. </li><li id="ul0038-0002" num="0153"> b. For developers, the browser gives them the option of entering in the URLs of the CLS installation, the Loader, as well as those of other binaries that need to be installed. </li></ul></li><li id="ul0037-0002" num="0154"> 2. Regular users will jump straight to the binary installation: <ul id="ul0039" list-style="none"><li id="ul0039-0001" num="0155"> a. If it is to be installed over the air, the CLS will send a configuration SMS to the device that includes the URLs for the binaries. Opening it starts the download. </li><li id="ul0039-0002" num="0156"> b. If the device is connected to the PC, the binary will download and start automatically. </li><li id="ul0039-0003" num="0157">  Both of these steps require the user to enter in the previously displayed PIN for authentication purposes. </li></ul></li><li id="ul0037-0003" num="0158"> 3. The device services will be activated, data imported from the device (if selected), duplicate records handled by the CLS, and records from the account sent to the device. The provisioning process is complete. </li></ul></li></ul>

0159<figref idref="DRAWINGS">FIG. 13</figref> illustrates a workflow of device provisioning via SMS according to an embodiment of the present invention. This use case offers a simple provisioning process, in terms of the user's experience. Here the service provider may cater the connected-life service to specific device types and allow the user to simply send an SMS to a designated number, whereupon their account is activated for connected-life use, if it is not already, and the device provisioned automatically, requiring a minimum amount of user interaction. This workflow represented in <figref idref="DRAWINGS">FIG. 13</figref> (under the specific branch) may be tailored to meet the requirements of the service provider and the device type(s) that may be provisioned. Alternatively, as shown under the general branch, upon sending an SMS, the CLS may return the URL for the user to browse to and provision the device as described in the Via Website use case.

0160<figref idref="DRAWINGS">FIG. 14</figref> illustrates a workflow of device provisioning via online shop according to an embodiment of the present invention. In this provisioning scenario, the device already meets the technical requirements for use with the connected-life service. The user has an account with the service provider (but not necessarily the connected-life service). All that the user does is to log on to the provider's website and activate the connected-life service. The provisioning is done automatically.

0000Record Exchange (REx) Application Program Interface

0161The Record Exchange API is designed to provide the functionality used in the SyncML (session-based) protocol. To accomplish this, the number of steps required and the commands used for accomplishing those steps are reduced. In the SyncML model, a process flow is described below: <ul id="ul0040" list-style="none"><li id="ul0040-0001" num="0000"><ul id="ul0041" list-style="none"><li id="ul0041-0001" num="0162"> Authenticate </li><li id="ul0041-0002" num="0163"> Start session </li><li id="ul0041-0003" num="0164"> Initialize sync session (negotiate sync type per database type) </li><li id="ul0041-0004" num="0165"> Client sends records to the server (may require multiple messages) </li><li id="ul0041-0005" num="0166"> Server performs a synchronization between the client's data and its own </li><li id="ul0041-0006" num="0167"> Server acknowledges client's records and sends records to the client (may require multiple messages) </li><li id="ul0041-0007" num="0168"> Client acknowledges the server's records </li><li id="ul0041-0008" num="0169"> End session </li></ul></li></ul>

0170As mentioned above, the entire session completes successfully in order for the synchronization operation to be considered successful. This makes the overall process error-prone primarily due to network connectivity and device stability issues.

0171The Record Exchange API addresses the integrity problem of the SyncML (session-based) sync by breaking up the process into discrete operations that can be performed, for the most part, independently of one another. The concept of synchronization is divided into its two constituent parts: putting and getting items from the client's perspective and the concept of initialization can be combined with either of these actions. So instead of using actions in a process with cascading dependencies, a typical sync using the Record Exchange API is described as: <ul id="ul0042" list-style="none"><li id="ul0042-0001" num="0000"><ul id="ul0043" list-style="none"><li id="ul0043-0001" num="0172"> The client initializes the data types it wants to use and sends items. The server sends an immediate response for this request. The server can indicate in its response whether there are items pending for the client. This step can be repeated as many times as the client deems necessary. </li><li id="ul0043-0002" num="0173"> The client initializes the data types it wants to use and requests items from the server. The server returns pending items to the client and indicates if there are still more pending. The client can repeat this step and include acknowledgement information. </li></ul></li></ul>

0174Although there are only two steps shown above, the Record Exchange API provides different functions for carrying out different parts of those steps. Client devices can use a put/get process or a more detailed process that includes separate init and acknowledgement steps as desired. Each of these steps is discussed in more detail below.

0175<figref idref="DRAWINGS">FIG. 15</figref> illustrates an overview of the REx protocol flow. In order to support protocol changes and provide backward compatibility with older devices, the device sends the current protocol version as URL parameters together with each request.

0000Exchanging Records

0176Every item exchanged through the REx API is addressed. To accomplish this, the REx API defines several components that comprise a unique reference to an item. Not all of the components are used in every situation, but for any given item, the supplied addressing information needs to be sufficient to uniquely identify that item. The addressing components defined in the REx API are data source, data type, and record ID.

0177Of these components only the record ID is mandatory. For the other two it is possible that their value will be implied in the operation being performed, in which case they can be omitted. The data source component is used to allow clients to create new items in different data sources, if a client has the ability to determine the valid data sources and possibly also be able to allow the user to select which one to use.

0178Although the names of these components originate from the original domain of the REx API, they can be used for any addressing requirements. The record ID can be a setting path function, for example. Note that for certain data types the record ID is optional. In these cases the record ID may be omitted. Within each response from the server, there is one item for each record ID.

0179Clients send records to the server using the putItems call. This function takes as parameters an array of ExchangeItems. The server responds to each putItems call with an ExchangeResult structure that contains an array of data types that have pending changes and an acknowledgement for the received items. One requirement is that clients acknowledge all items received from the server before calling putItems.

0180At any time the client can query the server for pending items by sending a getItems request. This call examines the contents of the item cache and returns any records that are pending for the client. To facilitate an optimal exchange of items and status, a client can include acknowledgement information when getting new items by using the ackAndGetItems call. The format of the acknowledgement information is described below.

0181In response to each getItems call, the server returns an ExchangeResult that contains, among other things, an array of ExchangeItems containing the contents of the pending items and an array of DataTypes that indicate which data types have more items to be retrieved.

0182To optimize the flow of items from the server to the client, the server will always send delete items before add and replace items. The requirements of the getItems request include: <ul id="ul0044" list-style="none"><li id="ul0044-0001" num="0000"><ul id="ul0045" list-style="none"><li id="ul0045-0001" num="0183"> Clients send all pending changes, via putItems, to the server before calling getItems; </li><li id="ul0045-0002" num="0184"> Clients include a limit value that the server will use to determine how much information to return in response to each getItems call; and </li><li id="ul0045-0003" num="0185"> Clients call ackItems immediately following a getItems call. </li></ul></li></ul>

0186Items are acknowledged in both directions so that the client and server know when an item has been successfully processed. Note that the terms ack and acknowledge are used interchangeably throughout this document. There are two ways to acknowledge the receipt of an item through getItems: via an individual ack or via an ack all ExchangeItems. Failure acks always require an individual ack ExchangeItem so the exact item and cause of failure can be identified. Ack all ExchangeItems are handled such that all items that are received before the item being acknowledged are interpreted as successfully processed. The Ack-all-items method contains a valid data type name. This implies that a separate ack-all-items is required for each data type involved in an exchange.

0187The server does not return any ack items in response to a putItems call. Instead it returns an overall result response for the entire putItems call. In other words, the processing of the items in a putItems call is an all-or-nothing operation. For this reason the item ref value is not used when acknowledging items sent from the client. Clients omit this value from the ExchangeItems they send to the server. It is recommended that clients send ack-all-items as soon as possible so the server will have the most accurate state representation of the client.

0188Clients that cannot or chose not to store the proposed record IDs can send back map commands that contain the (temporary) Locate Unit ID (LUID) proposed by the server and the LUID that represents the record on the client. Clients send map commands to the server by passing ExchangeItems in an ackItems call. Map commands can be sent at any time and can be sent any number of times (in the case of communication failures), and are not interpreted as an implicit receipt acknowledgement of items. Note that clients may still explicitly pass an ack item even for items are that are ID mapped. Clients may use the server's record IDs until they have sent map commands to the server.

0189To map the IDs, the client echoes back ExchangeItems received from the server, after changing the item type and replacing the data member with the client's LUID. In one embodiment, an example of ExchangeItem sent from the server is shown below: <tables id="TABLE-US-00002" num="2"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="OFFSET" colwidth="63PT" align="left" /><colspec colname="1" colwidth="154PT" align="left" /><thead><row><entry /><entry /></row><row><entry /><entry namest="OFFSET" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /><entry>struct ExchangeItem</entry></row><row><entry /><entry>{</entry></row><row><entry /><entry> itemRef = 100</entry></row><row><entry /><entry> itemType = 1  // add</entry></row><row><entry /><entry> dataTypeName = contacts</entry></row><row><entry /><entry> recordID = LUID</entry></row><row><entry /><entry> data = contact_data</entry></row><row><entry /><entry>}</entry></row><row><entry /><entry namest="OFFSET" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0190The client may return a map command like this: <tables id="TABLE-US-00003" num="3"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="OFFSET" colwidth="63PT" align="left" /><colspec colname="1" colwidth="154PT" align="left" /><thead><row><entry /><entry /></row><row><entry /><entry namest="OFFSET" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /><entry>struct ExchangeItem</entry></row><row><entry /><entry>{</entry></row><row><entry /><entry> itemRef = 100</entry></row><row><entry /><entry> itemType = 5  // map</entry></row><row><entry /><entry> dataTypeName = contacts</entry></row><row><entry /><entry> recordID = old LUID</entry></row><row><entry /><entry> data = new LUID</entry></row><row><entry /><entry>}</entry></row><row><entry /><entry namest="OFFSET" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables><br /> Record Exchange Data Structures

0191In one embodiment, examples of data structures of the REx are shown below. <tables id="TABLE-US-00004" num="4"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="OFFSET" colwidth="14PT" align="left" /><colspec colname="1" colwidth="203PT" align="left" /><thead><row><entry /><entry /></row><row><entry /><entry namest="OFFSET" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /><entry>struct DataType</entry></row><row><entry /><entry>{</entry></row><row><entry /><entry> string dataTypeName</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="3"><colspec colname="OFFSET" colwidth="14PT" align="left" /><colspec colname="1" colwidth="91PT" align="left" /><colspec colname="2" colwidth="112PT" align="left" /><tbody valign="top"><row><entry /><entry> string syncAnchor</entry><entry>optional</entry></row><row><entry /><entry> string pendingSyncAnchor</entry><entry>optional</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="OFFSET" colwidth="14PT" align="left" /><colspec colname="1" colwidth="203PT" align="left" /><tbody valign="top"><row><entry /><entry> int  exchangeStatus optional</entry></row><row><entry /><entry>}</entry></row><row><entry /><entry>struct ExchangeItem</entry></row><row><entry /><entry>{</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="4"><colspec colname="OFFSET" colwidth="14PT" align="left" /><colspec colname="1" colwidth="28PT" align="left" /><colspec colname="2" colwidth="49PT" align="left" /><colspec colname="3" colwidth="126PT" align="left" /><tbody valign="top"><row><entry /><entry> int</entry><entry>itemRef</entry><entry>see note below</entry></row><row><entry /><entry> int</entry><entry>itemType</entry><entry>see note below</entry></row><row><entry /><entry> string</entry><entry>dataSource</entry><entry>optional</entry></row><row><entry /><entry> string</entry><entry>dataTypeName</entry><entry>optional</entry></row><row><entry /><entry> string</entry><entry>recordID</entry><entry>optional</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="4"><colspec colname="OFFSET" colwidth="14PT" align="left" /><colspec colname="1" colwidth="28PT" align="left" /><colspec colname="2" colwidth="28PT" align="left" /><colspec colname="3" colwidth="147PT" align="left" /><tbody valign="top"><row><entry /><entry> string</entry><entry>jobID</entry><entry>optional - used by Get, Query & Query Result</entry></row><row><entry /><entry> int</entry><entry>result</entry><entry>optional - used to acknowledge changes</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="3"><colspec colname="OFFSET" colwidth="14PT" align="left" /><colspec colname="1" colwidth="56PT" align="left" /><colspec colname="2" colwidth="147PT" align="left" /><tbody valign="top"><row><entry /><entry> Value data</entry><entry>optional - type is any valid XML-RPC type</entry></row><row><entry /><entry>}</entry></row><row><entry /><entry namest="OFFSET" nameend="2" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0192ItemRef is a unique identifier that the server uses to reference an item it sends to the client. The client uses this value to acknowledge items it has received from the server. ItemRefs are a monotonically increasing sequence of integer values. The server maintains a sequence for each data type.

0193The device can also mark commands which it sends to the server with a monotonically increasing sequence of itemRef values. When a connection between the server and the device is interrupted, the server detects re-send commands by examine the itemRef values and ignores already received commands. The device maintains an itemRef sequence for each data type for which it supports commands with itemRef values. The device ensures that it sends according to data type for all or for non-commands an itemRef value.

0194In one approach, valid item types are listed below: <tables id="TABLE-US-00005" num="5"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="4"><colspec colname="OFFSET" colwidth="14PT" align="left" /><colspec colname="1" colwidth="49PT" align="left" /><colspec colname="2" colwidth="42PT" align="char" /><colspec colname="3" colwidth="112PT" align="left" /><thead><row><entry /><entry /></row><row><entry /><entry namest="OFFSET" nameend="3" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /><entry>Add</entry><entry>1</entry><entry /></row><row><entry /><entry>Replace</entry><entry>2</entry></row><row><entry /><entry>Delete</entry><entry>3</entry></row><row><entry /><entry>AddOrReplace</entry><entry>4</entry><entry>only valid from device to server</entry></row><row><entry /><entry>Map</entry><entry>5</entry><entry>not stored persistently</entry></row><row><entry /><entry>Get</entry><entry>6</entry></row><row><entry /><entry>Ack</entry><entry>7</entry><entry>not stored persistently</entry></row><row><entry /><entry>Ack All</entry><entry>8</entry><entry>not stored persistently</entry></row><row><entry /><entry>Query</entry><entry>9</entry></row><row><entry /><entry>Query Result</entry><entry>10</entry></row><row><entry /><entry>Query End</entry><entry>11</entry></row><row><entry /><entry>Clear</entry><entry>12</entry></row><row><entry /><entry>GetResult</entry><entry>15</entry></row><row><entry /><entry namest="OFFSET" nameend="3" align="center" rowsep="1" /></row></tbody></tgroup></table></tables><br /> Data contents: <ul id="ul0046" list-style="none"><li id="ul0046-0001" num="0000"><ul id="ul0047" list-style="none"><li id="ul0047-0001" num="0195"> Record content of the data—for adds and replaces </li><li id="ul0047-0002" num="0196"> NULL—for deletes unless additional information is required to perform the delete operation (as in some preference management cases) </li><li id="ul0047-0003" num="0197"> Record LUID—for maps </li></ul></li></ul>

0198Optional filter—for Query commands <tables id="TABLE-US-00006" num="6"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="OFFSET" colwidth="49PT" align="left" /><colspec colname="1" colwidth="168PT" align="left" /><thead><row><entry /><entry /></row><row><entry /><entry namest="OFFSET" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /><entry>struct ExchangeResult</entry></row><row><entry /><entry>{</entry></row><row><entry /><entry> int      result</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="4"><colspec colname="OFFSET" colwidth="49PT" align="left" /><colspec colname="1" colwidth="63PT" align="left" /><colspec colname="2" colwidth="35PT" align="left" /><colspec colname="3" colwidth="70PT" align="left" /><tbody valign="top"><row><entry /><entry> DataType[ ]</entry><entry>dataTypes</entry><entry>optional</entry></row><row><entry /><entry> ExchangeItem[ ]</entry><entry>items</entry><entry>optional</entry></row><row><entry /><entry>}</entry></row><row><entry /><entry namest="OFFSET" nameend="3" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0199The REx API is a flexible protocol for exchanging records or data. However, despite the flexibility built into the REx API, there will be situations where the core type definitions do not provide all of the required information. One way to resolve this issue is to define custom types based on the core type definitions that the API provides. This is handled since REx is based on XML-RPC. All of the structures defined in the REx API are transferred as structures in the XML-RPC format. XML-RPC structures can be viewed as a collection of name/value pairs. To extend a structure, a new name/value pair is added.

0200The REx API parser builds generic XML-RPC objects and passes them to marshaller functions that reside in protocol handler classes. The core REx API functions reside in a single protocol handler, but it is possible to define custom protocol handlers that inherit the entire core REx API functions while providing specialized functions for their own purposes. These specialized functions can marshal the parameters they receive and handle extended types appropriately. An example of an extended type is shown below: <tables id="TABLE-US-00007" num="7"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="OFFSET" colwidth="14PT" align="left" /><colspec colname="1" colwidth="203PT" align="left" /><thead><row><entry /><entry /></row><row><entry /><entry namest="OFFSET" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /><entry>struct DMExchangeItem extends ExchangeItem</entry></row><row><entry /><entry>{</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="3"><colspec colname="OFFSET" colwidth="14PT" align="left" /><colspec colname="1" colwidth="77PT" align="left" /><colspec colname="2" colwidth="126PT" align="left" /><tbody valign="top"><row><entry /><entry> string  dataTypeID</entry><entry>used to provide additional addressing</entry></row><row><entry /><entry /><entry>  information in the form of mapping</entry></row><row><entry /><entry /><entry>  information</entry></row><row><entry /><entry>}</entry></row><row><entry /><entry namest="OFFSET" nameend="2" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0201The above structure may be passed anywhere an ExchangeItem is expected, but functions that understand the DMExchangeItem type can also search and use the dataTypeID information.

0000Record Exchange Statuses and Result Codes

0202Table 2 defines the valid exchange statuses and result codes. Note that not all values listed are applicable in all cases. Consult the individual function definitions for the exact values that apply to each function. <tables id="TABLE-US-00008" num="8"><table frame="none" colsep="0" rowsep="0" pgwide="1"><tgroup align="left" colsep="0" rowsep="0" cols="6"><colspec colname="1" colwidth="21PT" align="center" /><colspec colname="2" colwidth="91PT" align="left" /><colspec colname="3" colwidth="35PT" align="center" /><colspec colname="4" colwidth="49PT" align="center" /><colspec colname="5" colwidth="42PT" align="center" /><colspec colname="6" colwidth="28PT" align="center" /><thead><row><entry namest="1" nameend="6" align="center">TABLE 2</entry></row><row><entry /></row><row><entry namest="1" nameend="6" align="center" rowsep="1" /></row><row><entry /><entry /><entry /><entry>Device to</entry><entry>Server to</entry><entry /></row><row><entry /><entry /><entry>Device to</entry><entry>server</entry><entry>device data</entry></row><row><entry /><entry /><entry>server</entry><entry>initRefresh data</entry><entry>type</entry></row><row><entry /><entry /><entry>acks item</entry><entry>type exchange</entry><entry>exchange</entry><entry>Overall</entry></row><row><entry /><entry /><entry>result</entry><entry>status</entry><entry>status</entry><entry>result</entry></row><row><entry namest="1" nameend="6" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry>200</entry><entry>OK (generic successful result)</entry><entry>x</entry><entry /><entry>x</entry><entry>x</entry></row><row><entry>201</entry><entry>OK (records pending); the</entry><entry /><entry /><entry>x</entry></row><row><entry /><entry>server is not forced to send</entry></row><row><entry /><entry>201 even when it has changes</entry></row><row><entry>250</entry><entry>Exchange refresh (client will</entry><entry /><entry>x</entry></row><row><entry /><entry>be restored from data source</entry></row><row><entry /><entry>records)</entry></row><row><entry>300</entry><entry>The device is in the zombie</entry><entry /><entry /><entry /><entry>x</entry></row><row><entry /><entry>mode</entry></row><row><entry>400</entry><entry>Bad request (generic request</entry><entry>x</entry><entry /><entry>x</entry><entry>x</entry></row><row><entry /><entry>error)</entry></row><row><entry>401</entry><entry>Unknown external user ID</entry><entry /><entry /><entry /><entry>x</entry></row><row><entry /><entry>(this overall error code is only</entry></row><row><entry /><entry>valid for devices which do not</entry></row><row><entry /><entry>use the security servlet to send</entry></row><row><entry /><entry>the request to the server)</entry></row><row><entry>404</entry><entry>Unknown data type</entry><entry>x</entry><entry /><entry>x</entry></row><row><entry>410</entry><entry>The server does not support</entry><entry /><entry /><entry /><entry>x</entry></row><row><entry /><entry>the client protocol version</entry></row><row><entry>417</entry><entry>Refresh required (e.g. sync</entry><entry /><entry /><entry>x</entry></row><row><entry /><entry>anchor mismatch)</entry></row><row><entry>420</entry><entry>Device full (the device ran out</entry><entry>x</entry></row><row><entry /><entry>of memory/“disk” space/. . .)</entry></row><row><entry>421</entry><entry>Temporary error, retry later</entry><entry>x</entry></row><row><entry>422</entry><entry>Command for a non-existing</entry><entry>x</entry></row><row><entry /><entry>item received</entry></row><row><entry>423</entry><entry>Servers requires itemRef</entry><entry /><entry /><entry>x</entry></row><row><entry /><entry>values for commands from</entry></row><row><entry /><entry>device to server and device-</entry></row><row><entry /><entry>sent commands without</entry></row><row><entry /><entry>itemRef values</entry></row><row><entry>500</entry><entry>Generic temporary server</entry><entry /><entry /><entry /><entry>x</entry></row><row><entry /><entry>error</entry></row><row><entry namest="1" nameend="6" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0203In one approach, the requests and their corresponding structures and responses that are used to inform the CLS about error situations are described below. The structures are also used to clear the errors when the error situations no longer exist.

0204The ErrorMessage structure is sent as a parameter to the raiseError and closeError requests. Not all members are set for all errors and all request methods. For each error and request method, the members are defined as unused, optional and mandatory. Note that the number in brackets after a member defines the maximum length of a member. <tables id="TABLE-US-00009" num="9"><table frame="none" colsep="0" rowsep="0" pgwide="1"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="266PT" align="left" /><thead><row><entry /></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry>struct ErrorMessage</entry></row><row><entry>{</entry></row><row><entry>// Location of the problem</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="91PT" align="left" /><colspec colname="2" colwidth="175PT" align="left" /><tbody valign="top"><row><entry>String databaseID[64];</entry><entry>// the id of a database for Rex or the</entry></row><row><entry /><entry>// SetEx database name for SetEx. Otherwise</entry></row><row><entry /><entry>// not set.</entry></row><row><entry>String dataItemID[128];</entry><entry>// the global ID of the Rex data item or</entry></row><row><entry /><entry>// the setting path for SetEx. Otherwise</entry></row><row><entry /><entry>// not set.</entry></row><row><entry>String taskID[64];</entry><entry>// the ID of the task in which the problem</entry></row><row><entry /><entry>// occured.</entry></row><row><entry>// User information</entry></row><row><entry>String whereDisplay[128];</entry><entry>// the display string in the client</entry></row><row><entry /><entry>// language to show the user where the</entry></row><row><entry /><entry>// problem occurred.</entry></row><row><entry>String whatDisplay[2048];</entry><entry>// the display string in the client</entry></row><row><entry /><entry>// language to show what went wrong.</entry></row><row><entry>String when;</entry><entry>// When did the problem happen (UTC time)</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="266PT" align="left" /><tbody valign="top"><row><entry>// Component location - where is the component that</entry></row><row><entry>// detected the problem</entry></row><row><entry>String machineDisplayName[64];  // human readable name of the machine.</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="91PT" align="left" /><colspec colname="2" colwidth="175PT" align="left" /><tbody valign="top"><row><entry /><entry>// If more than one deployment may run</entry></row><row><entry /><entry>// on this machine, be as specific as</entry></row><row><entry /><entry>// possible to identify this instance.</entry></row><row><entry>String componentName[64];</entry><entry>// the name of the software component that</entry></row><row><entry /><entry>// detected the problem. This is</entry></row><row><entry /><entry>// information for the developer. The</entry></row><row><entry /><entry>// component version may be included.</entry></row><row><entry>String exception[2048];</entry><entry>// the exception that causes the problem.</entry></row><row><entry>String context[2048];</entry><entry>// the reason why the error is detected or</entry></row><row><entry /><entry>// if possible the reason of the problem</entry></row><row><entry /><entry>// itself. Also any additional information</entry></row><row><entry /><entry>// to find the problem reason can be added</entry></row><row><entry /><entry>// here.</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="266PT" align="left" /><tbody valign="top"><row><entry>// Programmatic information to handle the bug in the error</entry></row><row><entry>// dispatching and view system</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="91PT" align="left" /><colspec colname="2" colwidth="175PT" align="left" /><tbody valign="top"><row><entry>String messageID[64];</entry><entry>// a worldwide unique ID for every error</entry></row><row><entry /><entry>// message. This is the reference if you</entry></row><row><entry /><entry>// close a message or resend it and it</entry></row><row><entry /><entry>// may not show up twice.</entry></row><row><entry>String userAction[32];</entry><entry>// One of the NO_ACTION, VIEW_ACTION,</entry></row><row><entry /><entry>// TAKE_ACTION or IMMEDIATE_TAKE_ACTION.</entry></row><row><entry>int errorID;</entry><entry>// One of the predefined errors ids. The</entry></row><row><entry /><entry>// error category is part of the upper</entry></row><row><entry /><entry>// bits.</entry></row><row><entry>}</entry></row><row><entry namest="1" nameend="2" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0205As response to all requests, the Error Response structure is returned to the calling device. <tables id="TABLE-US-00010" num="10"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="3"><colspec colname="OFFSET" colwidth="14PT" align="left" /><colspec colname="1" colwidth="70PT" align="left" /><colspec colname="2" colwidth="133PT" align="left" /><thead><row><entry /><entry /></row><row><entry /><entry namest="OFFSET" nameend="2" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /><entry>struct ErrorResponse {</entry><entry /></row><row><entry /><entry>int status;</entry><entry>// the status of the executed request.</entry></row><row><entry /><entry>String message;</entry><entry>// A general message field which is e.g.</entry></row><row><entry /><entry /><entry>// used to transport error messages for</entry></row><row><entry /><entry /><entry>// developers.</entry></row><row><entry /><entry>}</entry></row><row><entry /><entry namest="OFFSET" nameend="2" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0206As response to each request, the CLS returns the outcome of the request by setting the status member in the response structure. The values for the status member are: <tables id="TABLE-US-00011" num="11"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="3"><colspec colname="1" colwidth="112PT" align="left" /><colspec colname="2" colwidth="21PT" align="center" /><colspec colname="3" colwidth="84PT" align="left" /><thead><row><entry namest="1" nameend="3" align="center">TABLE 3</entry></row><row><entry /></row><row><entry namest="1" nameend="3" align="center" rowsep="1" /></row><row><entry>Name</entry><entry>Value</entry><entry>Description</entry></row><row><entry namest="1" nameend="3" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry>OK</entry><entry>200</entry><entry>CLS executed the request</entry></row><row><entry /><entry /><entry>without a problem.</entry></row><row><entry>BAD_REQUEST</entry><entry>400</entry><entry>CLS was not able to</entry></row><row><entry /><entry /><entry>understand the request at</entry></row><row><entry /><entry /><entry>all. This may not happen</entry></row><row><entry /><entry /><entry>and is a hint to a client bug.</entry></row><row><entry>INVALID_ARGUMENT</entry><entry>402</entry><entry>A mandatory member of</entry></row><row><entry /><entry /><entry>the ErrorMessage structure</entry></row><row><entry /><entry /><entry>is missing or one member</entry></row><row><entry /><entry /><entry>of the ErrorMessage</entry></row><row><entry /><entry /><entry>structure was set with</entry></row><row><entry /><entry /><entry>an invalid value e.g. the</entry></row><row><entry /><entry /><entry>string is too long. The</entry></row><row><entry /><entry /><entry>message field will hold the</entry></row><row><entry /><entry /><entry>name of the invalid field.</entry></row><row><entry>TEMPORARY_SERVER_ERROR</entry><entry>500</entry><entry>CLS has a temporary</entry></row><row><entry /><entry /><entry>problem. The device may</entry></row><row><entry /><entry /><entry>retry the request with an</entry></row><row><entry /><entry /><entry>increasing delay.</entry></row><row><entry namest="1" nameend="3" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0207The raiseError call is used to inform the CLS that an error has occurred on the device. The Error Response request takes an ErrorMessage structure as argument where different members are set according to the error type. As a result, an Error Response structure is returned. <ul id="ul0048" list-style="none"><li id="ul0048-0001" num="0000"><ul id="ul0049" list-style="none"><li id="ul0049-0001" num="0208"> Error Response raiseError(ErrorMessage) </li></ul></li></ul>

0209The closeError request clears the error that is reported by a previous raiseError request. Only the messageID member of the ErrorMessage structure is used for the closeError request. When the CLS receives the request, it clears a previous reported error with the same messageID. <ul id="ul0050" list-style="none"><li id="ul0050-0001" num="0000"><ul id="ul0051" list-style="none"><li id="ul0051-0001" num="0210"> Error Response closeError(ErrorMessage) <br /> Record Exchange Functions </li></ul></li></ul>

0211This section describes the functions in the Record Exchange API. For the functions that modify parameters passed to them, the following convention is used:

0212→ a right-pointing arrow indicates that value is set by the client and not modified by the server

0213← a left-pointing arrow indicates that server does not read the value sent by the client but will return a value

0214<img file="US2007016632A1_D0001.tif" /> a bi-directional arrow indicates that server both reads the client's value and returns a possibly updated value

0215The pre-exchange functions of the record exchange API include checkSyncAnchors, initRefresh, and queryChanges. Descriptions of the pre-exchange functions, their corresponding formats and parameters are provided below.

0216checkSyncAnchors: A client calls this function with both anchors for the data type inside the DataType structure to verify that one of the two sync anchors matches the server anchor. If a sync anchor check fails for a given data type, then the server will return a refresh-required result. The sync anchor values stored on the server will not be modified.

0217ExchangeResult checkSyncAnchors(DataType[ ] dataTypes)

0218Parameters:

0219dataTypes—an array indicating which data types to use in the check: <ul id="ul0052" list-style="none"><li id="ul0052-0001" num="0000"><ul id="ul0053" list-style="none"><li id="ul0053-0001" num="0220"> → dataTypeName </li><li id="ul0053-0002" num="0221"> → syncAnchor—the current device sync anchor for this data type. </li><li id="ul0053-0003" num="0222"> → pendingSyncAnchor—the pending anchor for this data type. </li></ul></li></ul>

0223Returns: an ExchangeResult which contains a DataType array with the appropriate exchangeStatus specified for each DataType. <ul id="ul0054" list-style="none"><li id="ul0054-0001" num="0000"><ul id="ul0055" list-style="none"><li id="ul0055-0001" num="0224"> ← result—<b>200</b> (OK) when the server has successfully processed the request, or a defined error code. </li><li id="ul0055-0002" num="0225"> ← dataTypes holds the exchangeStatus for the data types—<b>200</b> (OK), <b>201</b>, or a defined error code. <br /> initRefresh: If the client determines, or has been told by the server, that a refresh is required, then it calls initRefresh to begin the refresh process. </li></ul></li></ul>

0226ExchangeResult initRefresh(DataType[ ] dataTypes)

0227Parameters:

0228dataTypes—an array indicating which dataTypes to use in the initialization: <ul id="ul0056" list-style="none"><li id="ul0056-0001" num="0000"><ul id="ul0057" list-style="none"><li id="ul0057-0001" num="0229"> → dataTypeName, </li><li id="ul0057-0002" num="0230"> → exchangeStatus—<b>250</b> (Exchange refresh), </li><li id="ul0057-0003" num="0231"> → syncAnchor—the new anchor for this data type. </li></ul></li></ul>

0232Returns: an ExchangeResult populated as follows: <ul id="ul0058" list-style="none"><li id="ul0058-0001" num="0000"><ul id="ul0059" list-style="none"><li id="ul0059-0001" num="0233"> ← result—<b>200</b> (OK) when the server has successfully processed the request, or a defined error code. </li><li id="ul0059-0002" num="0234"> ← dataTypes indicates the init status for each data type specified in the original call: <b>200</b> (OK), <b>201</b>, or a defined error code. <br /> queryChanges: This function is used for cases where a client wants to poll the server for any pending changes, perhaps to provide user feedback, prior to performing an exchange. </li></ul></li></ul>

0235ExchangeResult queryChanges(DataType[ ] dataTypes)

0236Parameters:

0237dataTypes—an array defining which dataTypes to use for the change query. Sending an empty data type array will query changes for all data types. <ul id="ul0060" list-style="none"><li id="ul0060-0001" num="0000"><ul id="ul0061" list-style="none"><li id="ul0061-0001" num="0238"> → dataTypeName </li></ul></li></ul>

0239Returns: an ExchangeResult populated as follows: <ul id="ul0062" list-style="none"><li id="ul0062-0001" num="0000"><ul id="ul0063" list-style="none"><li id="ul0063-0001" num="0240"> ← result—either <b>200</b> (OK) when the server has successfully processed the request, or a defined error code. </li><li id="ul0063-0002" num="0241"> ← dataTypes indicates which DataTypes have pending changes on the server. If the caller passes an empty dataTypes parameter, then the data type's array result will contain only the data types for which changes exist on the server. If the caller passes a non-empty dataTypes parameter, then the same array will be returned with <b>200</b> (no changes), <b>201</b> (records pending), or <b>417</b> exchange status specified for each data type. </li></ul></li></ul>

0242The post-exchange functions of the record exchange API include ackItems, putItems, and ackAndPutItems. Descriptions of the post-exchange functions, their corresponding formats and parameters are provided below.

0243ackItems: After receiving items from the server, a client returns an acknowledgement to the server. This informs the server of the arrival status of each record, thereby allowing the server to efficiently manage its cache of the client's data. In one implementation, this function uses an array of ExchangeItems, which is what the server returns to the client in the various getItems calls. The client only needs to specify the itemRef and result members of each ExchangeItem. Another way to use this function is to send an ExchangeItem with itemType set to Ack All, dataType set according to the group of items being acknowledged, and itemRef set to the last item successfully processed for that dataType. The server interprets this as a successful acknowledgement for all items of that dataType whose itemRef is less than or equal to the specified itemRef value. Note that it is possible to send multiple ExchangeItems this way. All individual ack items are included before ack-all-items in the itemAcks parameter.

0244ExchangeResult ackItems(ExchangeItem[ ]itemAcks)

0245Parameters:

0246itemAcks—an array of ExchangeItems containing information about the items being acknowledged. The requirements for the itemAcks are as follows: <tables id="TABLE-US-00012" num="12"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="4"><colspec colname="OFFSET" colwidth="14PT" align="left" /><colspec colname="1" colwidth="63PT" align="left" /><colspec colname="2" colwidth="63PT" align="left" /><colspec colname="3" colwidth="77PT" align="left" /><thead><row><entry /><entry namest="OFFSET" nameend="3" align="center">TABLE 4</entry></row><row><entry /><entry /></row><row><entry /><entry namest="OFFSET" nameend="3" align="center" rowsep="1" /></row><row><entry /><entry>ExchangeItem</entry><entry>Requirements for</entry><entry>Requirements for Ack</entry></row><row><entry /><entry>member</entry><entry>Ack</entry><entry>All</entry></row><row><entry /><entry namest="OFFSET" nameend="3" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /><entry>itemRef</entry><entry>Yes</entry><entry>Yes</entry></row><row><entry /><entry>itemType</entry><entry>Yes</entry><entry>Yes</entry></row><row><entry /><entry>result</entry><entry>Yes</entry><entry>Optional (200)</entry></row><row><entry /><entry>dataTypeName</entry><entry>Yes</entry><entry>Yes</entry></row><row><entry /><entry>all others</entry><entry>Maybe</entry><entry>Maybe</entry></row><row><entry /><entry namest="OFFSET" nameend="3" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0247Returns: an ExchangeResult populated as follows: <ul id="ul0064" list-style="none"><li id="ul0064-0001" num="0000"><ul id="ul0065" list-style="none"><li id="ul0065-0001" num="0248"> ← result—either <b>200</b> (OK) when the server has successfully processed the request, or a defined error code. </li><li id="ul0065-0002" num="0249"> ← DataTypes—a dataType structure array; each element is holding the exchangeStatus: <b>200</b>) or a defined error code. <br /> putItems: This function allows the client to send a number of items to the server. </li></ul></li></ul>

0250ExchangeResult putItems(DataType[ ] dataTypes, ExchangeItem[ ] items):

0251Parameters:

0252DataType—the device sends for all dataTypes which are used in the items array from this request a new sync anchor. <ul id="ul0066" list-style="none"><li id="ul0066-0001" num="0000"><ul id="ul0067" list-style="none"><li id="ul0067-0001" num="0253"> → dataTypeName </li><li id="ul0067-0002" num="0254"> → syncAnchor—the new anchor for this data type. </li></ul></li></ul>

0255items—an array of ExchangeItems containing the records to be sent to the server.

0256Returns: an ExchangeResult populated as follows: <ul id="ul0068" list-style="none"><li id="ul0068-0001" num="0000"><ul id="ul0069" list-style="none"><li id="ul0069-0001" num="0257"> ← result—<b>200</b> (OK) when the server has successfully processed the request, or a defined error code. </li><li id="ul0069-0002" num="0258"> ← dataTypes—a DataType structure array for the data types in the request; each element is holding the exchangeStatus: <b>200</b>, <b>201</b>, or a defined error code. <br /> ackAndPutItems: This function is similar to the putItems with the addition of a parameter that allows the client to acknowledge received items before putting new ones. </li></ul></li></ul>

0259ExchangeResult ackAndPutItems(ExchangeItem[ ] acks, DataType[ ] dataTypes, ExchangeItem[ ] items)

0260Parameters—similar to putItems, with the addition of the following:

0261acks—contains acknowledgement information for specific ExchangeItems. The server will process these acks before accepting records from the client. See the ackItems function description for more information.

0262Returns: same as putItems.

0263getItems: The client calls this function to retrieve pending records for one or more data types. This is a common method of retrieving records from the server. The itemRef value for each data type allows the server to determine which records in the item cache the client has already received and which ones still need to be sent. The client may send in this field the last processed itemRef.

0264ExchangeResult getItems(DataType[ ] dataTypes, int limit)

0265Parameters:

0266dataTypes—an array of DataType structures that inform the server which data types to sync and at which point in the item cache to begin sending records. The DataType items are passed as follows: <ul id="ul0070" list-style="none"><li id="ul0070-0001" num="0000"><ul id="ul0071" list-style="none"><li id="ul0071-0001" num="0267"> → dataTypeName—the name of the data type. </li><li id="ul0071-0002" num="0268"> → syncAnchor—the new anchor for this data type. </li></ul></li></ul>

0269The server will ignore requests for getItems when the DataType array contains no element.

0270limit—this is an optional parameter that specifies the maximum size of the uncompressed response XML-RPC message. If this value is omitted, then the server will use a limit value that it deems to be reasonable.

0271Returns: an ExchangeResult that is populated as follows: <ul id="ul0072" list-style="none"><li id="ul0072-0001" num="0000"><ul id="ul0073" list-style="none"><li id="ul0073-0001" num="0272"> ← result-<b>200</b> (OK) when the server has successfully processed the request, or a defined error code. </li><li id="ul0073-0002" num="0273"> ← dataTypes—contains DataType structures for each of the data types from the request that have items ready to be retrieved. It is populated as follows: </li><li id="ul0073-0003" num="0274"> ← dataTypeName </li><li id="ul0073-0004" num="0275"> ← exchangeStatus—either <b>200</b> (OK), <b>201</b>, or a defined error code. </li><li id="ul0073-0005" num="0276"> ← items—contains the pending records, populated as follows: </li><li id="ul0073-0006" num="0277"> ← itemRef </li><li id="ul0073-0007" num="0278"> ← itemType </li><li id="ul0073-0008" num="0279"> ← recordID—is a temporary LUID for add items, a client LUID for all other item types. </li><li id="ul0073-0009" num="0280"> ← dataTypeName </li><li id="ul0073-0010" num="0281"> ← data—is omitted for delete items. <br /> ackAndGetItems: This function is similar to getItems with the addition of a parameter that allows the client to acknowledge received items while getting new ones. </li></ul></li></ul>

0282ExchangeResult ackAndGetItems(ExchangeItem[ ]acks, DataType[ ] dataTypes, int limit)

0283Parameters:

0284acks—contains acknowledgement information for specific ExchangeItems. The server will process these acks before retrieving records from the item cache. See the ackItems function description for more information.

0285<figref idref="DRAWINGS">FIG. 16</figref> illustrates a flow diagram of interactions between a user device and a server using the different REx methods.

0000Record Exchange Item Types

0286As a response to the getItems or ackAndGetItems request, the server may return a Clear command. This command has no data content and forces the device to remove all items for the given data type name.

0287In some situations, such as importing client device PIM data as part of the initial sync or fetching shadow data from a dataSource, the server can return a Query command to the device to force the device to upload the data for the given data type to the server.

0288<figref idref="DRAWINGS">FIG. 17</figref> illustrates a sequence diagram for a query process according to an embodiment of the present invention. In step <b>1</b>, the device calls the getItems method to request information from the server. In response to a getItems or ackAndGetItems request, the server returns a Query command. In the ExchangeItem of the command, thejobID field is set and marks this query. An optional data field may contain a filter to restrict the query. When no filter is given, the device will return all items for the given data type. An example of ExchangeItem for a Query command is shown below: <tables id="TABLE-US-00013" num="13"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="OFFSET" colwidth="35PT" align="left" /><colspec colname="1" colwidth="182PT" align="left" /><thead><row><entry /><entry /></row><row><entry /><entry namest="OFFSET" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /><entry>struct ExchangeItem {</entry></row><row><entry /><entry> itemRef = 222</entry></row><row><entry /><entry> itemType = 9   // Query</entry></row><row><entry /><entry> dataTypeName = contacts</entry></row><row><entry /><entry> jobID  = e2f28cee570111d89d7fac1000270000</entry></row><row><entry /><entry>}</entry></row><row><entry /><entry namest="OFFSET" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0289In step <b>2</b>, the device calls ackitems to acknowledge that it has received the Query command. In step <b>3</b>, the device collects the queried data. In step <b>4</b>, the device sends the data to the server using putItems. Each queried item is sent as one QueryResult. After all QueryResult items are sent, one QueryEnd item is sent which marks that the data upload for the query is done. All QueryResult and QueryEnd items have the jobID field set to the job ID from the query to indicate that these items are related to the query with this jobID. An example of QueryResult and the final QueryEnd ExchangeItem is shown below: <tables id="TABLE-US-00014" num="14"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="OFFSET" colwidth="35PT" align="left" /><colspec colname="1" colwidth="182PT" align="left" /><thead><row><entry /><entry /></row><row><entry /><entry namest="OFFSET" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /><entry>struct ExchangeItem {</entry></row><row><entry /><entry> itemType = 10   // QueryResult</entry></row><row><entry /><entry> dataTypeName = contacts</entry></row><row><entry /><entry> jobID  = e2f28cee570111d89d7fac1000270000</entry></row><row><entry /><entry> data = <contact class=“PUBLIC”>...</contact></entry></row><row><entry /><entry> recorded = BB0gAA==  // LUID</entry></row><row><entry /><entry>}</entry></row><row><entry /><entry>struct ExchangeItem {</entry></row><row><entry /><entry> itemType = 11  // QueryEnd</entry></row><row><entry /><entry> dataTypeName = contacts</entry></row><row><entry /><entry> jobID  = e2f28cee570111d89d7fac1000270000</entry></row><row><entry /><entry>}</entry></row><row><entry /><entry namest="OFFSET" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0290When the result for the query is too large for one putItems call, the device may use multiple putItems to upload the items to the server. The final QueryEnd command is sent only in the last putItems call.

0291When the device restarts after step <b>2</b>, for example after a device crash, after a user turned off the device, or after replacement of a dead battery, it continues with the query. Since the device has already acknowledged the Query command, the server will not resend this command. Therefore the device makes this command persistent to survive the restart. To avoid this situation, the device may acknowledge the Query command by calling ackAndPutItems in step <b>4</b>.

0292Note that the server may set a filter as part of the Query command using the data field. In one implementation, the server only uses the string {partial} as filter for dataSources. This filter informs the dataSource to return only shadow information for the queried items. This will reduce the amount of uploaded data. When the server needs the complete item, it will send a Get command to fetch it.

0293When the server requests for the shadow information (through the partial filter), the dataSource returns this information for the different type of data, such as mail, contact, task, and event items.

0294A Get command requests the device, by specifying a LUID, to upload the specified item to the server using putItems. Below is an example of ExchangeItem for a Get command: <tables id="TABLE-US-00015" num="15"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="OFFSET" colwidth="14PT" align="left" /><colspec colname="1" colwidth="203PT" align="left" /><thead><row><entry /><entry /></row><row><entry /><entry namest="OFFSET" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /><entry>struct ExchangeItem {</entry></row><row><entry /><entry> itemRef = 392</entry></row><row><entry /><entry> itemType = 6       // Get</entry></row><row><entry /><entry> dataTypeName = AAAAANWXbwt76SlDtJeWirnVnshCgQAA</entry></row><row><entry /><entry> recordID = RDIgAA==   // LUID</entry></row><row><entry /><entry> jobID   = 3a2f1bee57c111d8ae44ac1000270000</entry></row><row><entry /><entry>}</entry></row><row><entry /><entry namest="OFFSET" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0295The device sends the item back using a GetResult. A job ID is used to connect the Get and the GetResult: <tables id="TABLE-US-00016" num="16"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="OFFSET" colwidth="14PT" align="left" /><colspec colname="1" colwidth="203PT" align="left" /><thead><row><entry /><entry /></row><row><entry /><entry namest="OFFSET" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /><entry>struct ExchangeItem {</entry></row><row><entry /><entry> itemType = 15      // Get Result</entry></row><row><entry /><entry> dataTypeName = AAAAANWXbwt76SlDtJeWirnVnshCgQAA</entry></row><row><entry /><entry> recordID = RDIgAA==   // LUID</entry></row><row><entry /><entry> jobID   = 3a2f1bee57c111d8ae44ac1000270000</entry></row><row><entry /><entry> data = ...</entry></row><row><entry /><entry>}</entry></row><row><entry /><entry namest="OFFSET" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0296Note that like the query case the device uses ackAndPutItems to acknowledge the Get command and to send the requested item in one call to the server, or the device makes the result of the Get command persistent. When the device receives a Get for a non-existing item, it acknowledges the item with the <b>422</b> status code.

0297A QueryResult command is used by the device in the result of a query and as a response to a Get command. When a dataSource detects a new item, it sends an Add command to the server. When the dataSource detects a huge amount of new items (e.g. a new email folder with thousands of emails copied into the dataSource), it sends a QueryResult command for each new item containing only the shadow information. Upon sending the last piece of information of the QueryResult command, a QueryEnd command is sent to inform the server that the upload has finished. The server will send Get commands when it needs the complete information of one item. This reduces the amount of data send for such cases.

0000Synchronizing Server and Devices

0298The connected-life server (CLS) optimizes the synchronization of data between the server and the one or more user devices. Specifically, the CLS creates a backup of the connected-data-set at the server according to a predetermined backup interval. It then generates a checkpoint marker for tracking the time intervals when the backup of the connected-data-set is created and sends the checkpoint marker to the one or more user devices for maintaining a first record of changes to the connected-data-set.

0299To determine whether the server and the one or more user devices are out of synchronization, the CLS detects a replacement of the server or a crash of the server. Alternatively, the CLS may execute a session-based syncML protocol or a sync anchor protocol (described below) to determine whether the server and the user devices are out of synchronization. Upon determining the server and the one or more user devices are out of synchronization, the CLS restores the backup data of the connected-data-set at the server. Next, it requests the first record of changes of the connected-data-set from the one or more user devices using the checkpoint marker. It determines first portions of the connected-data-set that have changes after the checkpoint marker according to the first record of changes of the connected-data-set from the one or more user devices. This is done by comparing portions of the connected-data-set that have newer timestamps after the checkpoint marker between the one or more user devices and the server. It then updates the first portions of the connected-data-set that have changes by executing transactions of the first record of changes at the server.

0300Similarly, upon determining the server and a backend database are out of synchronization, the CLS restores the backup data of the connected-data-set at the server. Next, it requests the second record of changes of the connected-data-set from the backend database using the checkpoint marker. It determines second portions of the connected-data-set that have changes after the checkpoint marker according to the second record of changes of the connected-data-set from the backend database. This is done by comparing portions of the connected-data-set that have newer timestamps after the checkpoint marker between the backend database and the server. It then updates the second portions of the connected-data-set that have changes by executing transactions of the second record of changes at the server.

0301The primary purpose of the sync anchor protocol is to detect that the device and the server ran out of synchronization for exchange items. The client device has the responsibility to synchronize with the server. However, there is at least one scenario that cannot be detected by the client alone. Considering the following sequence of events: <ul id="ul0074" list-style="none"><li id="ul0074-0001" num="0000"><ul id="ul0075" list-style="none"><li id="ul0075-0001" num="0302"> Client and server are in Sync at point A. </li><li id="ul0075-0002" num="0303"> Client and server later are in sync at point B, and the actual dataset is different than at point A. </li><li id="ul0075-0003" num="0304"> The user does a system restore of the whole device image, including all data, configuration files, etc. </li><li id="ul0075-0004" num="0305"> The client may be started, but when it checks its local data, it sees a consistency because it is at point B. However, it is inconsistent (not in-sync) with the server, which assumes the device being at point B. </li></ul></li></ul>

0306This issue is addressed by the REx sync anchor protocol. Based on the sync anchors, the server can verify and inform the client that it is not in-sync anymore. This is done for each database to minimize the traffic for transferring data that need to be refreshed. For each type of exchange item, the device maintains two anchors. One is the current anchor for the type of exchange item. When the device requests or sends data from or to the server, it generates a new anchor and sends this data in the request. When the request ends without an error, the device knows that the server has received the new anchor successfully. In this case the device stores the new anchor as the current anchor.

0307When a client initiates a communication with the server, it calls the checkSyncAnchors method to check whether the device and server anchor match. If not, the device and server run out of sync for this type of exchange item.

0308<figref idref="DRAWINGS">FIG. 18</figref> illustrates a sync anchor protocol for synchronizing between a client device and a server according to an embodiment of the present invention. As shown in <figref idref="DRAWINGS">FIG. 18</figref>, the device maintains two sync anchors for each data type name. One is the current anchor, and when the device calls a method which sends or requests data, the device generates and sends a new sync anchor (the pending anchor) for each data type of the request to the server. A successful overall response implies that the server got and stored the new anchors for these data type names (even when the exchange status for a specify data type is not successful). In this case the device stores the new anchor for each data type as the current anchor. If the device gets no response or a response with an unsuccessful overall result code, it stores the pending anchor and resends it as the next new anchor.

0309The device calls checkSyncAnchors with the current anchor and optionally with the pending anchor if the pending anchor exists. When one anchor matches the server anchor, the device and the server are in sync. In this case and when there is a pending anchor, the device uses the previously sent current anchor as current anchor since it does not know whether the server has received the pending anchor, and sends the pending anchor as the next new anchor.

0310When the anchor check fails, the server returns an error status code <b>417</b>. The device sets back the anchor to the initial anchor, and calls initRefresh with a new anchor (not the initial anchor). Then, it calls getItems to determine whether the server has a Clear or Query command for the device. Next, the device optionally sends device-managed items through putItems to the server. Finally, the device calls getItems to retrieve the updated items from the server.

0311When a device (or one part of a device which is responsible for one data type name) starts, it first calls checkSyncAnchors to check whether the device and the server are still in sync. Note that methods like getItems or ackAndPutItems can also return a <b>417</b> exchange code for data types from the request. In this case the device acts as if a call for checkSyncAnchors has failed.

0312When the device starts the initial sync for a data type after installation or after an unknown data type <b>404</b> situation, it calls checkSyncAnchors with 0 as initial sync anchor. It is optional whether the device also sends the 0 as pending anchor. It is required that server and device are in sync for the initial sync.

0313The device calls getItems after the initial checkSyncAnchors call, and as result of the getItems call, a Clear or Query command is returned. The device activates the change detection when this initial command is processed.

0000Notifying User Devices Status of Communications

0314The CLS notifies a user status of communications between the server and the user. The user has one or more user devices that share portions of a connected-data-set maintained by the CLS. In one implementation, the CLS monitors communications between the server and the one or more user devices for a predetermined set of notification conditions. The set of predetermined notification conditions are formed according to information provided by the manufacturers and according to information gathered through actual usage of the one or more user devices. In addition, the set of predetermined notification conditions includes transmission failures of elements of the connected-data-set.

0315For example, the notification message may include a title of the communication that a notification condition is detected. The notification message may also include an abstract of the communication that a notification condition is detected. Furthermore, the notification message sent by the server to the device may include a hyperlink. This hyperlink may point to a web page that elaborates more on the nature of the notification, or it may even lead the user to a web page where he can solve the issue (for example, entering a new password to access a backend). This method is beneficial because normally only few items of information may be transported to the client device, and because it often requires many words to explain the nature of a notification. Also, the hyperlink provides a means for extensibility. In the notification message (or the menu of a notification screen or application), there may be an option to start a browser to load the web page behind this hyperlink.

0316When a notification condition is detected, the CLS sends a notification message to the one or more user devices. Note that in one implementation, the notification message may be sent to user devices that the predetermined set of notification conditions is detected. In another implementation, the notification message may be sent to user devices that the predetermined set of notification conditions is not detected.

0317In yet another implementation, the set of predetermined notification conditions may include email, task, calendar, and address book overflow conditions for the one or more user devices. In order to avoid device overflow, the server monitors and records the amount of data each device application may hold. The data is gathered either through information provided by the device manufacturers, for example, a user's manual may specify the address book of a device can hold a maximum of 500 contacts; or through testing of the user device, for example, the device refuses to store more than certain number of records sent by the server; or through actual usage, for example, certain calendar application still may work even if the number of events exceeds the predefined maximum number in the user's manual.

0318Based on the data gathered, the server can define a set of upper limits per device type or application in the server infrastructure. Since the server monitors the actual number of records on each device, it can stop sending more records to a device when the number of records on the device is approaching the predefined upper limit. For example, the server may keep the device 90% full to allow the user still do some useful work. In addition, the server may alert the user that a specific application (such as email or calendar) on the device has reached the predefined upper limit and request the user to take proactive actions, such as applying a different filter for the specific application to reduce the number of records on the device. In other approaches, different rules may be applied to different data types to manage the amount of records on a device. For instance, <ul id="ul0076" list-style="none"><li id="ul0076-0001" num="0000"><ul id="ul0077" list-style="none"><li id="ul0077-0001" num="0319"> Mail: higher priority is assigned to the new mails, which will always be sent to the device. If the device needs to make room for the new mails, the old mails will be deleted in the order from the oldest to the newest. </li><li id="ul0077-0002" num="0320"> Task: higher priority is assigned to the open tasks, the nearer the due date, the more important is the task. If the device needs to make room for the new tasks, the completed tasks will be deleted in the order from the oldest to the newest. </li><li id="ul0077-0003" num="0321"> Calendar: higher priority is assigned to events that will occur in the near future. In general, events in the future are more important than events in the past. If the device needs to make room for the new events, the past events will be deleted in the order from the oldest to the newest. </li><li id="ul0077-0004" num="0322"> Address book: higher priority is given to the ones that are already on the device. If the address book is full, the server will not deliver new addresses from other devices or from the backend to the device. <br /> Settings Exchange (SetEx) Protocol </li></ul></li></ul>

0323The Settings Exchange (SetEx) protocol is used to exchange the settings information between the device and the server. SetEx is supported by DPREx protocol with changes to the data structures. Similar to the DPREx protocol, the data content is an XML document holding the settings changes. The encoding of the XML data content document is always the same as the encoding of the XML-RPC envelope. The encoding is able to represent all Unicode characters. The SetEx protocol uses settings as base URL extension; for example, http://server:port/dp/settings is an example of a SetEx URL.

0000Settings Exchange Status Codes

0324SetEx uses the same status codes as DPREx. The status code <b>300</b> is returned when a device is in a zombie state and tries to put or get settings to or from the server. In this case the device first sends the device type identification. SetEx uses a new status code <b>405</b>. This code is returned as a response to a SetEx call in order to determine when the server requests to get settings from the device.

0000Settings Exchange Process Flow

0325In one embodiment, the process flow for settings exchange is described in three use cases: 1) initial settings exchange; 2) normal settings exchange; and 3) dump settings exchange.

0326During the initial settings exchange, the device identifies its device type to the server. This situation occurs when the device is connecting to the server for the first time. Note that this can happen when the user has bought a new device or when the device has been completely reset, or if the device state is reset to zombie on the server side. In all these situations the device starts by exchanging the device type identification settings. This enables the server to determine the true identity (correct device type identification information) of the device. There are two possible process flow scenarios. In the first case, the device thinks it is connecting to the server for the first time, and it exchanges the device type identification settings. In the second case, the device thinks it has been initialized (synced device type identification settings) while the server thinks otherwise. Both these cases are discussed in association with the sequence diagrams described in the following sections.

0327<figref idref="DRAWINGS">FIG. 19</figref> illustrates a process flow diagram when the device exchanges device type identification settings according to an embodiment of the present invention. As shown in <figref idref="DRAWINGS">FIG. 19</figref>, in step <b>1</b>, the device calls putItems to exchange device type identification settings. In step <b>1</b>.<b>1</b>, the server ends the device zombie state after properly identifying the device. In step <b>1</b>.<b>2</b>, the server builds a response by calling the buildExchangeResult method. The response contains server status to be sent to the device. If the device is already out of the zombie state when it receives the device type identification settings, this operation will have no effect.

0328<figref idref="DRAWINGS">FIG. 20</figref> illustrates a process flow diagram when the device tries to exchange settings other than device type identification in the zombie state according to an embodiment of the present invention. This situation occurs when the known state of the device on the server is in zombie state and the device is attempting to exchange normal application settings. As shown in <figref idref="DRAWINGS">FIG. 20</figref>, in step <b>1</b>, the device calls putItems to exchange normal settings. In this case the server rejects the device request with an error code <b>300</b>, which indicates that the device is in the zombie state. In step <b>2</b>, the device then calls putItems to exchange the device type identification settings that enable the server to confirm the identity of the device and end the zombie state.

0329In the case of normal settings exchange, the device exchanges settings for applications running on the device. In this scenario, the device is no longer in the zombie state and can perform normal settings exchange between the device and the server.

0330<figref idref="DRAWINGS">FIG. 21</figref> illustrates a sequence diagram for normal settings exchange according to an embodiment of the present invention. As shown in <figref idref="DRAWINGS">FIG. 21</figref>, in step <b>1</b>, if the device has changed settings, it sends them to the server using the putItems method call. It repeats this step as long as it has more settings to send.

0331If the device receives a notification from the server for pending settings changes available on the server, it issues a getItems call to retrieve the settings changes. Note that this step may be omitted if there are no pending settings available on the server for the device.

0332The device issues an ackAndGetItems method call if the server has flagged through the <b>201</b> data type status code that more settings changes exist. The device in this case acknowledges the settings received in the last response from the server and requests for the pending settings changes on the server.

0333Finally after all the settings changes have been fetched by the device from the server, it issues an ackitems call. The ackitems method enables the server to clean up any resources that are associated with the changed settings sent from the server.

0334In the process flow described above, there is no difference between updating settings. The major difference is the data content, although the operations are different. Note that: <ul id="ul0078" list-style="none"><li id="ul0078-0001" num="0000"><ul id="ul0079" list-style="none"><li id="ul0079-0001" num="0335"> 1. Delete with an empty settings document, deletes the whole database. </li><li id="ul0079-0002" num="0336"> 2. All settings and the sub-trees of those settings that are leaves in the delete data content document are deleted. </li><li id="ul0079-0003" num="0337"> 3. A setting marked as a node in the delete data content does not delete the sub-tree. </li></ul></li></ul>

0338For example, the existing tree is: <ul id="ul0080" list-style="none"><li id="ul0080-0001" num="0000"><ul id="ul0081" list-style="none"><li id="ul0081-0001" num="0339"> a/b/m </li><li id="ul0081-0002" num="0340"> a/b/n </li><li id="ul0081-0003" num="0341"> a/c/ </li></ul></li></ul>

0342To delete m and n, one may specify the sub-node. The SetEx data content for deleting m and n is: <tables id="TABLE-US-00017" num="17"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="OFFSET" colwidth="63PT" align="left" /><colspec colname="1" colwidth="154PT" align="left" /><thead><row><entry /><entry /></row><row><entry /><entry namest="OFFSET" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /><entry><Node name= “a”></entry></row><row><entry /><entry> <Leaf name= “b”></Leaf></entry></row><row><entry /><entry></Node></entry></row><row><entry /><entry namest="OFFSET" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables><ul id="ul0082" list-style="none"><li id="ul0082-0001" num="0000"><ul id="ul0083" list-style="none"><li id="ul0083-0001" num="0343"> Note that the sub-node b is specified as a leaf in the deleted data content. The resulting tree is: </li><li id="ul0083-0002" num="0344"> a/c </li></ul></li></ul>

0345It is uncommon to delete leaves. Also note that the interior nodes do not have semantic. From the above schema example the tree (a/c) is the same as (a/b, a/c), because b is an interior node and has no semantic. So deleting the leaf a/b/m and a/b/n is semantically the same as deleting a/b in the above example. Leaf node delete example: <tables id="TABLE-US-00018" num="18"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="OFFSET" colwidth="70PT" align="left" /><colspec colname="1" colwidth="147PT" align="left" /><thead><row><entry /><entry /></row><row><entry /><entry namest="OFFSET" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /><entry><Node name=“a”></entry></row><row><entry /><entry> <Node name=“b”></entry></row><row><entry /><entry>  <Leaf name=“m”></Leaf></entry></row><row><entry /><entry>  <Leaf name=“n”></Leaf></entry></row><row><entry /><entry> </Node></entry></row><row><entry /><entry></Node></entry></row><row><entry /><entry namest="OFFSET" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0346The resulting tree is: <ul id="ul0084" list-style="none"><li id="ul0084-0001" num="0000"><ul id="ul0085" list-style="none"><li id="ul0085-0001" num="0347"> a/c </li></ul></li></ul>

0348To simplify implementations, data content specs may define that deletes are allowed on specific sub-nodes. A data content restriction for the above example may be that only deletes on a/b are allowed, but not on a leaf.

0000Dump Settings Exchange

0349In the dump settings exchange case, the device issues a SetEx method call. The server determines that it likes to get all settings from the device. This method is primarily used for testing or checking that the device is in the state the server expects by getting all data from the device. When this happens, the server responds with a special error code <b>405</b>. In response to the error code, the device starts dumping the settings information pertaining to the data type that caused this.

0350<figref idref="DRAWINGS">FIG. 22</figref> illustrates a sequence diagram for dump settings according to an embodiment of the present invention. The device invokes the putItems call to exchange normal settings. If the server is in a state that requires the device to dump all known settings for certain data types, it returns a <b>405</b> code for the given data type. Note that this may also happen when the device initiates a getItems call.

0351The device calls initRefresh (code <b>251</b>) to notify the server that it has started a dump settings exchange. The device issues a putItems request in response to the dump required alert to be sent by the server. In this state, the device dumps all the settings it contains to the server. This step is repeated as long as the device has more settings that need to be dumped.

0000Settings Exchange Data Structures

0352This section describes enhancements to the core device proxy records exchange (DPREx) data structures. The ExchangeItem structure may be modified to support settings exchange. In particular, there are restrictions on what values are allowed in SetEx protocol for the itemType and recordID fields in ExchangeItem.

0353In one implementation, the itemType data structure supports Delete and Replace operations. In case of settings exchange, Replace is redefined to mean Add if the setting does not exist and update otherwise. The recordID field is omitted for settings exchange.

0354When a device requests for settings, but limits the message size to be less than a predefined size, the SetEx content is split to sizes less than the predefined size. Splitting is based on leaf nodes. For example, if the message size is set to 0, only one leaf node per request is transferred. It is often the case that the implementation is too complicated with this definition without any benefit. To simplify the implementation, it is possible to group settings on node level. An example of data content is shown as a/b/c, a/b/d, a/b/e, and a/m/c.

0355If grouping is enabled for a/b/, it is guaranteed that a/b/c, a/b/d, and a/b/e be transferred in one message, regardless of the message size. Note that this message can also contain other settings. It is up to the data content specification to define the settings.

0356The following sections show XML-RPC fragments that contain sample settings data content. In one implementation, the settings tree data content in the Data field of ExchangeItem are used for exchanging device type identification settings. There are six different device type identification settings used, and they are Mod, Hint1, Hint2, Hint3, Hint4, and Hint5. Here, Mod represents the device model and in most cases can be used to uniquely identify the device. Hint1 to Hint5 contain information to identify the device type, in addition to the information contained in the Mod string.

0357The following devTypeIdent XML schema defines which data is allowed. Note that the data type name for this case is s-devTypeIdent. <tables id="TABLE-US-00019" num="19"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="OFFSET" colwidth="28PT" align="left" /><colspec colname="1" colwidth="189PT" align="left" /><thead><row><entry /><entry /></row><row><entry /><entry namest="OFFSET" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /><entry></entry></row><row><entry /><entry><methodCall></entry></row><row><entry /><entry>  <methodName>putItems</methodName></entry></row><row><entry /><entry>  <params></entry></row><row><entry /><entry>   <param></entry></row><row><entry /><entry>    <value></entry></row><row><entry /><entry>     <array></entry></row><row><entry /><entry>      <data></entry></row><row><entry /><entry>       <value></entry></row><row><entry /><entry>        <struct></entry></row><row><entry /><entry>         <member></entry></row><row><entry /><entry>          <name>itemType</name></entry></row><row><entry /><entry>          <value></entry></row><row><entry /><entry>           <i4>2</i4></entry></row><row><entry /><entry>          </value></entry></row><row><entry /><entry>         </member></entry></row><row><entry /><entry>         <member></entry></row><row><entry /><entry>          <name>dataTypeName</name></entry></row><row><entry /><entry>          <value>s-devTypeIdent</value></entry></row><row><entry /><entry>         </member></entry></row><row><entry /><entry>         <member></entry></row><row><entry /><entry>          <name>data</name></entry></row><row><entry /><entry>          <value><![CDATA[<Settings></entry></row><row><entry /><entry> <Leaf name=“mod” format=“chr”>WinXP</Leaf></entry></row><row><entry /><entry></Settings></entry></row><row><entry /><entry>]]></value></entry></row><row><entry /><entry>         </member></entry></row><row><entry /><entry>        </struct></entry></row><row><entry /><entry>       </value></entry></row><row><entry /><entry>      </data></entry></row><row><entry /><entry>     </array></entry></row><row><entry /><entry>    </value></entry></row><row><entry /><entry>   </param></entry></row><row><entry /><entry>   <param></entry></row><row><entry /><entry>   <value></entry></row><row><entry /><entry>    <boolean>0</boolean></entry></row><row><entry /><entry>   </value></entry></row><row><entry /><entry>  </param></entry></row><row><entry /><entry> </params></entry></row><row><entry /><entry></methodCall></entry></row><row><entry /><entry namest="OFFSET" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0358The following shows example of a server response for a getItems call the settings tree data content for exchanging email folder settings. <tables id="TABLE-US-00020" num="20"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217PT" align="left" /><thead><row><entry /></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry><member></entry></row><row><entry> <name>data</name></entry></row><row><entry> <value><![CDATA[<Settings></entry></row><row><entry> <Node name=“Accounts”></entry></row><row><entry>  <Node name=“1”></entry></row><row><entry>   <Leaf name=“AccountID” format=“chr”>aAccountId</Leaf></entry></row><row><entry>   <Leaf name=“GUIName” format=“chr”>Markus Meyer</Leaf></entry></row><row><entry>   <Leaf name=“EMailAddress”</entry></row><row><entry>   format=“chr”>Markus @web.de</Leaf></entry></row><row><entry>   <Leaf name=“IsDefault” format=“bool”>true</Leaf></entry></row><row><entry>  </Node></entry></row><row><entry> </Node></entry></row><row><entry> <Node name=“Folders”></entry></row><row><entry>  <Node name=“1”></entry></row><row><entry>   <Leaf name=“FolderID” format=“chr”>aFolderId</Leaf></entry></row><row><entry>   <Leaf name=“AccountID” format=“chr”>aAccountId</Leaf></entry></row><row><entry>   <Leaf name=“FolderType” format=“int”>0</Leaf></entry></row><row><entry>   <Leaf name=“GUIName” format=“chr”>web.de Inbox</Leaf></entry></row><row><entry>   <Leaf name=“SortType” format=“int”>0</Leaf></entry></row><row><entry>  </Node></entry></row><row><entry>  <Node name=“2”></entry></row><row><entry>   <Leaf name=“FolderID” format=“chr”>aFolderId2</Leaf></entry></row><row><entry>   <Leaf name=“AccountID” format=“chr”>aAccountId</Leaf></entry></row><row><entry>   <Leaf name=“FolderType” format=“int”>2</Leaf></entry></row><row><entry>   <Leaf name=“GUIName” format=“chr”>todo</Leaf></entry></row><row><entry>   <Leaf name=“SortType” format=“int”>0</Leaf></entry></row><row><entry>  </Node></entry></row><row><entry> </Node></entry></row><row><entry></Settings></entry></row><row><entry>]]></entry></row><row><entry> </value></entry></row><row><entry></member></entry></row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0359In SetEx, the Clear command is not used as the very first command for cleaning up traces of a previous installation or database activation. Therefore, when the device performs the first sync for a SetEx data type (a checkSyncAnchors call with anchor 0), it initiates a cleanup process by itself. The same initial-sync rules apply when the server forces the device to perform an initRefresh call by returning the exchange status <b>417</b> to a SetEx request.

0000Settings Exchange Functions

0360This section contains the list of changed definitions of the DPREx functions, including getItems, putItems, ackItems, and initRefresh. For getItems and putItems, the following restrictions apply: the recordID field is not used, and only Replace and Delete are supported for the itemType field in the returned ExchangeItem instances. The Data field of the ExchangeItem contains the settings data content.

0361For ackItems, the following restrictions apply: the recordID field is not used, and only Ack and AckAll are supported for the itemType field in the returned ExchangeItem instances. The Data field is not used in this case.

0362The initRefresh method may be called by the device in two cases. First, it is used to notify the server that the device is going to start a dump of all settings known to the device in response to a server alert. This is performed by sending in a special exchange status ExchangeAll represented by status code <b>251</b> for each data type known to the device. Second, the device wants to retrieve all known settings on the server after a getItems call. The device does this by sending the status INIT_REFRESH represented by status code <b>251</b> for each data type.

0000Application Exchange Protocol

0363Application Exchange protocol is used to define the process of exchanging software changes between the device and the server. The application exchange functionality is quite different from record and settings exchange which necessitates defining a new protocol on top of XML_RPC. The protocol flow, data structures, and functions for Application Exchange (AppEx) software are described in the following sections. The AppEx protocol uses apps as base URL extension and uses the version number and external user ID as URL parameter. An example of AppEx URL is shown as http://www.verdisoft.com/dp/apps?extID=2347dhji34&amp;version=1.0.1.

0000Application Exchange Process Flow

0364<figref idref="DRAWINGS">FIG. 23</figref> illustrates a sequence diagram of an application exchange process flow between a device and a server according to an embodiment of the present invention. The sequence of steps in software exchange process flow of <figref idref="DRAWINGS">FIG. 23</figref> is described below: <ul id="ul0086" list-style="none"><li id="ul0086-0001" num="0000"><ul id="ul0087" list-style="none"><li id="ul0087-0001" num="0365"> 1) The device requests the server for available application changes. The server returns a list of setup information for all applications that have changes available. When the server has no software changes, the AppEx process ends. </li><li id="ul0087-0002" num="0366"> 2) The device processes the setup information and decides when to start executing the software changes. </li><li id="ul0087-0003" num="0367"> 3) The device initiates the application setup. The server responds with a list of setup commands for the device to execute. </li><li id="ul0087-0004" num="0368"> 4) The device processes the setup commands and downloads the files required for the application setup. When a file download fails, the device stops downloading the remaining files. It installs the successfully downloaded software and then uses the sequence deviceSetupStarts and deviceSetupEnds with the appropriate error code to inform the server that the download has failed. </li><li id="ul0087-0005" num="0369"> 5) The device informs the server that the application setup processes will start on the device. This information is used by the server to invalidate all old services associated with the software that has been changed on the device. The server may respond with the special status code <b>301</b> to force the device to start the whole process from the beginning by calling getApplicationUpdates. When one setup command fails, the device stops executing the remaining commands. </li><li id="ul0087-0006" num="0370"> 6) The device starts the application. </li><li id="ul0087-0007" num="0371"> 7) The application informs the server that it is installed. The server uses this call to schedule settings for the device. </li><li id="ul0087-0008" num="0372"> 8) The device fetches settings necessary from the server. </li><li id="ul0087-0009" num="0373"> 9) The application informs the server through an optional request that it is ready for a self-test. The server activates some predefined test data for this application. </li><li id="ul0087-0010" num="0374"> 10) The device informs the server that the setup process on the device has completed for the specified applications. As part of the request the device sends a new software sync anchor. </li><li id="ul0087-0011" num="0375"> 11) The application informs the server through an optional request that it is ready to be used. <br /> Application Exchange Data Structures </li></ul></li></ul>

0376This section describes the XML_RPC data structures which are used in the exchange of software applications between the device and the server. The application exchange data structures include SetupInfo, SetupInfoItem, SetupCommand, Name ValuePair, and AppExResult.

0377The SetupInfo structure is used when the device requests the server for available software changes. The server returns a SetupInfo instance which represents software updates available for the device. <tables id="TABLE-US-00021" num="21"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="OFFSET" colwidth="35PT" align="left" /><colspec colname="1" colwidth="182PT" align="left" /><thead><row><entry /><entry /></row><row><entry /><entry namest="OFFSET" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /><entry>struct SetupInfo</entry></row><row><entry /><entry>{</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="3"><colspec colname="OFFSET" colwidth="35PT" align="left" /><colspec colname="1" colwidth="98PT" align="left" /><colspec colname="2" colwidth="84PT" align="left" /><tbody valign="top"><row><entry /><entry> string</entry><entry>description;</entry></row><row><entry /><entry> int</entry><entry>setupSize;</entry></row><row><entry /><entry> Date</entry><entry>sunshineDate;</entry></row><row><entry /><entry> SetupInfoItem[ ]</entry><entry>setupInfoItems;</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="OFFSET" colwidth="35PT" align="left" /><colspec colname="1" colwidth="182PT" align="left" /><tbody valign="top"><row><entry /><entry>}</entry></row><row><entry /><entry namest="OFFSET" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0378Data members: <ul id="ul0088" list-style="none"><li id="ul0088-0001" num="0000"><ul id="ul0089" list-style="none"><li id="ul0089-0001" num="0379"> description: it is a mandatory field, and is human-readable. It describes the whole software update and is used by the device to display a message in the dialog box for the user if the user is asked to accept the update. </li><li id="ul0089-0002" num="0380"> setupSize: it is a mandatory field, which specifies the space requirements for the application update. </li><li id="ul0089-0003" num="0381"> sunshineDate: it is an optional field, which specifies the time when the software may be updated. The format is UTC. The access to the server can be denied when the device did not install the software in time. When this field is missing, the device processes the software changes immediately; otherwise the user will get asked if he wants to get the update now or later. </li><li id="ul0089-0004" num="0382"> setupInfoItems: it is an optional field, which is an array of SetupInfoItem structures when software changes exist. </li></ul></li></ul>

0383The SetupInfoItem structure is used inside the SetupInfo structure. Each SetupInfoItem represents a software change available for the device. <tables id="TABLE-US-00022" num="22"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="OFFSET" colwidth="42PT" align="left" /><colspec colname="1" colwidth="175PT" align="left" /><thead><row><entry /><entry /></row><row><entry /><entry namest="OFFSET" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /><entry>struct SetupInfoItem</entry></row><row><entry /><entry>{</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="3"><colspec colname="OFFSET" colwidth="42PT" align="left" /><colspec colname="1" colwidth="70PT" align="left" /><colspec colname="2" colwidth="105PT" align="left" /><tbody valign="top"><row><entry /><entry> int</entry><entry>setupType;</entry></row><row><entry /><entry> string</entry><entry>setupInfoId;</entry></row><row><entry /><entry> string</entry><entry>description;</entry></row><row><entry /><entry> boolean</entry><entry>additionalDescription;</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="OFFSET" colwidth="42PT" align="left" /><colspec colname="1" colwidth="175PT" align="left" /><tbody valign="top"><row><entry /><entry>}</entry></row><row><entry /><entry namest="OFFSET" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0384Data members: <ul id="ul0090" list-style="none"><li id="ul0090-0001" num="0000"><ul id="ul0091" list-style="none"><li id="ul0091-0001" num="0385"> setupType: it is a mandatory field, and it may contain one of the constants INSTALL=1, UPDATE=2, and UNINSTALL=3. </li><li id="ul0091-0002" num="0386"> additionalDescription: it is an optional field, which specifies that the description for this setup item is independent of and additional to the overall description in the SetupInfo and is presented to the user additionally. If this flag is not present or is false, the description is not presented to the user. </li><li id="ul0091-0003" num="0387"> setupInfoId: it is a mandatory field, which uniquely identifies the application setup change for the device. </li><li id="ul0091-0004" num="0388"> description: it is an optional field, which describes the software change. </li></ul></li></ul>

0389The SetupCommand structure is used to send setup commands to the device as part of the software change. An example of the SetupCommand structure and its corresponding data members are described below. <tables id="TABLE-US-00023" num="23"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="OFFSET" colwidth="35PT" align="left" /><colspec colname="1" colwidth="182PT" align="left" /><thead><row><entry /><entry /></row><row><entry /><entry namest="OFFSET" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /><entry>struct SetupCommand</entry></row><row><entry /><entry>{</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="3"><colspec colname="OFFSET" colwidth="35PT" align="left" /><colspec colname="1" colwidth="98PT" align="left" /><colspec colname="2" colwidth="84PT" align="left" /><tbody valign="top"><row><entry /><entry> int</entry><entry>setupType;</entry></row><row><entry /><entry> int</entry><entry>itemRef</entry></row><row><entry /><entry> string</entry><entry>URL;</entry></row><row><entry /><entry> string</entry><entry>CRCStr</entry></row><row><entry /><entry> string</entry><entry>programId;</entry></row><row><entry /><entry> NameValuePair[ ]</entry><entry>nameValuePairs</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="OFFSET" colwidth="35PT" align="left" /><colspec colname="1" colwidth="182PT" align="left" /><tbody valign="top"><row><entry /><entry>}</entry></row><row><entry /><entry namest="OFFSET" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0390Data members: <ul id="ul0092" list-style="none"><li id="ul0092-0001" num="0000"><ul id="ul0093" list-style="none"><li id="ul0093-0001" num="0391"> setupType: it is a mandatory field, and it contains one of the constants INSTALL=1, UPDATE=2, and UNINSTALL=3. </li><li id="ul0093-0002" num="0392"> itemRef it is a mandatory field. The SetupCommand elements in the SetupCommand array are marked with an increasing item reference number. This item reference is used in some functions to identify one SetupCommand element from the array. </li><li id="ul0093-0003" num="0393"> URL: it is an optional field, which specifies the URL for the setup command or file to download. This field is normally set by default. However, on some platforms, no software needs to be downloaded for an un-install. </li><li id="ul0093-0004" num="0394"> CRCStr: it is an optional field and contains a CRC-32 check sum information. The CRC may be used by the device to cache software downloads based on the CRC, or it may be used to check whether the downloaded file is corrupted. </li><li id="ul0093-0005" num="0395"> programId: it is a mandatory field, and contains an ID that uniquely identifies the application program being set up. </li><li id="ul0093-0006" num="0396"> Name ValuePairs: it is an optional field, and specifies the NameValuePair data structure. </li></ul></li></ul>

0397The NameValuePair structure is used as part of the SetupCommand structure. A NameValuePair structure is used to specify name/value pair parameters. These parameters are specific to this installation and are used to transport information, for instance command line parameters, that is needed for the specific software and/or device type. <tables id="TABLE-US-00024" num="24"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="OFFSET" colwidth="77PT" align="left" /><colspec colname="1" colwidth="140PT" align="left" /><thead><row><entry /><entry /></row><row><entry /><entry namest="OFFSET" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /><entry>struct NameValuePair</entry></row><row><entry /><entry>{</entry></row><row><entry /><entry> string name;</entry></row><row><entry /><entry> string value;</entry></row><row><entry /><entry>}</entry></row><row><entry /><entry namest="OFFSET" nameend="1" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0398The AppExResult structure is used to return the result of the method request. It contains information pertaining to application exchange. <tables id="TABLE-US-00025" num="25"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="OFFSET" colwidth="49PT" align="left" /><colspec colname="1" colwidth="168PT" align="left" /><thead><row><entry /><entry /></row><row><entry /><entry namest="OFFSET" nameend="1" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /><entry>struct AppExResult</entry></row><row><entry /><entry>{</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="3"><colspec colname="OFFSET" colwidth="49PT" align="left" /><colspec colname="1" colwidth="70PT" align="left" /><colspec colname="2" colwidth="98PT" align="left" /><tbody valign="top"><row><entry /><entry> SetupInfo</entry><entry>setupInfo;</entry></row><row><entry /><entry> SetupCommand[ ]</entry><entry>setupCommands;</entry></row><row><entry /><entry> int</entry><entry>result;</entry></row><row><entry /><entry>}</entry></row><row><entry /><entry namest="OFFSET" nameend="2" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0399Data members: <ul id="ul0094" list-style="none"><li id="ul0094-0001" num="0000"><ul id="ul0095" list-style="none"><li id="ul0095-0001" num="0400"> setupInfo: it is an optional field, and is used for returning the application setup information to the device. This field is returned only when the device calls getApplicationUpdates. </li><li id="ul0095-0002" num="0401"> setupCommands: it is an optional field, and is used for returning the setup commands associated with application change (install, update, or uninstall). This field is returned when the device calls initiateApplicationUpdates. </li><li id="ul0095-0003" num="0402"> result: it is a mandatory field, and contains the result of the application exchange method request. <br /> Application Exchange Functions </li></ul></li></ul>

0403This section describes the functions used to perform application exchange between the device and the server. The AppEx functions include checkSyncAnchors, getApplicationUpdates, initiateApplicationUpdates, deviceSetupStarts, deviceSetupEnds, applicationInstalled, applicationReadyToTest, applicationReadyToGo, and initRefresh. Some functions can send an error code to the server. In one implementation, the error codes are defined below in Table 5. <tables id="TABLE-US-00026" num="26"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="3"><colspec colname="1" colwidth="21PT" align="center" /><colspec colname="2" colwidth="112PT" align="left" /><colspec colname="3" colwidth="84PT" align="left" /><thead><row><entry namest="1" nameend="3" align="center">TABLE 5</entry></row><row><entry /></row><row><entry namest="1" nameend="3" align="center" rowsep="1" /></row><row><entry>Code</entry><entry>Name</entry><entry>Description</entry></row><row><entry namest="1" nameend="3" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="3"><colspec colname="1" colwidth="21PT" align="char" char="." /><colspec colname="2" colwidth="112PT" align="left" /><colspec colname="3" colwidth="84PT" align="left" /><tbody valign="top"><row><entry>0</entry><entry>OK</entry><entry>No error occurred.</entry></row><row><entry>1</entry><entry>ERR_CANT_GET_RESPONSE</entry><entry>The server did not</entry></row><row><entry /><entry /><entry>respond to a call.</entry></row><row><entry>2</entry><entry>ERR_CANT_DOWNLOAD_FILE</entry><entry>The component was not</entry></row><row><entry /><entry /><entry>able to download a file</entry></row><row><entry /><entry /><entry>from the file server.</entry></row><row><entry>3</entry><entry>ERR_CANT_WRITE_FILE</entry><entry>The component is not able</entry></row><row><entry /><entry /><entry>to store a downloaded file.</entry></row><row><entry>4</entry><entry>ERR_RAN_OUT_OF_DISK</entry><entry>Ran out of disk space</entry></row><row><entry /><entry>SPACE</entry><entry>(whatever disk for the</entry></row><row><entry /><entry /><entry>current platform means).</entry></row><row><entry>5</entry><entry>ERR_RAN_OUT_OF_MEMORY</entry><entry>Ran out of memory.</entry></row><row><entry>200</entry><entry>ERR_SETUP_FAILED</entry><entry>The Setup program failed.</entry></row><row><entry namest="1" nameend="3" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0404Note that for device local errors like ERR CANT_DOWNLOAD_FILE or ERR_RAN_OUT_OF_DISKSPACE, the device tries all possible steps to fix the errors (e.g. asks the user to check the Internet connection or to clean up the hard drive) before reporting the error to the server. When the device sends an error code to report a problem of the current software the server disables the device.

0405The checkSyncAnchors is used every time a device starts up; it sends the current software anchor known to the device. When the device has a pending anchor, it also sends the pending anchor to the server. In the alternative when the device has no pending anchor, no pending anchor is sent to the server. The server compares the anchor received to the anchor stored on the server to determine whether the device and the server are out of sync. <ul id="ul0096" list-style="none"><li id="ul0096-0001" num="0000"><ul id="ul0097" list-style="none"><li id="ul0097-0001" num="0406"> AppExResult checkSyncAnchors(String anchor, String pendingAnchor) </li></ul></li></ul>

0407Returns: an instance of the AppExResult where the result is <b>200</b> when the anchors match, result is <b>417</b> when there is an anchor mismatch.

0408The getApplicationUpdates method returns information about the list of all application updates available for the device. <ul id="ul0098" list-style="none"><li id="ul0098-0001" num="0000"><ul id="ul0099" list-style="none"><li id="ul0099-0001" num="0409"> AppExResult getApplicationUpdates(String anchor) </li><li id="ul0099-0002" num="0410"> Returns: an instance of the AppExResult that contains the SetupInfo structure when software changes are available. Otherwise the SetupInfo member is not set. </li><li id="ul0099-0003" num="0411"> Parameters: <ul id="ul0100" list-style="none"><li id="ul0100-0001" num="0412"> anchor—The device sends a new anchor. </li></ul></li></ul></li></ul>

0413The initiateApplicationUpdates method is invoked by the device to get a list of instructions from the server to start the application change (install, update, or uninstall) process. The information returned by the server includes the files to be downloaded and the commands to be executed on the device. The device executes the application change commands in the order listed in the returned setup commands. <ul id="ul0101" list-style="none"><li id="ul0101-0001" num="0000"><ul id="ul0102" list-style="none"><li id="ul0102-0001" num="0414"> AppExResult initiateApplicationUpdates(String[ ] setupInfoIds) </li><li id="ul0102-0002" num="0415"> Returns: an instance of the AppExResult that contains the SetupCommand array. </li><li id="ul0102-0003" num="0416"> Parameters: <ul id="ul0103" list-style="none"><li id="ul0103-0001" num="0417"> setupInfoIds—As parameter the device sends the setupInfoIds from the getApplicationUpdates response. </li></ul></li></ul></li></ul>

0418The deviceSetupStarts method informs the server that application setup has started on the device. It enables the server to invalidate all the old services associated with the software that is being changed. On the other hand if new application updates have been added on the server after the device has initiated the application update process and before this function call, the server returns an error code <b>301</b> indicating new application updates exist. When this happens, the device restarts the application update process. <ul id="ul0104" list-style="none"><li id="ul0104-0001" num="0000"><ul id="ul0105" list-style="none"><li id="ul0105-0001" num="0419"> AppExResult deviceSetupStarts( ) </li><li id="ul0105-0002" num="0420"> Returns: an instance of the AppExResult, which may issue the result code <b>301</b> to indicate that the device restarts the AppEx process. </li></ul></li></ul>

0421When the device tries to request this method and gets no answer back from the server, it does not know whether the request has been received by the server or whether the response from the server was lost. In this case the device retries with a new request to this method. Note that this can result in a <b>420</b> error code if the response was lost.

0422The deviceSetupEnds method informs the server that the application setup on the device has completed. The server checks whether more software changes were scheduled in the meantime on the server and sends out a new notification when necessary. <ul id="ul0106" list-style="none"><li id="ul0106-0001" num="0000"><ul id="ul0107" list-style="none"><li id="ul0107-0001" num="0423"> AppExResult deviceSetupEnds(String anchor, int itemRef, int error Code, String errorMsg) </li><li id="ul0107-0002" num="0424"> Parameters: <ul id="ul0108" list-style="none"><li id="ul0108-0001" num="0425"> anchor—The device sends a new anchor that represents the currently installed software. </li><li id="ul0108-0002" num="0426"> itemRef this parameter may be used in two ways: <ul id="ul0109" list-style="none"><li id="ul0109-0001" num="0427"> First, the itemRef specifies that the command at position “N” and all other commands less than that position “N” in the setup commands array are successful and all other commands are not executed. </li><li id="ul0109-0002" num="0428"> Second, the itemRef indicates that the setup for the command at the position specified by itemRef, for example “M,” has failed, all other commands with an offset less than “M” are successful, and all commands with an offset greater than “M” are not executed. </li></ul></li><li id="ul0108-0003" num="0429"> error Code—In case of an error, the cause of error is listed here. Otherwise an “OK” code is returned. </li><li id="ul0108-0004" num="0430"> errorMsg—this parameter specifies a detailed error message. In case of success, this field is null. </li></ul></li><li id="ul0107-0003" num="0431"> Returns: an instance of the AppExResult. </li></ul></li></ul>

0432This method is called under normal operation. If the current AppEx process uninstalls the program that includes the AppEx code, the device calls this method immediately before it starts the un-installation.

0433The applicationInstalled method informs the server that the application has been installed or updated. It is mandatory for every application which uses REx API or SetEx API to synchronize data between the device and the server. The primary usage of this method is for program update. The server calls this method to activate settings that are used by the updated software. <ul id="ul0110" list-style="none"><li id="ul0110-0001" num="0000"><ul id="ul0111" list-style="none"><li id="ul0111-0001" num="0434"> AppExResult applicationInstalled(String programId, int error Code, String errorMsg) </li><li id="ul0111-0002" num="0435"> Parameters: <ul id="ul0112" list-style="none"><li id="ul0112-0001" num="0436"> programId—uniquely identifies the application service on the server side. </li><li id="ul0112-0002" num="0437"> error Code—In case of an error, the cause of error is listed here. Otherwise an OK code is returned. </li><li id="ul0112-0003" num="0438"> errorMsg—Specifies a detailed error message. In case of a successful application installation, this field is null. </li></ul></li><li id="ul0111-0003" num="0439"> Returns: an instance of the AppExResult. </li></ul></li></ul>

0440The applicationReadyToTest method informs the server that it wants to perform some testing to check whether it works correctly. The server uses this method to activate some test data. <ul id="ul0113" list-style="none"><li id="ul0113-0001" num="0000"><ul id="ul0114" list-style="none"><li id="ul0114-0001" num="0441"> AppExResult applicationReadyToTest(String programId, int error Code, String errorMsg) </li><li id="ul0114-0002" num="0442"> Parameters: <ul id="ul0115" list-style="none"><li id="ul0115-0001" num="0443"> programId—uniquely identifies the application service on the server side. </li><li id="ul0115-0002" num="0444"> error Code—In case of an error, the cause of error is listed here. Otherwise an “OK” code is returned. </li><li id="ul0115-0003" num="0445"> errorMsg—Specifies a detailed error message. In case of success this field is null. </li></ul></li><li id="ul0114-0003" num="0446"> Returns: an instance of the AppExResult. </li></ul></li></ul>

0447The applicationReadyToGo method informs the server that it is ready for use. Each program that calls applicationinstalled or applicationReadyToTest is required to call the applicationReadyToGo method. <ul id="ul0116" list-style="none"><li id="ul0116-0001" num="0000"><ul id="ul0117" list-style="none"><li id="ul0117-0001" num="0448"> AppExResult applicationReadyToGo(String programId, int error Code, String errorMsg) </li><li id="ul0117-0002" num="0449"> Parameters: <ul id="ul0118" list-style="none"><li id="ul0118-0001" num="0450"> programId—uniquely identifies the application service on the server side. </li><li id="ul0118-0002" num="0451"> error Code—In case of an error, the cause of error is listed here. Otherwise an “OK” code is returned. </li><li id="ul0118-0003" num="0452"> errorMsg—Specifies a detailed error message. In case of success this field is null. </li></ul></li><li id="ul0117-0003" num="0453"> Returns: an instance of the AppExResult. </li></ul></li></ul>

0454The initRefresh method is used when the device informs the server that it wants to re-install all software on the device. When the server receives this request, it marks all software which may be on the device for installation. When the device receives a successful response to this call, it performs a complete AppEx process to retrieve the commands. <ul id="ul0119" list-style="none"><li id="ul0119-0001" num="0000"><ul id="ul0120" list-style="none"><li id="ul0120-0001" num="0455"> AppExResult initRefresh( ) </li><li id="ul0120-0002" num="0456"> Returns: an instance of the AppExResult. </li></ul></li></ul>

0457The server sends a notification when it has software changes for the device. When a device calls getApplicationUpdates, the server assumes that the device has received the notification and clears the notification on the server side. This means that the device makes the result of getApplication Updates persistent for both the cases that the user postpones the software changes and that the device has been restarted. When the device receives a notification in the middle of an AppEx process, the device may ignore the notification. When the device calls deviceSetupEnds to terminate the AppEx process, the server checks whether more software changes exist and sends out a new notification if necessary.

0000Application Exchange Status Code

0458In settings exchange, the status code <b>300</b> is returned when the device is in the zombie mode. In this case, the device first sends the device type identification using the Device Provisioning Protocol to leave the zombie mode.

0459A call to the deviceSetupStarts method can return a <b>301</b> result code that forces the device to start with the whole AppEx process from the beginning by calling getApplicationUpdates. A request to getApplicationUpdates can return a <b>302</b> result code when the server currently is not able to determine whether software changes exist. This may happen when the server waits for a newly installed or updated software program to call applicationInstalled and/or applicationReadyToGo. In this case the device retries the request later for several times with an increased delay. After several retries, if the server still responds with the <b>302</b> status code, the device ends the whole AppEx process and just waits for the next notification.

0460A call to the checkSyncAnchors method can return a <b>417</b> result code that indicates the software on the device and the software the server believes may be on the device are different. Each call to the server may result in an error code <b>500</b>. This is a temporary server error indicating the server is not able to respond to the device call at this moment for whatever reason. The data content has not been examined by the server, so it is not considered to be wrong. The client retries the same request using the same interval as before. After a given numbers of retries, the client may terminate the retry and wait for the next normal synchronization event, such as a notification or polling timeout.

0000Software Sync Anchors

0461Software sync anchors are used to detect when the software on the device is different from the software the server believes may be on the device. This may happen when the user tries to back up the whole device. In this situation, the software on the device may be incompatible with the software that was installed on the device through the server before the device was restored from the backup.

0462Both the device and the server are initialized to the same software sync anchor value to guarantee that they are in sync in the beginning. The device drives the sync anchors. Each time the device calls getApplicationUpdates or deviceSetupEnds, it sends a new anchor to the server, which stores the anchor. When the device receives from the server a successful response to the call, it replaces the current anchor with the new anchor which was sent to the server. When the call to getApplicationUpdates or deviceSetupEnds fails, the device does not know whether the server has received the request and has stored the new anchor. Therefore it resends the pending new anchor when it tries to call the request again.

0463Each time when it starts, the device sends the current anchor to the server using checkSyncAnchors. When the device has a pending new anchor that has not gotten a successful response for the deviceSetupEnds call, it sends this anchor as a parameter to the checkSyncAnchors call. The server compares the sent anchor (or the sent anchors) with the last anchor it has received from the device. When the anchors do not match, the device reports the problem to the user and calls initRefresh to start a complete software installation from scratch.

0000Application Exchange States

0464The server may be in one of two states during the software installation, uninstall or update process. <figref idref="DRAWINGS">FIG. 24</figref> illustrates an application exchange state transition diagram according to an embodiment of the present invention. When the device calls an illegal method, the error state causes the server to return a <b>420</b> status code as a response to this call. Afterwards, the state machine returns to the state from which it transitioned to the error state.

0465To get out of an error state, the device may call getApplicationUpdates and restart the whole application exchange process. To do that, the device calls deviceSetupEnds with an error code (for example <b>200</b>) and −1 as an itemRef. Then it starts a new AppEx process from a clean state with respect to the previously interrupted process. Application Exchange Installations and Updates

0466When the device installs or updates software over AppEx, it may happen that the installation or update fails. When the changes have not been completely rolled back by the setup program (since the device has crashed), it may happen that the software is no longer useable. This is critical if the device tries to update the software which performs AppEx on the device.

0467If the device is still able to run the AppEx with the server, it may try to call the initRefresh method followed by the AppEx process to re-install all (and so the broken) software programs on the device. If the device is no longer able to run the AppEx programs, it uses the loader to send the device capabilities, such as the device type identification information, again to deliver the URL to the remote installer. This call implies that on the server side all software programs are marked for re-installation. The device installs the remote installer and then uses AppEx to re-install the software programs.

0468It will be appreciated that the above description for clarity has described embodiments of the invention with reference to different functional units and processors. However, it will be apparent that any suitable distribution of functionality between different functional units or processors may be used without detracting from the invention. For example, functionality illustrated to be performed by separate processors or controllers may be performed by the same processor or controllers. Hence, references to specific functional units are only to be seen as references to suitable means for providing the described functionality rather than indicative of a strict logical or physical structure or organization.

0469The invention can be implemented in any suitable form, including hardware, software, firmware, or any combination of these. The invention may optionally be implemented partly as computer software running on one or more data processors and/or digital signal processors. The elements and components of an embodiment of the invention may be physically, functionally, and logically implemented in any suitable way. Indeed, the functionality may be implemented in a single unit, in a plurality of units, or as part of other functional units. As such, the invention may be implemented in a single unit or may be physically and functionally distributed between different units and processors.

0470One skilled in the relevant art will recognize that many possible modifications and combinations of the disclosed embodiments may be used, while still employing the same basic underlying mechanisms and methodologies. The foregoing description, for purposes of explanation, has been written with references to specific embodiments. However, the illustrative discussions above are not intended to be exhaustive or to limit the invention to the precise forms disclosed. Many modifications and variations are possible in view of the above teachings. The embodiments were chosen and described to explain the principles of the invention and their practical applications, and to enable others skilled in the art to best utilize the invention and various embodiments with various modifications as are suited to the particular use contemplated.