JP4343704B2 - Method and system for server-based operations in server synchronization with computing devices - Google Patents

Description

Related applications

(Mutual citation of related applications)
The present disclosure is named “Method and Apparatus For Detecting Insufficient Memory For Data Extraction Processes” filed on September 28, 2001, and named “Method and Apparatus for Detecting Insufficient Memory for the Data Extraction Process”. This is a continuation-in-part of US Patent Application No. 09/967439.

  The present disclosure relates generally to computer systems, and more particularly, but not exclusively, to transferring data from one computer system to another.

  Portable computing devices such as personal digital assistants (PDAs) available from vendors such as Palm, Handspring, Hewlett Packard, Sony, Casio, and Pion. Devices (also referred to herein as handheld devices) are increasingly accepted in the business world. Some users need to use their handheld devices to interact with enterprise business applications, such as those provided by Siebel Systems, Inc., Oracle Corporation et al. . These enterprise business applications include large databases that can be accessed and / or updated by any number of users at any time.

  Accessing enterprise business applications through handheld devices is due to the relatively limited amount of computing power, energy storage, and memory available on regular handheld devices, You may face big problems. For example, a user may desire to extract data that resides in a server that is used to support enterprise business applications. In view of the limited resources of handheld devices, it is generally desirable for handheld devices to be designed and configured to efficiently receive extracted data.

Means to solve the problem

  In accordance with aspects of the present invention, a method and system for synchronizing a main database of a server and a local database of a handheld device is provided. A user can perform transactions in a local database using an application residing in the handheld device. In one aspect of the invention, the handheld device (1) establishes a connection between the server and the sync client, (2) receives an identifier of the structure of the main database from the server, and (3) a version of the handheld application Configured to receive (4) send transaction information to the server, (5) receive metadata to update the handheld application, and (6) receive data extracted from the main database from the server Related to sync client. This aspect allows the system to determine which database data and metadata the handheld device needs during synchronization, and the system uploads transactions performed by the user into the local database. This is advantageous.

  In another aspect of the invention, the sync client downloads a full extract of the main database to the handheld device, or a delta extract (ie, data in the main database that has changed since the last sync operation). Just configured to decide what to download). This aspect has the advantage that the system can perform a delta extract download where appropriate to reduce the time required to complete the synchronization operation.

  In yet another aspect of the invention, the sync client is configured to update the filter information used by the server to filter data from the main database downloaded to the handheld device.

  Non-limiting and non-exhaustive embodiments of the present invention are described with reference to the following figures. Unless otherwise noted, like numerals refer to like parts throughout the various figures.

  Embodiments of a system and method for detecting insufficient memory conditions during the data extraction process are described below. In the following description, numerous specific details are set forth in order to provide a thorough understanding of embodiments of the present invention. However, one skilled in the art will also understand that the invention may be practiced without one or more of its specific details or using other methods, components, materials, and the like. In other instances, well-known structures, materials, or operations have not been shown or described in detail to avoid obscuring aspects of the invention.

  Throughout this specification, reference to “an embodiment” or “an embodiment” includes a particular feature, structure, or characteristic described in connection with that embodiment is included in at least one embodiment of the invention. Means that Thus, the appearances of the phrases “in one embodiment” or “in an embodiment” in various places throughout this specification are not necessarily all referring to the same embodiment. Furthermore, the particular features, structures, or characteristics may be combined in any suitable manner in one or more embodiments.

  In the following description, for purposes of explanation, specific terminology may be set forth in order to provide a thorough understanding of the present invention. However, after reading the description, it will be apparent to one skilled in the art that those specific details are not required in order to practice the invention.

  Some portions of the detailed descriptions that follow may be presented in the form of algorithms or symbolic representations of information stored in computer memory. Those algorithmic descriptions and representations can be used by those skilled in the art to convey the substance of their work to others skilled in the art. An algorithm is herein and generally considered a self-consistent sequence of steps or operations that yields the desired result. Those steps or operations may require physical manipulation of physical quantities. Usually, but not necessarily, these quantities take the form of electrical, magnetic, or electromagnetic signals capable of being stored, transferred, combined, compared, or otherwise manipulated. These signals are referred to herein or generally as bits, bytes, words, values, elements, symbols, characters, terms, numbers, and the like.

  Unless otherwise stated, terms such as “processing”, “computing”, “computing”, “determining”, “displaying”, etc. refer to computer systems or other similar electronic computing Refers to device actions and processes. Specifically, these actions and processes operate on data represented as physical quantities (described above) within a computer system register or within a memory, and the computer system memory or register, or other information storage device, The data is transformed into another data that is similarly represented as an internal physical quantity of the information transmission device or the information display device.

  The invention also relates to one or more devices for performing the operations described herein. Some devices may be specially constructed for the required purpose, or may include a general purpose computer selectively activated or configured by a computer program stored within the computer. Such computer programs can be stored on any computer readable storage medium, including but not limited to floppy disks, optical disks, compact disks (CDs), magneto-optical disks, and any other type of disk. Can be stored inside. Other storage media include read-only memory (ROM) including erasable programmable ROM, electrically erasable programmable ROM (EPROM and EEPROM), and random access memory (RAM) including static RAM and dynamic RAM Further, a magnetic card or an optical card is included.

  The algorithms and displays presented herein are not inherently related to any particular computer or other apparatus unless specifically stated otherwise. Dedicated devices as well as various general purpose systems can be used with programs according to the teachings herein. In addition, the present invention is not described with reference to any particular programming language. In view of the present disclosure, those skilled in the art can use the various programming languages to implement the teachings of the present disclosure without undue experimentation.

System Overview FIG. 1 illustrates a system 100 having a database that a user can access via a handheld device according to one embodiment of the present invention. The system 100 includes a main computer system 110 having a main database 12 and a server connected to the database 112. In the first possible embodiment, the server is implemented as server 114. In a second possible embodiment, the server is implemented as a server 116 that includes a synchronization engine 118. In a third possible embodiment, main computer system 110 may include both server 114 and server 116. Both servers 114 and 116 are shown in FIG. 1 for convenience. However, in the first embodiment and the second embodiment described above, either of the servers can be omitted.

  System 100 also includes a handheld device that a user uses to remotely access main database 112. Handheld devices 120-1, 120-2, 120-3, 120-4, 120-5 are shown in FIG. If server 114 is present in system 100, the user can remotely access main database 112 via connection 122 to server 114 using handheld device 120-1. In one embodiment, connection 122 is implemented using a standard telephone modem or a serial interface defined by the handheld device manufacturer.

  Alternatively, a user may remotely access main database 112 via an intermediate computer device (also referred to herein as a companion device) 124 connected to server 114 via connection 126. . The companion device 124 is typically a more powerful computing device (ie, having more memory, a higher performance processor, a larger power supply, etc.) than a normal handheld device. For example, the companion device can be a desktop computer or a notebook computer. Handheld device 120-2 and companion device 124 transfer information over connection 127. In one embodiment, connection 127 is typically implemented using a serial interface provided with a handheld device. For example, connection 127 can be implemented using a serial port protocol, a parallel port protocol, or other bus protocol. Some handheld devices include a cradle assembly that provides a physical interconnection between the handheld device and the companion device.

  In this embodiment, companion device 124 includes a synchronization engine 128 and a synchronization manager 130. The synchronization engine 128 performs the same function as the synchronization engine 118 of the server 116. In some embodiments, synchronization manager 130 and synchronization engines 118, 128 are implemented in software executed by one or more processors of companion device 124 or server 116. Further, although not shown in FIG. 1, this embodiment of handheld device 120-1 includes a synchronization engine and a synchronization manager that perform essentially the same functions as synchronization engine 128 and synchronization manager 130.

  If server 116 is present in main computer system 110, a user can access main database 112 via connection 132 to server 116 using handheld device 120-3. Connection 132 may be a telephone modem connection, as described above with respect to connection 122, or any other type of connection supported by both server 116 and handheld device 120-3. Although not shown, this embodiment of handheld device 120-3 includes a synchronization manager that provides essentially the same functionality as synchronization manager 130. As described above, the server 116 includes the synchronization engine 118 so that a device accessing the main database 112 via the server 116 does not have to have its own synchronization engine.

  Alternatively, a user can access main database 112 via companion device 134 using handheld device 120-4. Device 134 is connected to the handheld device via connection 136. Connection 136 is typically a serial interface provided by a handheld device vendor. Companion device 134 is connected to server 116 via connection 138. In this embodiment, handheld device 120-4 includes a synchronization manager component (not shown) similar to handheld device 120-3. Companion device 134 includes an interface component (also referred to herein as a proxy) 140 that allows data transfer between possible server 116 and handheld device 120-4. It doesn't have to be a proxy. For example, in one embodiment, the connection 138 (ie, the connection between the server and companion devices) can be an HTTP (Hypertext Transport Protocol) connection (eg, an Internet connection), while Connection 136 (i.e., a connection between a companion device and a handheld device) can be a unique handheld device synchronization connection (e.g., a serial bus). Thus, interface component 140 effectively acts as a proxy between server 116 and handheld device 120-4.

  Further, the user can access the main database 112 via the companion device 144 using the handheld device 120-5. Device 144 is connected to handheld device 120-5 via connection 146. In this embodiment, companion device 144 includes a synchronization manager 148 that communicates with server 116 via connection 150. With the sync manager 148 of the companion device 144, the handheld device 120-5 need not have a sync manager component.

  In fact, several users can use the handheld device to main through each of the five paths described above (ie, the communication path between the main database 112 and the handheld devices 120-1 to 120-5). Can access the database 112 Thus, for example, although only one handheld device 120-3 is shown in FIG. 1 as being directly coupled to the server 116, several users are substantially connected to the handheld device 120-3. Main database 112 can be accessed in essentially the same manner using handheld devices configured in the same manner.

  Furthermore, other embodiments of the system 100 may be implemented using various combinations or permutations of the five paths described above. For example, system 100 may include main database 112 and handheld device 120-3 (via direct connection 132 with server 116) and database 112 and handheld device 120-4 (via server 116 and companion device 134). ) Can be implemented to support only the path between. According to this exemplary embodiment, a handheld device configured with a synchronization manager can perform direct synchronization or companion synchronization (via proxy 140).

  Furthermore, while telephone modem connections, HTTP connections, and standard handheld synchronous connections have been described above, in any other embodiment, any suitable connection can be used. For example, other embodiments can use protocols other than HTTP. Furthermore, even if the signal propagation medium used by this connection is wired (for example, using a medium such as twisted pair, cable, optical fiber), it is wireless (for example, infrared technology, radio frequency technology, optical technology). May be used).

  One function of the system 100 is to synchronize selected information between the main computer system 110 and the handheld device. For example, the information can be data from a database stored in the main database 112 or a local database (not shown) of the handheld device. During operation of the system 100, data in the database is frequently updated by the user. The updated database data is delivered to the user via a synchronization process. In addition, the information to be synchronized may include definitions (also referred to herein as metadata) used by applications running on the handheld device. Some of the operations performed during the synchronization process are described below with respect to FIG.

  FIG. 2 illustrates the data flow between the handheld device 202 and another computer system 204 when synchronizing data according to one embodiment of the present invention. For example, the computer system 204 may either (a) either the server 114 or 116, or (b) the companion device 124, or (c) the companion device 134 coupled with either the server 114 or 116, or (d ) Implemented by companion device 144 coupled to either server 114 or 116. Some specific embodiments of the data flow operation of FIG. 2 are described below in connection with FIGS.

  Referring again to FIG. 2, the handheld device 202 initiates a connection with the computer system 204 indicated by arrow 210 in FIG. In one embodiment, handheld device 202 initiates this connection with computer system 204 by logging in using a modem (eg, via an Internet connection). For example, this connection can be a standard HTTP connection. In another embodiment, the handheld device 202 can initiate this connection to the companion device using a synchronization interface application or hardware provided by the handheld device vendor. For example, the connection can be initiated when the user places the handheld device 202 in a cradle accessory and activates the sync button on the cradle.

  In this embodiment, computer system 204 then provides initialization data to handheld device 202 as indicated by arrow 212 in FIG. In one embodiment, the initialization information may include information related to the latest version of the main database 112. For example, a new table may have been added to the main database 112. In addition, the initialization information may include information related to the latest transaction uploaded to the computer system 204 (see description below). In one embodiment, the handheld device 202 pulls this initialization information after the connection is established. Alternatively, the computer system 204 may push initialization information to the handheld device 202 in response to the connection being established.

  As indicated by arrow 213 in FIG. 2, computer system 204 then forwards application definition information to handheld device 202. In one embodiment, this application definition information relates to a definition used in an application (also referred to herein as a handheld application) that a user uses to access the local database of handheld device 202. Contains information. For example, the application definition information can include a view and a screen displayed by the handheld application when providing a user interface. In one embodiment, the handheld device 202 determines whether it needs to update its local application definition (using initialization information) and, if necessary, passes the above information to the computer system. Pull from 204. In other embodiments, the computer system 204 can receive information from the handheld device 204 indicating an application-defined version of the handheld device 202. The computer system 204 then determines whether the handheld device 202 needs updated application definition information and pushes the updated application definition to the handheld device 202 if so.

  Handheld device 202 forwards the transaction information to computer system 204 as indicated by arrow 214 in FIG. In one embodiment, all local database transactions entered by the user into the handheld device 202 are recorded. This recorded transaction information is transferred to the computer system 204, which then executes the transaction in the main database 112 (FIG. 1). In some embodiments, the handheld device 202 transfers the transaction information as a block to the computer system 204. After receiving the entire block, computer system 204 determines whether the block has been properly received. In other embodiments, the handheld device 202 transfers transaction information in several relatively small blocks. After receiving each small block, the computer system 204 determines whether the block has been properly received and retransmits the block or sends a message or signal to the handheld device 202 to send the next block. Send. Thus, if a problem or interruption occurs during the transfer, the handheld device 202 need only transfer the blocks that were not properly received, rather than resending all of the transaction information.

  Computer system 204 then forwards the error information to handheld device 202 as indicated by arrow 216 in FIG. In one embodiment, this error information includes: (a) a transaction that the system 100 (FIG. 1) does not allow a user to perform transactions on data modified by one or more other users. And (b) information about changes made to the transaction by the server. The user can then manually correct or handle those errors on the handheld device 202.

  In addition, the handheld device 202 and the computer system 204 can update the filter settings as indicated by the arrow 218 in FIG. The filter settings are set so that unnecessary or unnecessary information is not transferred between the handheld device 202 and the computer system 204, and limited resources on the handheld device 202 are saved. In this embodiment, the user can update the filter settings of the handheld device 202 and then upload the settings to the computer system 204. Thus, the computer system 204 can avoid subsequently downloading information that the user does not want. Further, in this embodiment, computer system 204 processes the filter settings received from handheld device 202 to ensure that the filter settings are appropriate. For example, a user may be attempting to filter out information requested by an application currently running on the handheld device 202 in an attempt to perform properly.

  Next, the computer system 204 transfers the data in the database to the handheld device 202 as indicated by the arrow 220 in FIG. This operation is also referred to herein as “data extraction”. In one embodiment, the computer system 204 is visible to the handheld device 202 and forms all images of the data in the database after being filtered. This image is also referred to herein as extraction. The computer system 204 then downloads this extract to the handheld device 202. In one embodiment, the computer system 204 downloads the extract in a series of relatively small blocks, and the handheld device 202 confirms receipt of each small block.

  In another embodiment, computer system 204 stores the extract after each download. During the next data extraction operation, the computer system 204 compares the current extraction with the previous extraction and downloads only the database data that has changed (also referred to herein as a delta extraction). Then, the previous extraction can be deleted. In a further refinement, in certain circumstances, the computer system 204 can ignore the previous extraction and instead download the entire current extraction. For example, if the structure of the main database 112 (FIG. 1) has changed since the previous extraction, the computer system 204 performs a full extraction rather than attempting to perform a delta extraction. The handheld device 202 then disconnects from the computer system 204 as indicated by the arrow 222 in FIG.

  FIG. 3 illustrates the components of the synchronization engine 116 (FIG. 1) and handheld device 300 used in the synchronization operation according to one embodiment of the present invention. Handheld device 300 can be used to implement any handheld device 120-3 through 120-5 (FIG. 1).

  In this embodiment, the synchronization engine 116 includes a metadata extractor 301, a transaction processor 303, and a data extractor 305. The handheld device 300 includes a local database 308 and includes a synchronization client (synchronization client) 310 having a metadata importer 311, a transaction recorder 313, and a data importer 315. In this embodiment, the sync client 310 and its components are implemented in software.

  The above-described elements of the synchronization engine 116 and the synchronization client 300 are connected to each other as follows. The metadata generator / extractor 301 of the sync engine 116 is operatively coupled to the metadata importer 311 of the sync client 310 as indicated by the dashed line 317. The transaction processor 303 of the sync engine 116 is operatively coupled to the transaction recorder 313 of the sync client 310 as indicated by the dashed line 319. The data extractor 305 of the sync engine 116 is operatively coupled to the data importer 315 of the sync client 310 as indicated by the dashed line 321. The sync client 310 can access the local database 308 as indicated by line 323. The above components operate as follows.

  In this embodiment, some of the key functions of the metadata generator / extractor 301 determine whether the sync client 310 needs updated metadata and store the metadata stored on the server 116. Extracting data and transferring the extracted metadata to the handheld device 300. The metadata includes screen, view, field, etc. definitions for a handheld application (not shown) used to access the local database 308. The metadata generator / extractor 301 extracts metadata (stored in a specific format in the server 116) and forms a message or datagram containing the metadata for transmission to the sync client 310. To do.

  The metadata importer 311 of the sync client 310 processes the metadata sent from the metadata generator / extractor 301 to update the handheld application inside the handheld device 300. For example, in one embodiment, the metadata importer 311 determines whether the handheld device has sufficient memory to store the metadata before requesting the synchronization engine 116 to download the metadata. Determine. After the handheld device 300 stores the metadata, the metadata importer 311 can then update the handheld application (not shown) with the new application definition included in the metadata. . One embodiment of this operation is described in more detail below with respect to FIG.

  In this embodiment, a transaction recorder 313 within the handheld device 300 records information related to transactions made by the user to the local database 308. For example, each time a user changes data in the local database 308, the transaction recorder 313 assigns a transaction identifier (transaction ID) and records the transaction ID and other relevant information about the transaction. . In another embodiment, the transaction ID can be assigned when the synchronization process is performed. Other related information described above may include, for example, modified fields that are used by server 116 to find modified records on main database 112 (FIG. 1) or to create new records, Includes previous and new data, record identifiers and record names, and record-related details. The transaction recorder 313 can then upload the transaction to the transaction processor 303 of the synchronization engine 116.

  Transaction processor 303 receives transactions from handheld device 300 and executes each transaction to update main database 112 (FIG. 1). A transaction can be inconsistent with another transaction from another user, in which case the transaction processor 303 reports an error without executing the transaction. One embodiment of this operation is described in more detail below with respect to FIG. In another embodiment, the transaction processor 303 changes one or more portions of the transaction so that the transaction is successful. The transaction processor 303 can then send a message to the handheld device 300 informing the user of the changes that have been made.

  In this embodiment, the data extractor 305 of the synchronization engine 116 extracts database data that is visible to the handheld device 300 from the main database 112 (FIG. 1). The term visibility has the well-known meaning of remote access to a database (see, eg, US Pat. Nos. 6,216,135 and 6,233,617). Furthermore, in this embodiment, the data extractor 305 can avoid extracting data according to the filter settings (described above in connection with arrow 218 in FIG. 2). The data extractor 305 also forms the extracted database data into a file that is downloaded to the handheld device 300. In one embodiment, the synchronization engine 116 can send the file to the handheld device 300 in a series of small messages or datagrams.

  A data importer 315 of the handheld device 300 receives the file and temporarily stores the file to update the local database 308. As described below, this file may contain updated database data in a different format than that of the local database 308. In such cases, the data can be processed into a local database 308 format using a separate component.

Handheld Device FIG. 4 illustrates a handheld device 120-3 (FIG. 1) according to one embodiment of the present invention. In this embodiment, handheld device 120-3 is configured to synchronize directly with server 116. In addition to the local database 308, the handheld device 120-3 includes a synchronization client 401, a synchronization log (synchronization log) 403, a transaction database 405, a data storage application (also referred to herein as a data store) 407, data -It has a store 409. In this embodiment, sync client 401 performs functions substantially similar to those described with respect to sync managers 130 and 148 (FIG. 1) residing in the companion device. In particular, the sync client 401 executes the functions of the metadata importer 311, transaction recorder 313, and data importer 315 of the sync client 310 (FIG. 3).

  The sync log 403 is used to display a list of all messages sent during the sync operation (see, eg, the operation of FIG. 2), which will later be used if a problem occurs during sync. Can be used to restore information. The transaction database 405 is used to store information associated with each transaction (eg, information generated by the transaction recorder 313 of FIG. 3). In one embodiment, the synchronization manager stores transaction information in the transaction database 405. Alternatively, a handheld application (not shown) stores transaction information in transaction database 405. The data store 407 of this embodiment is used to process the downloaded database data into the local database 308 format. Data store 409 stores filter settings, version of local database 308, version of handheld application (not shown), file defining schema of local database, application definition described above from metadata. used. Data store 409 is also used to store transaction error messages. In this embodiment, the local database and handheld application versions are referred to herein as Extract ID and Repository ID, respectively. In some embodiments, the data store 409 may include an operating system registry (such as in the Windows operating system or the Linux operating system).

  A sync client 401 is coupled to a local database 308, a sync log 403, a transaction database 405, a data store 407, and a data store 409. Sync client 401 is also coupled to server 116 (FIG. 1) via connection 132. In addition, a data store 407 is coupled to the local database 308. The operation of this embodiment of handheld device 120-3 is described below in connection with FIG.

  FIG. 5 illustrates the components of handheld device 120-2 (FIG. 1) and companion device 124 (FIG. 1) according to one embodiment of the present invention. This embodiment of handheld device 120-2 and companion device 124 includes components similar to those previously described in handheld device 120-3 (FIG. 4). Specifically, the handheld device 120-2 includes a local database 308, a transaction database 405, a data store 407, and a data store 409. The companion device 124 includes a synchronization client 501 and a synchronization log 503. Both the synchronization client 501 and the synchronization log 503 are the synchronization client 401 (FIG. 3) and the synchronization log 403 (FIG. 3) of the handheld device 120-3. Performs functions similar to those. In addition, the companion device 124 includes a synchronization engine 505 and a companion local database 508. The client synchronization engine 505 provides functions similar to those of the synchronization engine 118 (FIG. 1) when accessing the main database 112 (FIG. 1).

  In this embodiment, sync client 501 is coupled to local database 308, transaction database 405, data store 407, and data store 409 of handheld device 120-2. This interconnection can be implemented via connection 127 (FIG. 1). Further, the sync client 501 is coupled to a sync log 503, a client sync manager 505, and a companion local database 508. In one embodiment, companion local database 508 may store an image of local database 405 of handheld device 120-2. In such an embodiment, companion device 124 may be configured to synchronize companion local database 508 with main database 112 (FIG. 1). Subsequent synchronization of the handheld device 120-2 synchronizes the local database 308 of the handheld device 120-2 with the currently synchronized companion local database 508.

Sync Client Process FIG. 6 illustrates the operation of the sync client during the sync process according to one embodiment of the invention. In this embodiment, the sync client is a handheld device that has a direct connection to the server. For example, the handheld device and server may be handheld device 120-3 (FIG. 4) and server 116 (FIG. 1). Alternatively, the sync client can be implemented by a combination of a companion device and a handheld device (eg, companion device 124 and handheld device 120-2 as in FIG. 5). For convenience, the operation of the sync client will be described with reference to handheld device 120-3 (FIG. 4) and server 116 (FIG. 1). In view of the present disclosure, those skilled in the art will appreciate that the following description applies to other types of sync clients without undue experimentation.

  Referring to FIGS. 4 and 6, one embodiment of the sync client operates as follows. At block 601, a sync client is connected to a server (a companion device in other embodiments). In one embodiment, the sync client 401 is connected to the server 116 when the user performs a login process. In one embodiment, the sync client 401 executes an interface or driver that operates the modem to directly access the server 116. In other embodiments, this connection may be an internet connection. In still other embodiments, the connection may be a wireless connection that implements a direct communication link, a web-based communication link, or other type of communication link using RF or optical technology. .

  At block 603, the sync client receives initialization data. In one embodiment, sync client 401 receives initialization data from server 116 via connection 132. As described above in connection with FIG. 2, this initialization data includes the latest version of the main database 112 (eg, the extraction ID), the latest transaction uploaded to the server 116, and the latest version of the handheld application (eg, Information related to the repository ID). In this embodiment, the sync client 401 stores initialization information in the data store 409.

  At block 605, the sync client receives an application defined version. Block 605 can be omitted if the handheld application definition is included as part of the initialization data received at block 603. In one embodiment, the server 116 sends an application defined version (which may not have been updated) to the sync client 401. The sync client 401 can compare the newly received application definition version with the application version already stored in the data store 409 (ie, the current version of the handheld application). Next, the sync client 401 stores the new application definition version in the data store 409.

  At block 607, the sync client provides transaction information to the server or companion device. In one embodiment, sync client 401 sends transaction information stored in transaction database 405 to server 116. For example, sync client 401 can send transaction information for all recorded transactions in one data block. Alternatively, sync client 401 may send transaction information in several smaller blocks and wait for receipt confirmation from server 116 before sending the next smaller block. An embodiment of this operation is described in more detail below with respect to FIGS.

  At block 609, the sync client obtains metadata from the server. In one embodiment, sync client 401 receives metadata from server 116. As described above, this metadata includes application definitions for handheld applications. In this embodiment, the sync client 401 is in the case where the application definition version received at block 605 does not match the locally stored application definition version (eg, this situation occurs when the application definition has been updated). Block 609 is executed. One embodiment of this operation is described in more detail below with respect to FIG. In another embodiment, sync client 401 does not compare application-defined versions and instead always requests metadata from server 116. Next, the server 116 determines whether the application definition needs to be updated.

  At block 611, the sync client updates its local database. In one embodiment, sync client 401 requests that server 116 initiates a data extraction operation to provide updated database data to handheld device 120-3. In this embodiment, the user can cause the sync client 401 to update the filter before obtaining database data from the server 116. For this reason, the server 116 avoids downloading unnecessary database data. This helps to conserve battery power and can reduce the time required to complete the synchronization process. In one embodiment, the server 116 downloads the entire data extract (ie, data that is visible to the sync client and filtered) in a single large block. In an alternative embodiment, the server 116 can download a relatively small block of data extraction in response to a request by the sync client 401. If handheld device 120-3 properly receives this block, sync client 401 can send a request for the next block until handheld device 120-3 receives the entire extract from server 116. And so on.

  In a further refinement, the sync client 401 can first decide whether to receive a full extract or a delta extract. For example, if the database version has changed (see block 603), the sync client 401 can request a complete extraction from the server 116. However, if the database version has not changed, the sync client 401 can request a delta extraction from the server 116. For example, in delta extraction, the server 116 compares the full extraction of the previous download to the handheld device 120-3 with the current full extraction. Server 116 then downloads only records from the current full extract that are different from the corresponding records in the previous extract.

  At block 613, the sync client is disconnected from the server (or companion device). In this embodiment, in response to input from the user, sync client 401 performs a logout process and is disconnected from server 116.

  FIG. 7 illustrates in more detail one embodiment of block 607 (FIG. 6) according to the present invention. The sync client performs the operation of FIG. In this embodiment, the sync client resides in handheld device 120-3 that has a direct connection with server 116. As in the description of FIG. 6, the transaction processing operation of block 607 will be described in the context of handheld device 120-3 (FIG. 4) and server 116 (FIG. 1). However, in view of the present disclosure, those skilled in the art will appreciate that the following description applies to other types of sync clients without undue experimentation. Referring to FIGS. 4 and 7, block 607 is performed as follows in this exemplary embodiment.

  At block 701, the sync client receives information related to the latest transaction uploaded to the server or (companion device). In one embodiment, the sync client 401 obtains a transaction identifier (transaction ID) from the server 116. This transaction ID is the identifier of the latest transaction received by the server 116. In one embodiment, handheld device 120-3, when initialized, generates a transaction ID using a pseudo-unique ID generator. In another embodiment, the ID generation is guaranteed to be unique. The sync client 401 then makes this simulation every time the handheld device 120-3 uploads information recorded about the transaction to the server 116 (also referred to herein as "uploading a transaction"). Increment the unique ID. In this embodiment, the sync client 401 then compares the received transaction ID with the transaction information in the transaction database 405 to determine unprocessed transaction information (ie, a transaction greater than the transaction ID received from the server 116). Send transaction with ID).

  At block 703, the sync client compresses the outstanding transaction to be uploaded. In one embodiment, sync client 401 compresses the transaction information using any suitable compression algorithm. The sync client 401 can then convert the compressed information into a format supported by the connection between the handheld device 120-3 and the server 116 (eg, text for use with an HTTP connection). . In an alternative embodiment, block 703 may be omitted (ie, the information need not be compressed).

  At block 705, the sync client then uploads the outstanding transaction information. In one embodiment, sync client 401 sends transaction information to server 116 in a single large block. Alternatively, sync client 401 can send transaction information in a series of smaller blocks. In one such embodiment, the server 116 provides an acknowledgment after properly receiving each smaller block from the handheld device 120-3. One embodiment of this operation is described in more detail below with respect to FIG.

  At block 707, the sync client obtains information regarding the error (if any) that occurred during block 705. In one embodiment, the server 116 keeps track of all errors that occurred while processing the transaction. For example, the error is that the transaction attempted to update a field that was updated more recently by another user that synchronized before the user of handheld device 120-3. Other examples include errors that occur when a transaction violates other data validation rules imposed by the server that are not imposed by the handheld application.

  At block 709, the sync client then processes the transaction error. In one embodiment, sync client 401 prompts the user to manually correct the error. In another embodiment, errors are provided on a separate error screen that the user can choose to view and are manually corrected or ignored.

  FIG. 8 illustrates in more detail block 705 (FIG. 7) according to one embodiment of the present invention. The sync client performs the operation of FIG. In this embodiment, the sync client resides in handheld device 120-3 that has a direct connection to server 116. As with the description of FIG. 6, the transaction processing operation of block 705 will be described in the context of handheld device 120-3 (FIG. 4) and server 116 (FIG. 1). However, in view of the present disclosure, those skilled in the art will appreciate that the following description applies to other types of sync clients without undue experimentation. Referring to FIGS. 4 and 8, block 705 is performed as follows in this exemplary embodiment.

  At block 801, the sync client 401 determines whether the transaction ID received at block 701 (FIG. 7) has been stored in the transaction database 405 (FIG. 4). If the received transaction ID is in the transaction database 405, all of the transaction records in the transaction database 405 created before the transaction corresponding to the received transaction ID have already been received by the server 116. And is therefore no longer needed. In one embodiment, sync client 401 executes block 803. At block 803, the sync client 401 deletes all of the transaction records in the transaction database 405 that have a transaction ID that is smaller than the received transaction ID (ie, created earlier).

  However, if at block 801 the sync client 401 determines that the received transaction ID is not in the transaction database 405, then any transaction records remaining in the transaction database 405 are Not received. At block 805, the sync client 401 identifies the number of outstanding transaction records stored in the transaction database 405. In one embodiment, this number is stored in a variable (referred to herein as TXNCOUNT for convenience). Block 805 is also executed after completion of block 803.

  At block 807, the sync client 401 determines whether the number of processed transaction records is less than TXNCOUNT. That is, after block 805, the number of processed transaction records in the current execution of block 705 is set to zero. As each transaction record in transaction database 405 is processed (eg, uploaded to server 116), the number of processed transaction records is incremented. When the number of processed transaction records reaches the value of TXNCOUNT, all of the transaction records in transaction database 405 are processed. If so, the process proceeds to block 809 where all of the transaction records stored in the transaction database 405 are deleted and block 705 ends.

  However, if the number of processed transaction records is less than the value of TXNCOUNT, the process proceeds to block 811 where sync client 401 obtains the next transaction record from transaction database 405.

  At block 813, the sync client 401 adds the transaction record to the transaction string or transaction message to be uploaded to the server 116. In one embodiment, sync client 401 packs the transaction record into a transaction string to be uploaded to server 116. In some other embodiments, the transaction records can be stored in the transaction database 405 as a series of small mini-transaction records (especially if the transaction is a complex transaction or a large transaction). . At block 813, sync client 401 concatenates the mini-transaction record with the existing transaction string.

  At block 815, the sync client 401 determines whether the transaction record is a mini-transaction record. For example, in one embodiment, each mini-transaction record of a transaction has the same transaction ID. The sync client 401 can determine whether the transaction record is a mini-transaction record by comparing the transaction ID of the current transaction record with the transaction ID of the previous transaction record. If the transaction record is a mini-transaction record, the operation flow loops back to block 811. However, if the transaction record is not a mini-transaction, block 817 is executed.

  At block 817, in this embodiment, the transaction string (from block 813) is URL (Universal Resource Locator) encoded so that it can be sent to the server 116 over an HTTP connection. In one embodiment, the sync client 401 URL encodes the transaction string.

  At block 819, the URL encoded transaction string is uploaded. In one embodiment, the sync client 401 places the encoded transaction string in the HTTP request header and sends it to the server 116. If the transaction string is too large (eg, greater than 2 kilobytes), the string is uploaded using multiple HTTP requests. After the transaction string is uploaded, the process returns to block 807. The process is repeated until all of the transaction records in transaction database 405 have been processed.

  FIG. 9 shows a block 609 (FIG. 6) for updating metadata according to one embodiment of the present invention. The sync client performs the operation of FIG. In this embodiment, the sync client resides in handheld device 120-3 (FIG. 4) that has a direct connection to server 116 (FIG. 1). As with the description of FIG. 6, the transaction processing operation of block 609 will be described in the context of handheld device 120-3 (FIG. 4) and server 116 (FIG. 1). However, in view of the present disclosure, those skilled in the art will appreciate that the following description applies to other types of sync clients without undue experimentation. Referring to FIGS. 4 and 9, block 609 is performed as follows in this exemplary embodiment.

  At block 901, the sync client 401 compares the repository ID stored locally (ie, stored in the data store 409) with the repository ID from the server 116 (see block 605 in FIG. 6). . The repository ID stored locally indicates the version of the handheld application that is present in the handheld device 120-3, while the repository ID from the server 116 is the handheld that the handheld device 120-3 should have. Indicates the version of the application (eg, the handheld application may have been updated since the last time the handheld device 120-3 was synchronized).

  At block 903, the sync client 401 determines whether the repository IDs match. If the repository IDs match, the handheld device 120-3 has the correct version of the handheld application and block 609 ends. However, if the repository IDs do not match, the handheld device 120-3 must be updated with the correct version of the handheld application. Thus, if the repository IDs do not match at block 903, the process proceeds to block 905.

  At block 905, the sync client 401 obtains the size of the metadata. In one embodiment, the sync client 401 obtains the metadata size from the server 116. However, this size does not represent the size that the metadata occupies within the handheld device 120-3 when downloaded and stored in the data store.

  At block 907, sync client 401 applies a scaling factor to the size received at block 905 to determine the maximum expected size of the executed metadata. In one embodiment, this scaling factor is determined empirically. In other embodiments, the scaling factor is configurable or can be determined dynamically. This scaling factor ensures that the actual size of the executed metadata is less than or equal to the expected maximum size.

  At block 909, the sync client 401 determines whether the memory available on the handheld device 120-3 is sufficient to store the metadata. In one embodiment, sync client 401 compares the expected maximum size identified at block 907 with available memory.

  If there is sufficient available memory, the sync client 401 obtains metadata from the server 116 at block 911. In one embodiment, sync client 401 pulls metadata from server 116 in one transfer. In another embodiment, sync client 401 pulls metadata from server 116 in a series of smaller transfers.

  If at block 909 there is not enough available memory, the process proceeds to block 913. At block 913, sync client 401 executes the error routine and exits block 609 gracefully. For example, the sync client 401 displays a message to the user that the handheld device 120-3 has insufficient memory available to complete the sync process, and the user deletes unnecessary files. Suggest to retry the synchronization process. In another embodiment, the error routine at block 913 prompts the user to free up memory space and returns to block 909 instead of exiting after the user has done so.

  FIG. 10 shows a block 611 (FIG. 6) for extracting database data according to one embodiment of the present invention. The sync client performs the operation of FIG. In this embodiment, the sync client resides in handheld device 120-3 (FIG. 4) that has a direct connection to server 116 (FIG. 1). As in the description of FIG. 6, the transaction processing operation of block 611 will be described in the context of handheld device 120-3 (FIG. 4) and server 116 (FIG. 1). However, in view of the present disclosure, those skilled in the art will appreciate that the following description applies to other types of sync clients without undue experimentation. Referring to FIGS. 4 and 10, block 611 is performed as follows in this exemplary embodiment.

  In block 1001, the synchronization client 401 obtains the extraction ID from the server 116. In one embodiment, sync client 401 obtains this information as part of the initialization information at block 603 (FIG. 6). This extraction ID indicates the version of the database that the handheld device 120-3 should have. In addition, handheld device 120-3 locally stores an extraction ID indicating the version of the database that currently exists in handheld device 120-3 (eg, in data store 409). These extraction IDs may be different if the database architecture has been updated since the last time handheld device 120-3 was synchronized. For example, the main database 112 (FIG. 1) may have been updated to add and / or delete fields or tables.

  At block 1003, the sync client 401 processes the filter. In one embodiment, the user may have changed the filter settings on the handheld device 120-3. As described above, the filter setting is used by the server to download only the data of the database desired by the user. One advantage of this filtering is that the filtering reduces the amount of data downloaded to a size that can fit into the memory of the handheld device 120-3. The sync client 401 can download the filter settings stored in the server 116 and use the filter settings to update the locally updated filter settings. The synchronization client 401 can also upload the filter settings changed by the user to the server 116. The server ensures that the filter settings changed by the user are valid settings. A reasonable new filter setting is used by the server when downloading data from the database to the handheld device 120-3. This filter setting is described in more detail below in connection with FIG. 10A.

  At block 1005, the sync client 401 determines whether the handheld device 120-3 has sufficient memory available to store database data downloaded by the server 116. In one embodiment, the synchronization manager 116 obtains the size of the data extraction from the server 116. As described above, the server 116 is visible to the handheld device 120-3 and is used to create an extract of the filtered database data according to the reasonable filter settings uploaded from the handheld device. Access Figure 1). The server 116 provides the size of the data extraction (full extraction or delta extraction) to the sync client 401, and then whether the sync client 401 has enough memory available inside the handheld device 120-3. Determine.

  If there is sufficient memory, sync client 401 pulls the data extraction (full or delta) from server 116 at block 1007. The sync manager 410 can pull the data extraction in a single transfer or in a series of smaller transfers. At block 1009, the sync client 401 stores the extract in the local database 308.

  However, if the handheld device 120-3 does not have enough memory available to store the extraction, block 611 ends. For example, sync client 401 executes an error routine similar to block 913 (FIG. 9) and ends block 611 gracefully.

  In block 1011, the synchronization client 401 obtains a new extraction ID from the server 116. The synchronization client 401 can omit the block 1011 when the extraction ID stored locally is the same as the extraction ID received from the server 116 in the block 1001.

  FIG. 10A shows the filter described in block 1003 (FIG. 10) according to one embodiment of the invention. In this embodiment, the filter is associated with the screen defined by the metadata (described above in connection with FIGS. 3 and 9). As described above, the screen is displayed by a handheld application running on the handheld device to provide a user interface to the local database of the handheld device. For example, the screen may display data from a selected group of databases in a format / configuration that allows the user to more easily use and understand the data.

  As shown in FIG. 10A, the filter has a plurality of screens denoted SCREEN_1 through SCREEN_M. When the handheld application is running, the user can move various screens to display the desired database data on the handheld device. Each screen has at least one business object. For example, the screen SCREEN_1 has several business objects shown as BUSOBJ_1 to BUSOBJ_N. The business object is preconfigured to define group related data to be displayed by the handheld device. Screens are defined to have only one business object per screen to simplify the processing in block 1003 (FIG. 10).

  FIG. 11 shows a block 1003 (FIG. 10) for processing a filter according to one embodiment of the invention. In this embodiment, the sync client performs the operation of block 1003. In this embodiment, the sync client resides in handheld device 120-3 (FIG. 4) that has a direct connection to server 116 (FIG. 1). As in the description of FIG. 10, the operation of block 1003 will be described in the context of handheld device 120-3 (FIG. 4) and server 116 (FIG. 1). However, in view of the present disclosure, those skilled in the art will appreciate that the following description applies to other types of sync clients without undue experimentation. Referring to FIGS. 4 and 11, block 1003 is performed as follows in this exemplary embodiment.

  At block 1101, the sync client 401 downloads filter information from the server 116 (FIG. 1). This filter information includes the filter settings that the server 116 used for the sync client 401 in the previous sync operation. Further, this filter information may include updates to the filters provided by the system administrator, by the sync client 401 vendor, or by the sync engine 118 (FIG. 1). The filter information includes (a) a screen identifier, (b) an identifier of a business object associated with each screen, (c) a filter associated with each business object, and the like. Because each screen has only one associated business object, the filter information can be downloaded as a file containing only the screen and its associated filter. In this embodiment, the downloaded file is temporarily stored in handheld device 120-3 (FIG. 1) for access by sync client 401.

  At block 1103, the sync client 401 obtains a locally stored filter setting file (also referred to herein as a filter setting file). This filter settings file may contain filter settings that have been changed by the user after the previous synchronization operation. The sync client 401 can then access its filter settings during block 1103.

  At block 1105, the sync client 401 updates the filter information to include information from both the filter configuration file and the filter information downloaded at block 1101. Furthermore, the sync client 401 can also update the filter information using default filter settings for the business object. In one embodiment, the sync client 401 includes a component (eg, a dialog) that allows the user to select a filter setting. For example, the component can display a screen with a menu that allows the user to make filter setting selections. Thereafter, the next screen is displayed so that the user can change the settings as desired. This is repeated until all of the screen is displayed. The filter setting file is updated to reflect the filter setting selection.

  At block 1107, the sync client 401 updates the filter setting file to include the updated filter information. This updated filter settings file is stored locally in the handheld device 120-3.

  At block 1109, the sync client 401 provides the updated filter information to the server 116. In one embodiment, sync client 401 uploads updated filter information to server 116 in the form of an XML string. Before the synchronization client 401 sends the filter setting information to the server 116, the XML string is URL-encoded. In other embodiments, the filter information is in the form of a packed string with pre-selected characters used to link the business object with the filter settings and to indicate the next business object. .

  FIG. 12 illustrates in more detail blocks 1103, 1105, 1107 (FIG. 11) according to one embodiment of the present invention. In this embodiment, the sync client performs the operation. In one embodiment, the sync client resides in handheld device 120-3 (FIG. 4) that has a direct connection to server 116 (FIG. 1). As with the description of FIG. 11, the operation of blocks 1103, 1105, and 1107 will be described with respect to handheld device 120-3 (FIG. 4) and server 116 (FIG. 1). However, in view of the present disclosure, those skilled in the art will appreciate that the following description applies to other types of sync clients without undue experimentation. Referring to FIGS. 4 and 11, blocks 1103, 1105, 1107 are performed as follows in this exemplary embodiment.

  At block 1201, the sync client 401 analyzes the downloaded filter information (see block 1101 in FIG. 11). In one embodiment, the downloaded filter information is in the form of an XML encoded stream. The synchronization client 401 sets up a data structure for storing filter information analyzed from the downloaded information. In one embodiment, the data structure is a linked list. In another embodiment, the data structure is a markup language file such as, for example, XML, SGML, or HTML.

  At block 1203, sync client 401 searches for the next screen in the parsed downloaded filter information. If sync client 401 finds a screen, block 1205 places the screen in the data structure. For example, in the linked list embodiment, sync client 401 can create a link for the found screen. In the XML embodiment, the sync client 401 creates a tag or attribute for the screen.

  At block 1207, sync client 401 searches for the next business object associated with the screen of block 1203. If sync client 401 finds a business object, block 1209 places the business object in a data structure with a mechanism that indicates the relationship between the business object and the screen. Continuing with the linked list example described above, the sync client 401 can create a link from the screen found at block 1203 to the business object found at block 1207. In an XML embodiment, the sync client 401 can create a tag or attribute for a business object.

  At block 1211, the sync client 401 searches for the next filter associated with the business object at block 1207. If sync client 401 finds a filter, block 1213 places the filter in the data structure. Continuing with the linked list example described above, sync client 401 creates a link from the business object found at block 1207 to the filter found at block 1211. In the XML embodiment, the sync client 401 creates a tag or attribute for the filter. As described above in connection with FIG. 10A, a business object has a plurality of filters. However, in this embodiment, only one filter is active at a time.

  At block 1215, sync client 401 determines whether an active filter for the business object found at block 1207 has been selected. In one embodiment, the data structure includes a separate “active filter” pointer that points to the active filter corresponding to the business object found at block 1207. The sync client 401 checks whether this pointer is filled (ie, pointing to an address). If the pointer is empty, no active filter is selected for the business object.

  If an active filter has been selected, operation flow returns to block 1211 to search for the next filter. However, if no active filter is selected, the sync client 401 determines at block 1217 whether the filter found at block 1207 is the default filter. If so, at block 1219, sync client 401 sets the filter as the default filter. For example, sync client 401 reads an “active filter” pointer with a default filter address, and the operational flow returns to block 1211. If, at block 1217, the filter is not the default filter, operation flow returns to block 1211 to look for the next filter.

  Returning to block 1207, if the sync client 401 cannot find the next business object, the operation flow proceeds to block 1221. For example, sync client 401 can find a default filter for the current business object (ie, found in the previous execution of block 1207) if all of the business objects for the screen have been found or sync client 401 has found it. If not, you may not be able to find the next business object. At block 1221, sync client 401 determines whether an active filter has been selected for the current business object. If sync client 401 determines that an active filter has been selected (eg, if all of the filters for the current business object have been found and one is the default filter), the flow of operations is blocked Returning to 1203, the next screen is searched. However, if sync client 401 determines that no active filter is selected (eg, no filter is found for the current business filter, or none of the found filters are the default filter). The operation flow proceeds to block 1223.

  At block 1223, sync client 401 searches for the found filter (s) for the current business object for a filter that is not an “no filter” filter (ie, one or more of blocks 1211-1219). By repeating). More specifically, as described above, a business object may not have an active filter. In that case, this embodiment uses a “no filter” filter to indicate that the business object does not have an active filter. If the sync client 401 finds a filter that is a “no filter” filter among the found filter (s) at block 1223, the sync client 401 selects the filter as an active filter at block 1225.

  However, if at block 1223 no such filter is found, operation flow proceeds to block 1227. In one embodiment of block 1227, the sync client 401 searches for the filter (s) found for an “no filter” filter. If sync client 401 finds a “no filter” filter, it selects that filter as the active filter at block 1229. However, if at block 1227 the sync client 401 fails to find a “no filter” filter, then no active filter is selected, as shown at block 1231. After either block 1229, 1231, the operational flow returns to block 1203 to look for the next screen.

  If, at block 1203, sync client 401 has not found a screen (eg, all of the screen has been found in a previous iteration of block 1203), operation flow proceeds to block 1240. In this embodiment of block 1240, the sync client 401 obtains the filter settings file (see block 1103 above). As described above, the filter setting file also includes filter settings changed by the user after the previous synchronization operation. In this embodiment, the filter settings include an activated filter (ie, business object / filter pair) associated with each business object.

  At block 1242, sync client 401 parses the next business object / filter pair from the filter configuration file. The sync client 401 loops back to block 1242 until all of the business object / filter pairs are parsed from the filter configuration file (as described below).

  At block 1244, the sync client 401 determines whether the business object / filter pair is empty (ie, no active filter has been selected in the previous sync operation). If the business object / filter pair is empty, operation flow returns to block 1242 to parse and retrieve the next business object / filter pair.

  However, if at block 1244 the sync client 401 determines that the business object / filter pair is not empty, the operation flow proceeds to block 1246. At block 1246, the sync client 401 searches the data structure for the business object indicated by the business object / filter pair (see blocks 1205-1213). Block 1246 is useful because the business object may no longer exist, for example, in a handheld application update. If the sync client 401 does not find a business object in the data structure at block 1246, the operational flow returns to block 1242 to parse and retrieve the next business object / filter pair.

  However, if the sync client 401 finds a business object at block 1246, the operation flow proceeds to block 1248. At block 1248, the sync client 401 searches the data structure described above for the filter. As described above with respect to business objects, filters may no longer exist due to handheld application updates. If, at block 1248, sync client 401 fails to find a filter in the data structure, operation flow returns to block 1242 to parse and retrieve the next business object / filter pair. However, if sync client 401 finds a filter in the data structure, it sets the found filter as the active filter at block 1250. The operation flow then returns to block 1242 where the next business object / filter pair is parsed and retrieved.

  The operational flow of the embodiment of FIG. 12 actually retrieves the latest filter settings stored in the server for the sync client and then resets the filter settings to the default active filter. It then updates the default active filter for business objects and filters using the locally stored user settings from the previous sync operation. This embodiment helps to ensure that the filter settings are correct when the handheld application is updated.

  FIG. 13 shows a block 1007 (FIG. 10) for extracting data according to one embodiment of the present invention. In this embodiment, the sync client performs the operation of block 1007. As with the description of FIG. 10, the operation of block 1007 will be described in the context of handheld device 120-3 (FIG. 4) and server 116 (FIG. 1). However, in view of the present disclosure, those skilled in the art will appreciate that the following description applies to other types of sync clients without undue experimentation. Referring to FIGS. 4 and 13, block 1007 is performed as follows in this exemplary embodiment.

  In block 1301, the synchronization client 401 obtains the extraction ID downloaded from the server 116 and the extraction ID stored locally for comparison. As described above, the extraction ID identifies the database extraction version. For example, when the database structure on the server 116 is changed, both extraction IDs are different.

  In block 1303, the synchronization client 401 determines whether the extracted ID stored locally matches the downloaded extracted ID. If the extraction IDs match, the operation flow proceeds to block 1305. At block 1305, the sync client 401 requests delta extraction from the server 116. As described above, delta extraction includes only database data that has changed since the last synchronization operation. For example, in one embodiment, for each sync client, a sync engine (eg, sync engine 118 or 128 in FIG. 1) maintains a copy of the extract after each sync operation. Next, during the current sync operation, the sync engine (eg, sync engine 118 or 128) retrieves a full extract for the sync client from main database 112 (FIG. 1). In the case of delta extraction, the sync client 401 compares the stored extract with the full extract retrieved from the main database 112 and transmits only the database data that has changed to the sync engine (118 or 128). This delta extraction is then received by the sync client 401.

  Conversely, if the sync client 401 determines in block 1303 that the two extraction IDs do not match, the operation flow proceeds to block 1307. At block 1307, sync client 401 requests a complete extraction from server 116. Server 116 then provides a full extract, which is received by sync client 401.

  FIG. 14 illustrates a compression operation according to one embodiment of the present invention. This compression operation can be performed by a sync client (eg, sync client 401 of FIG. 4) or a server (eg, server 114 or 116 of FIG. 1). For example, this compression operation can be performed by server 116 before sending database data (eg, delta extraction) to sync client 401. This compression algorithm can also be used by the sync client 401 to send information back to the server 116. For example, this compression operation can be used to implement block 703 (FIG. 7). This compression operation reduces the time required to transfer information between the server and the sync client.

  At block 1401, the information to be transmitted is compressed. In one embodiment, the information is binary data such as database data, transaction data or metadata. Any suitable compression algorithm can be used. In one embodiment, the binary information is www. info-zip. Compressed using the ZIP 2.3 compression utility available from org. In other embodiments, other compression algorithms can be used.

  At block 1403, the compressed binary data is converted to text. In one embodiment, the compressed binary data is converted to text using standard Base64 encoding. Conversion to text helps to reduce data corruption during the transmission process. In a further refinement, the text data may include markup using a markup language such as XML (Extensible Markup Language) or HTML (Hypertext Markup Language).

  At block 1405, the text data generated at block 1403 is encoded using a protocol for the connection between the server and the sync client. In one embodiment, standard hypertext transfer protocol (HTTP) is used to encode text data for transmission over the Internet. In other embodiments, different protocols can be used depending on the nature of the connection between the server and the sync client. For example, in other embodiments, text data can be File Transfer Protocol (FTP) encoded. This compressed and encoded information is then sent to the destination recipient. In some embodiments, block 1403 can be omitted, with block 1405 encoding the compressed binary data from block 1401 instead of text.

  In a further refinement of this operation, the information sent can be divided into smaller units, which are then separately compressed and encoded according to blocks 1401, 1403, 1405. Before this smaller unit is sent separately to the recipient to receive the next unit of information, the recipient stores (a) the compressed information unit and (b) the stored compressed information. Decompress the unit, (c) store the decompressed information unit, and (d) delete the compressed information unit. This improvement reduces the amount of available memory that the recipient needs to properly receive and decompress the transmitted information.

Server Process FIG. 15 illustrates a server synchronization process according to one embodiment of the invention. In this embodiment, the server is connected to a sync client. For example, the sync client resides in a handheld device that has a direct connection to the server. In one embodiment, the handheld device and server may be handheld device 120-3 (FIG. 4) and server 116 (FIG. 1). Alternatively, the sync client can be implemented by a combination of a companion device and a handheld device (eg, companion device 124 or handheld device 120-2 as in FIG. 5). For convenience, server operation will be described in the context of server 116 (FIG. 1) and handheld device 120-3 (FIG. 4). In view of the present disclosure, those skilled in the art will appreciate that the following description applies to other types of sync clients without undue experimentation.

  4 and 15, one embodiment of the server operates in cooperation with the synchronization client as follows. At block 1501, the server is connected to the sync client. The sync client can reside in a companion device in some embodiments. In this embodiment, the server 116 is connected to the sync client 401 in response to the user logging in. In one embodiment, the server 116 executes an interface or driver that operates a modem to directly access the sync client 401. In other embodiments, the connection is an internet connection. In yet other embodiments, the connection is a wireless connection that implements a direct, web-based, or other type of communication link using RF or optical technology.

  At block 1503, the server downloads initialization data to the sync client. In one embodiment, server 116 downloads initialization data to sync client 401 via connection 132. As described above, this initialization data includes the latest version of the main database 112 (eg, the extraction ID), the identifier of the latest transaction uploaded to the server 116 by the sync client 401, and the latest version of the handheld application (eg, Information related to the repository ID).

  At block 1505, the server receives transaction information from the sync client. In one embodiment, the server 116 receives transaction information from the sync client 401 and stores the transaction information in a memory (not shown) of the computer system (FIG. 1). For example, the server 116 receives transaction information for all recorded transactions from the sync client 401 in one relatively large block of data. Alternatively, the server 116 may receive transaction information from the sync client 401 in several smaller blocks. In this alternative embodiment, after receiving each smaller block, the server 116 provides an acknowledgment to the synchronization client 401 that informs the synchronization client 401 to send the next smaller block.

  At block 1507, the server sends metadata to the sync client. In one embodiment, server 116 sends metadata to sync client 401. As described above, this metadata includes application definitions for handheld applications. In this embodiment, the server 116 executes block 1507 in response to a request from the sync client 401. As described above, the sync client 401 requests metadata if the application stored in the server 116 (from the latest sync operation) does not match the application definition version stored locally. This situation can occur if the application definition has been updated since the last synchronization operation. In another embodiment, sync client 401 is configured to always request metadata during sync operations without comparing versions. In this alternative embodiment, the server 116 determines whether the application definition has been updated since the last synchronization operation, and if so, sends metadata to the synchronization client 401. In a further refinement of this alternative embodiment, the server 116 automatically performs the above operations without waiting for a request from the sync client 401 and synchronizes the metadata if the application definition has been updated. It can be pushed to the client 401.

  At block 1509, the server updates the sync client's local database. In one embodiment, the server 116 receives a request from the sync client 401 and initiates a data extraction operation. In this embodiment, the server 116 can receive updated filter settings (see description of FIGS. 11 and 12 above) prior to performing a data extraction operation. Thus, the server 116 avoids downloading data, unnecessary database data, which helps to conserve battery power and reduce the time required to complete the synchronization process. . In one embodiment, the server 116 downloads the entire data extract (ie, data that is visible to the sync client and filtered) in a single large block. In an alternative embodiment, server 116 may download a relatively small block of data extracts in response to a request by sync client 401. If sync client 401 properly receives this relatively small block, sync client 401 sends a request for the next relatively small block, and so on until sync client 401 receives the entire data extraction from server 116. To be done. This data extraction can be a full extraction or a delta extraction (described in more detail below in connection with FIG. 16).

  At block 1511, the server is disconnected from the sync client. In this embodiment, the server 116 is disconnected from the sync client 401 in response to a logout process initiated by the user (or automatically performed by the sync client 401 upon completion of the sync operation). In an alternative embodiment, the server 116 is automatically disconnected from the sync client 401 after performing the operation of block 1509.

  FIG. 16 shows block 1509 (FIG. 15) according to one embodiment of the invention. In this embodiment, the server performs the operation of block 1509. As in the description of FIG. 15, the operation of block 1509 will be described in the context of handheld device 120-3 (FIG. 4) and server 116 (FIG. 1). However, in view of the present disclosure, those skilled in the art will appreciate that the following description applies to other types of sync clients without undue experimentation. Referring to FIGS. 4 and 16, block 1509 is performed as follows in this exemplary embodiment.

  At block 1601, the server 116 extracts data from the main database 112 that is visible to the sync client 401. Further, the server 116 filters the data according to the filter settings provided to the server 116 by the sync client 401 (described in connection with FIGS. 11 and 12).

  At block 1603, the server 116 saves the extracted data file in memory (not shown) for later use in later synchronization operations. At block 1605, the server 116 compares this extraction with a file containing extracted data from a previous synchronization operation. If the data from the corresponding database record is different, at block 1607, the server 116 saves the data from the newer extract (ie, “delta”) in another file referred to herein as a delta extract file. To do. In one embodiment, when the delta extract is received by sync client 401, server 116 stores each delta as a record / data pair that can be parsed from the delta extract. In this embodiment, reserved delimiters separate the fields in each record, and different reserved delimiters separate the records. In one embodiment, an escape mechanism can be used to cause these reserved delimiters to appear with the record field value. Further, in some embodiments, the delta extraction file may include an indicator for each record / data pair that indicates whether the record has been deleted, new, or modified.

  In a further refinement, delta extraction is performed at the field level rather than the record level (which may include several fields) to further reduce the size of the delta extraction file.

  Next, at block 1609, the server 116 determines whether to download a full extract or a delta extract to the sync client 401. In one embodiment, server 116 receives a request from sync client 401 for a full or delta extraction. As described above, in one embodiment, the sync client 401 makes this request based on whether the extract ID downloaded from the server 116 matches the extract ID stored locally by the sync client 401. In one exemplary embodiment, if the structure of the local database 308 has changed since the last synchronization operation (eg, due to changes in the main database 112 or visibility rules), both extractions The IDs are different and the sync client requests a complete extraction. If the structure of the local database 308 has not changed, both extraction IDs are the same and the sync client 401 requests delta extraction. Depending on the result of block 1609, the server 116 sends a full extract or a delta extract to the sync client 401 at block 1611 or 1613, respectively.

  In another embodiment, the server 116 receives the extraction ID stored locally from the sync client and compares the received extraction ID with the latest extraction ID stored in the server 116. For example, the server 116 can request the data from the sync client 401, or this can be a data extraction process (eg, the sync client provides its own local extract ID instead of the extract ID). May be part of block 1101 in FIG. Server 116 can then determine whether to download a delta extract or a full extract as appropriate. For example, the server 116 may execute blocks 1301 and 1303 (FIG. 13) instead of the synchronization client 401.

  In a similar manner, the server 116 receives the repository ID when determining whether to provide metadata to the sync client 401 (see block 609 in FIG. 6). For example, the server 116 can request the data from the sync client 401 or it can be part of the data extraction process (eg, instead of getting the repository ID, the sync client is stored locally in its own Other than providing a repository ID that is similar to block 605 in FIG. The server 116 can then determine whether to download the metadata. For example, server 116 is configured to execute blocks 901 and 903 (FIG. 9) on behalf of sync client 401.

  The above description of illustrated embodiments of the invention, including what is described in the abstract, is not intended to be exhaustive or to limit the invention to the precise forms disclosed. While particular embodiments and examples of the present invention have been described herein for purposes of illustration, various equivalent modifications are possible within the scope of the present invention, as will be appreciated by those skilled in the art.

  In light of the above detailed description, these changes can be made to the invention. The terms used in the following claims should not be construed to limit the invention to the specific embodiments disclosed in the specification and the claims. Rather, the scope of the present invention is to be determined entirely by the following claims, which are to be construed in accordance with established principles of claim interpretation.

1 is a block diagram illustrating a system having a main database that a user can access via a handheld device according to one embodiment of the present invention. FIG. FIG. 4 illustrates data flow between a handheld device and another computer system according to one embodiment of the invention. FIG. 3 is a top-level block diagram illustrating server and client components used in synchronizing a handheld device according to an embodiment of the present invention. FIG. 2 is a more detailed block diagram illustrating components of a handheld device used in synchronizing a handheld device directly with a server according to one embodiment of the present invention. FIG. 3 illustrates a companion device and components of a handheld device used in synchronizing a handheld device with a server via a companion device according to an embodiment of the present invention. 5 is a flow diagram illustrating a client synchronization process according to an embodiment of the invention. 3 is a flow diagram illustrating a transaction processing operation according to one embodiment of the invention. 4 is a flow diagram illustrating a send transaction operation according to one embodiment of the invention. 5 is a flow diagram illustrating a metadata update operation according to an embodiment of the present invention. 4 is a flow diagram illustrating a data extraction operation according to an embodiment of the present invention. It is a figure which shows the filter by one Embodiment of this invention. FIG. 5 illustrates a filtering operation according to one embodiment of the present invention. 5 is a flowchart illustrating in more detail a filtering operation according to an embodiment of the present invention. 4 is a flow diagram illustrating a data extraction operation according to an embodiment of the present invention. 4 is a flow diagram illustrating a compression operation according to an embodiment of the present invention. 5 is a flow diagram illustrating a server synchronization process according to an embodiment of the invention. 4 is a flow diagram illustrating a database data transfer operation according to an embodiment of the present invention.

Claims (19)

A method of synchronizing the first and second databases of the server and handheld device, respectively,
Receiving, via a data connection, filter information from a sync client, the server being a software process executing on the handheld device;
The server filtering the first database based on the filter information;
The server creating a file storing filtered data of the first database, wherein the filtered data stored in the file is all data stored in the first database; And the creating step, which is a copy of some of the data,
Said server comparing said filtered data with data of a previously created file, wherein said previously created file synchronizes said first and second databases during said previous operation. The comparing comprising a copy of the data of the first database filtered by
The server transmits only a subset of the filtered data to the sync client, the subset including the filtered data of the file that is not comparable to the data of the previously created file. Comprising a step . The server according to claim 1 structure of the first database further comprises the steps determines whether the updated O Bae subsequent translation of the last synchronizing the first and second database the method of. It said first structure determining whether the updated since the last the Operation synchronizing the first and second database database,
The server, the synchronization client structure shown to information of the first database stored in the handheld device when the first and last the Operation synchronizing the second database is performed Receiving steps from
Said server The method of claim 2 including the step of comparing the information indicating the current structure of the information indicating the structure of the first database. The method of claim 1 whether the application is updated running Rubeki further comprising determining the server on the handheld device. Wherein determining whether the application is updated Rubeki running on handheld devices,
The server indicating a version of an application running on the handheld device and receiving information stored on the handheld device from the sync client;
Claims, including a step in which the server is compared with the information indicating the current version of the application that the information indicating the version of the application running is not running on the handheld device on the handheld device 4. The method according to 4 . The server, the information of the transaction that the user performs on the second database via the handheld device, comprising: receiving from the synchronization client, Ru is performed for the second database transaction The step of receiving the information of
A step wherein the server, that receive an identifier of a transaction received Recently provided to the synchronization client,
Said server The method of claim 1, the transaction information including the identifier of each transaction made after transactions received of said date and a step of receiving from the synchronization client. Receiving information of a transaction that will be performed on the second database,
When a transaction error is detected, The method of claim 6 step further including up to send the error information to the synchronization client. A system for synchronizing the first and second databases of the server and the handheld device, respectively;
Means for receiving user-specific filter information from the sync client;
Means for instructing the data may look to the user of the handheld device within the first database,
It means for filtering the instruction information based on the user-specific filter information,
Means for storing a copy of this filtered data in a file;
Means for comparing the filtered data stored in the file with data of a previously created file, wherein the previously created file is filtered during a previous operation of synchronizing the first and second databases; Said means for comparing comprising a copy of said first database data
And means for transmitting only a subset of the filtered data to the synchronization client, wherein the subset comprises the filtered data of the file which is not comparable to the data of the file that was previously created, composed of a means for the transmission System. The system of claim 8 further comprising a determining means for determining whether the structure of the first database is updated O Bae subsequent translation of the last synchronizing the first and second databases. Wherein said means for determining whether the updated since the last the Operation of the structure of the first database synchronizing the first and second databases,
It means for receiving said first and structure shown to information of the first database stored in said handheld device when the previous operation to be synchronized is executed a second database,
10. The system of claim 9 , comprising means for comparing information indicative of the structure with information indicative of a current structure of the first database . The system of claim 9 applications running on the handheld device further comprises means for determining whether the updated by Rubeki. Said means for determining whether the said application updates running Rubeki on handheld devices,
It indicates the version of the application running on the handheld device, and means for receiving a pre-Symbol information stored in the handheld device,
The system of claim 11 including means for comparing the information indicating the current version of the application that is not running the stored information on the handheld device. The information of the transaction that the user performs on the second database via the handheld device, comprising: means for receiving from the synchronization client, receives information of the transaction that will be performed on the second database means,
Means for providing an identifier for the latest received transaction;
10. The system of claim 9 , further comprising means for receiving transaction information including an identifier for each transaction performed after the most recently received transaction. Means for receiving information of transactions executed on the second database;
14. The system of claim 13 , further comprising means for sending error information to the sync client when a transaction error is detected. When executed by a computer,
An operation in the first database indicating data visible to a user of a handheld device that includes the second database ;
And operations of filtering the instruction data based on the user-specific filter information,
An operation to store a copy of this filtered data in a file;
An operation of comparing the filtered data stored in the file with data of a previously created file, wherein the previously created file is synchronized during a previous operation of synchronizing the first and second databases. The comparing operation comprising a filtered copy of the first database data;
A operation of transmitting a subset of the filtered data to the synchronization client, wherein the subset comprises the filtered data of the file which is not comparable to the data files created last time, to perform the operations that the transmission A machine-readable medium that stores multiple instructions. Wherein the plurality of instructions, when executed by the computer, not to the computer, or the structure of the first database is updated O Bae subsequent translation of the last synchronizing the first and second database The machine-readable medium of claim 15 , further comprising instructions for performing an operation to determine whether. The instruction is executed by the computer running the first and the operation determines whether the structure of the first database to turn Bae subsequent translation of the last synchronizing is updated second database When the computer
The receive structure of the first database stored on the handheld device to indicate to information from the synchronization client when the first and the last the Operation synchronizing the second database is performed Operations,
Machine-readable medium of claim 16 comprising instructions to perform the operations to be compared with the information indicating the current structure of the information indicating the structure of the first database. Wherein the plurality of instructions, when executed by the computer, further comprising the computer, an instruction to perform the determining operation whether the application is updated running Rubeki on the handheld device The machine-readable medium of claim 15 . Wherein the instructions, when executed by the computer to perform the operation for determining whether or not the application is updated Rubeki, the computer,
And operations shows the version of the application running on the handheld device, and to receive the pre-Symbol information stored in the handheld device report from the synchronization client,
Machine-readable medium of claim 18 comprising instructions to perform the operations to be compared with the information indicating the current version of the application that is not running the information on the handheld device.

Images