System and method for wireless hot-synchronization of a personal digital assistant

[0002] —Not Applicable—

[0003] —Not Applicable—

[0004] The present invention is related to the field of digital data communications between devices for the purpose of maintaining data synchronization.

[0005] A Personal Digital Assistant (PDA) is a portable electronic device that accepts and stores information in one or more databases resident in onboard memory. These databases may include data used for an appointment calendar, for example, or an address/telephone book. The information may be for either personal or business use. A PDA user often maintains these databases on a host system, such as a personal computer, as well as on the PDA. By doing so, the user may achieve greater flexibility in the use and updating of database information.

[0006] It is generally desirable that the PDA database and the host system database contain the same information, in order to prevent the inadvertent use of “stale”, or outdated, information. Thus, it is necessary to “synchronize” the databases periodically, i.e., to reflect changes that have been made in one database in the other. It is possible to maintain synchronization by manually copying changes from one database to the other. However, this process can be cumbersome, tedious and error-prone, and therefore in many cases is preferably avoided.

[0007] There are existing systems that are designed to accomplish synchronization between a PDA database and a host system database automatically, using synchronization software and/or hardware. For example, in one currently available system, a user synchronizes a PDA database with a host system database by installing the PDA into a special “cradle” connected to the host system and executing a “hot-sync” process. The PDA and host system exchange data that reflects the changes made to the respective databases since the last synchronization. Each system modifies its respective database accordingly, so that upon completion of the synchronization process the respective databases are identical.

[0008] Synchronization procedures such as described above may be inconvenient for a user, because of the requirement that the PDA be placed in a cradle that is physically connected to the host system. The user may find it difficult or impossible to return to the cradle to synchronize the databases. For example, the user may be a “mobile” user, such as a salesperson, who remains away from the host system for extended periods. In such a case, the user is required to either transfer changes manually, or to use the PDA and/or host system databases in an unsynchronized manner, running the risk of using stale information.

[0009] In accordance with the present invention, a method and system for wireless hot-synchronization of a Personal Digital Assistant (PDA) device with a host system is disclosed. The system avoids the use of a cradle tethered to the host system, along with the attendant inconvenience.

[0010] The disclosed system includes a hot-sync server that establishes a wireless hot-sync channel between a PDA and a host system, such as a personal computer. The PDA includes a wireless transceiver, such as a radio-frequency (RF) transceiver, for communication over a wireless link with the hot-sync server also having a wireless transceiver. The host system and hot-sync server are communicatively coupled to each other, for example via a local area network (LAN). Upon receiving a hot-sync request over the wireless link from the PDA, the hot-sync server establishes a network connection with the host system. The PDA and host system then exchange data packets over the hot-sync channel that includes the wireless channel between the PDA and the hot-sync server and the network connection between the hot-sync server and the host system. Preferably, the data exchange is performed using a standard communication protocol.

[0011] In general, the hot-sync system can support synchronization among a number of PDAs and respective host systems. The system may rely on a single hot-sync server or on multiple servers, to provide increased capacity and/or to enhance system availability. The hot-sync system can enhance the usability of PDAs and similar untethered devices, providing database users with accurate data while reducing physical constraints imposed on the synchronization process.

[0012] Other aspects, features, and advantages of the present invention are disclosed in the detailed description that follows.

[0013] The invention will be more fully understood from the following detailed description taken in conjunction with the accompanying drawings in which:

[0014] FIG. 1 is a block diagram of a wireless hot-sync system;

[0015] FIG. 2 is a more detailed block diagram of the wireless hot-sync system of FIG. 1;

[0016] FIG. 3 is a timing diagram of messages exchanged during a hot-sync operation executed by the wireless hot-sync system of FIGS. 1 and 2;

[0017] FIG. 4 is a state diagram depicting the operation of a hot-sync state machine in a Personal Digital Assistant (PDA) in the wireless hot-sync system of FIGS. 1 and 2;

[0018] FIG. 5 is a state diagram depicting the operation of a hot-sync state machine in a hot-sync server in the wireless hot-sync system of FIGS. 1 and 2; and

[0019] FIG. 6 is a state diagram depicting the operation of a hot-sync state machine in a host system in the wireless hot-sync system of FIGS. 1 and 2.

[0020] A wireless Personal Digital Assistant (PDA) hot-sync system is illustrated in FIG. 1. The system comprises one or more hot-sync servers 10, one or more PDA devices 12, and a plurality of host systems 14. The servers 10 and host systems 14 are communicatively coupled to a local area network (LAN) 16. The PDA 12 includes function keys 18 and a touch screen 20 for viewing, manipulating, and modifying database information stored in the PDA 12. The PDA 12 and hot-sync server 10 communicate over a wireless link 22 using a standard communication protocol, such as the IEEE standard 802.11 protocol or an emerging wireless communication protocol referred to by the name “Bluetooth”. The circuitry implementing the communication protocol may be integral to the PDA 12, or it may be implemented in an external device or a plug-in module, for example. The hot-sync server 10 may be directly connected to the LAN 16, or it may connect to the LAN 16 through other devices such as network routers (not shown). The host system 14 may be a personal computer, or a network server that maintains a database for use by multiple network users, for example.

[0021] As shown in FIG. 1, a hot-sync operation employs three channels as follows: a channel 24 between the PDA 12 and the hot-sync server 10 carried on the wireless link 22, a channel 26 between the hot-sync server 10 and the host system 14 over the LAN 16, and a channel 28 between the host system 14 and the PDA 12, which is carried over the LAN 16 and the wireless link 22. The manner in which these channels are established and used is described below.

[0022] FIG. 2 shows elements of a PDA 12, a hot-sync server 10, and a host system 14 in more detail. A PDA hot-sync state machine 30 is implemented in software or firmware stored in PDA memory 32 and executed by an on-board processor (not shown). The PDA hot-sync state machine 30 maintains several timers 34, described below, that are used in the synchronization process. The PDA 12 also includes a wireless transceiver 36 for communicating the hot-sync server 10. Transceiver communication may be accomplished using radio-frequency, microwave, infrared or other wireless transmission schemes capable of supporting the specified communication protocol.

[0023] A server hot-sync state machine 40 is implemented in software stored in server memory 42 and executed by a processor (not shown). The server hot-sync state machine 40 maintains timers 44 that are used in the synchronization process. The hot-sync server 10 includes a wireless transceiver 46 for communicating with the PDA 12, and also includes a network interface 48 for communicating directly or indirectly with the host system 14. The network interface 48 may use any of a variety of conventional network protocols, such as the Ethernet protocol.

[0024] In the host system 14, a host system hot-sync state machine 50 is likewise implemented in software, which is stored in host system memory 52 and executed by a processor (not shown). The host system hot-sync state machine 50 maintains a single timer 54 used during the synchronization process. The host system 14 includes a network interface 56 for communicating with the hot-sync server 10 and the PDA 12 via the LAN 16.

[0025] FIG. 3 shows a sequence of messages used to carry out a hot-sync operation in the PDA hot-sync system. As shown, there are three distinct phases of operation: an Open Channel phase during which a hot sync channel between the PDA 12 and the host system 14 is created; a Use Channel phase during which data packets are exchanged between the PDA 12 and the host system 14 to synchronize the respective databases; and a Close Channel phase during which the hot-sync channel is de-established.

[0026] The process begins when the PDA 12 transmits a synchronization request (SYNC REQ) message. The SYNC REQ message indicates that the PDA 12 desires to perform a hot-sync operation with one of the host systems 14. The target host system 14 is identified in the SYNC REQ message, preferably by a name that is mapped to a network address by a distributed name service. It may be possible in alternative embodiments to identify the target host system 14 in other ways, for example by using a directory that maps the identity of the requesting PDA 12 to the identity of the target host system 14.

[0027] The hot-sync request message includes a “well-known” multicast address to which the servers 10 listen. Each hot-sync server that receives the SYNC REQ message sends a connection request (CONN REQ) message to the designated host system 14, requesting that the host open a connection to be used for a hot-sync operation. The host first determines if it is able to participate in the requested hot-sync operation. The host's ability to participate may be affected by, for example, the availability of network connections or other host resources, and may also depend on the satisfaction of some security criteria, such as verifying the identity of the requesting PDA 12. If the host system 14 decides not to grant the hot-sync request, it takes no further action, and the requesting PDA 12 ultimately times out (see below). Otherwise, the host system 14 returns a connection accepted (CONN ACPTD) message to the hot-sync server 10. The hot-sync server 10 then sends a service offered (SVC OFFRD) message to the PDA 12, indicating that the requested hot-sync operation can be performed via the responding hot-sync server 10.

[0028] Due to the multicast nature of the hot-sync request, the PDA 12 may receive replies from more than one hot-sync server 10. The PDA 12 must choose one hot-sync server 10 through which it will establish the hot-sync channel to the desired host system 14. The PDA 12 may employ one of many different algorithms, such as first reply received, to determine which server will be used to establish the wireless hot-sync channel.

[0029] The PDA 12 then sends a service accepted (SVC ACPTD) message to the hot-sync server 10, indicating that the PDA 12 accepts the offer of service. Upon receiving the SVC ACPTD message, the hot-sync server 10 sends a connection opened (CONN OPEND) message to the host system 14 to open the channel 28 (FIG. 1) that will be used for data transfer between the host system 14 and the PDA 12 during the hot-sync operation. After the channel 28 is opened, the hot-sync server 10 sends a service enabled (SVC ENBLD) message to the PDA 12. This message prompts the PDA 12 to commence the actual transfer of hot-sync data over the hot-sync channel 28.

[0030] During the Use Channel phase, the hot-sync server 10 relays transfer packet (XFER PKT) messages between the PDA 12 and the host system 14. Any errors that occur during the transfer of packets are handled within the communication protocol established between the PDA 12 and the host system 14. If the transfer terminates normally, the host system 14 sends a transfer complete (XFER COMPL) message, to which the hot-sync server 10 responds by sending a service disabled (SVC DISBLD) message to the PDA 12. This marks the completion of the hot-sync operation. The transfer may also complete abnormally, for example due to a failure of the transfer protocol. If such a failure is detected by the hot-sync server 10, it sends a SVC DISBLD message to the PDA 12 informing the PDA 12 that the operation has terminated.

[0031] It should be noted that the mechanism described herein for opening, maintaining, and closing the wireless communication channel is independent from the data transfer protocol that is used by the PDA 12 and the host system 14 to transfer data. In particular, it is assumed that the transfer protocol has its own error detection and handling features, and that each device has a suitable interface to the operating system and/or user. Thus in the above case in which the PDA 12 receives a SVC DISBLD message for an error case, it is assumed that higher-level software detects the premature closing of the channel, and takes appropriate action. While it may be possible in alternative embodiments to incorporate additional error detection and handling features in the channel-establishing mechanism, the disclosed technique offers the benefits of a very simple interface to higher-level software.

[0032] FIG. 4 shows the operation of the PDA hot-sync state machine 30. The PDA hot-sync state machine 30 remains in an IDLE state 110 until a user requests a wireless hot-sync operation. The request may be indicated, for example, using a function key 18 (FIG. 1), or using an icon or menu item on the touch screen 20 (FIG. 1). In response, the PDA 12 transmits a multi-cast SYNC REQ message for receipt by one or more hot-sync servers 10 as described above. Several counters, referred to as a find_service_retry counter, an enable_service_retry counter and a transfer_retry counter (see FIG. 2), are reset. A timer referred to as the find_service timer is enabled, and the PDA hot-sync state machine 30 transitions to a FIND SERVER state 120.

[0033] In the FIND SERVER state 120, the PDA 12 waits for a SVC OFFRD message from a hot-sync server 10 over the wireless link 22. If a SVC OFFRD message is not received before the expiration of the find_service timer, then the value of the find_service_retry counter is compared with a predetermined value referred to as the max_service_retries value. If the value of the find_service_retry counter is less than the max_service_retries value, the PDA 12 increments the find_service_retry counter, transmits another SYNC REQ message, resets the find_service_timer, and remains in the FIND SERVER state 120 to again await the return of a SVC OFFRD message. If, however, the value of the find_service_retry counter is equal to the max_service_retries value, indicating that the attempts to find a hot-sync server 10 have failed, the PDA hot-sync state machine 30 transitions back to the IDLE state 110.

[0034] If the PDA hot-sync state machine 30 receives a SVC OFFRD message when in the FIND SERVER state 120, it cancels the find_service timer, transmits a SVC ACPTD message over the wireless link 22 to the hot-sync server 10 that sent the SVC OFFRD message, sets an enable_service timer, and transitions to an OBTAIN SERVICE state 130. The value of the find_service_retry counter is maintained. As described below, the FIND SERVER state 120 may be entered again at a later point in the process. Maintaining the value of the find_service_retry counter ensures that an infinite loop will not result from such re-entry.

[0035] In the OBTAIN SERVICE state 130, the PDA hot-sync state machine 30 waits to receive a SVC ENBLD message. If the enable_service timer expires before a SVC ENBLD message is received, then the value of a counter referred to as an enable_service_retry counter is compared with a predetermined value referred to as a max_enable_service_retries value. If the value of the enable_service_retry counter is less than the value of max_enable_service_retries, the PDA hot-sync state machine 30 increments the enable_service_retry counter, transmits another SVC ACPTD message to the same hot-sync server 10, and re-starts the enable_service timer. On the other hand, if the value of the enable_service_retry counter is equal to the max_enable_service_retries value when the enable_service timer expires, indicating that the hot-sync server 10 has become unavailable, the PDA hot-sync state machine 30 transitions back to the FIND SERVER state 120 to attempt to find another hot-sync server 10. As mentioned above, the value of the find_service_retry counter has been maintained, so that this re-entry does not result in an infinite loop through the FIND SERVER and OBTAIN SERVICE states 120 and 130.

[0036] When the PDA hot-sync state machine 30 is in the OBTAIN SERVICE state 130 and receives a SVC ENBLD message from the hot-sync server 10, it cancels the enable_service timer and transitions to a TRANSFER state 140. At this point, the hot-sync communications channel 28 has been established, and either the PDA 12 or the host system 14 can initiate the transfer of data, which may be carried out in the same manner as in the above-described configuration in which a conventional PDA is placed in a hot-sync cradle. When in the TRANSFER state 140, the PDA hot-sync state machine 30 transmits XFER PKT messages to the hot-sync server 10 and receives XFER PKT messages from the hot-sync server 10 using an appropriate communication protocol. A known protocol such as File Transfer Protocol (FTP) or Trivial File Transfer Protocol (TFTP) may be employed. The protocol to be used may be specified as a PDA configuration parameter, or it may be specified using a discovery mechanism over the communication channel 28 once established.

[0037] If the hot-sync transfer completes successfully, the PDA hot-sync state machine 30 receives a SVC DISBLD message from the hot-sync server 10, cancels all timers, and transitions back to the IDLE state 110.

[0038] When the PDA hot-sync state machine 30 is in the TRANSFER state 140, the PDA 12 may detect a non-recoverable transfer protocol failure, such as by timeout or an explicit notification. The hot-sync server 10 may also detect a failure of the hot-sync channel 28, in which case it will send a SVC DISBLD message to the PDA 12. In either case, if the value of the transfer_retry counter is less than a value referred to as the max_transfer_retries value, the PDA 12 increments the transfer_retry counter, transmits a new SYNC REQ message addressed to any nearby hot-sync server 10 over a corresponding wireless link 22, re-enables the find_service timer, and transitions back to the FIND SERVER state 120 in an attempt to re-establish a channel 28. Again, the saving of the find_service_retry counter prevents the occurrence of infinite loops through the FIND SERVER, OBTAIN SERVICE and TRANSFER states. On the other hand, if the content of the transfer_retry counter is equal to the max_transfer_retries value, indicating that attempts to complete the transfer have failed, the PDA hot-sync state machine 30 transitions back to the IDLE state 110.

[0039] FIG. 5 shows the operation of the server hot-sync state machine 40. The server hot-sync state machine 40 remains in an IDLE state 210 until it receives a SYNC REQ message from a PDA 10 over a corresponding wireless link 22. The hot sync server 10 may have a plurality of hot-sync state machines 40 operating concurrently to service requests from a number of different PDAs 12 in its local area. If the hot-sync server 10 is available to service the hot-sync request, it sends a CONN REQ message to the host system 14 designated in the SYNC REQ message, enables a timer referred to as a find_host timer, and transitions 201 to a FIND HOST state 220. If the hot-sync server 10 is not available to service the hot-sync request, the server hot-sync state machine 40 takes no action and remains in the IDLE state 210.

[0040] When in the FIND HOST state 220, the server hot-sync state machine 40 awaits the receipt of a CONN ACPTD message from the designated host system 14. If the find_host timer expires before a CONN ACPTD message is received, the server hot-sync state machine 40 immediately transitions back to the IDLE state 210. If a CONN ACPTD message is received before the expiration of the find_host timer, the server hot-sync state machine 40 cancels the find_host timer, transmits a SCV OFFRD message to the PDA 12, enables a timer referred to as a service_accepted timer, and transitions to a HOST FOUND state 230.

[0041] When the server hot-sync state machine 40 is in the HOST FOUND state 230, it awaits the receipt of a SVC ACPTD message from the PDA 12. If the service_accepted timer expires before a SVC ACPTD message is received, the server hot-sync state machine 40 transitions back to the IDLE state 210. If a SVC ACPTD message is received before expiration of the service_accepted timer, the server hot-sync state machine 40 cancels the service_accepted timer, transmits a CONN OPEND message to the host system 14, and transmits a SVC ENBLD message to the PDA 12. The server hot-sync state machine 40 then transitions to the TRANSFER state 240.

[0042] When the server hot-sync state machine 40 is in the TRANSFER state 240, the hot-sync server 10 receives XFER PKT messages from the host system 14 and forwards these messages as XFER PKT messages to the PDA 12, and also receives XFER PKT messages from the PDA 12 and forwards these messages as XFER PKT messages to the host system 14. The hot-sync server 10 preferably implements an activity timer (not shown) to determine whether a disconnect occurs on either side (wireless or network) of the hot-sync channel 28. The activity timer may be watching for any channel traffic or for required two-way traffic. If failure of the hot-sync channel 28 is detected when the server hot-sync state machine 40 is in the TRANSFER state 240, the hot-sync server 10 transmits a SVC DISBLD message to the PDA 12 and closes the hot-sync channel 28, and the server hot-sync state machine 40 transitions to the IDLE state 210. If the transfer protocol completes successfully, as indicated by the receipt of a XFER COMPL message from the host system 14, the hot-sync server 10 transmits a SVC DISBLD message to the PDA 12, and the server hot-sync state machine 40 transitions to the IDLE state 210.

[0043] FIG. 6 shows the operation of the host system hot-sync state machine 50. The host system hot-sync state machine 50 remains in an IDLE state 310 until the host system 14 receives a CONN REQ message from a hot-sync server 10. The host system 14 may have a plurality of hot-sync state machines 50, one per PDA 12, operating concurrently. If the host system 14 is available to service the hot-sync request, the host system 14 sends a CONN ACPTD message to the hot-sync server 10, enables a connection_open timer, and transitions to a CONNECTING state 320. If the host system 14 is not available to service the hot-sync request, the host system hot-sync state machine 50 takes no action and remains in the IDLE state 310.

[0044] When in the CONNECTING state 320, the host system hot-sync state machine 50 waits for a CONN OPEND message indicating that the connection to the requesting PDA 12 should be opened. If the connection_open timer expires before a CONN OPEND message is received from the hot-sync server 10, the host system hot-sync state machine 50 immediately transitions back to the IDLE state 310. If a CONN OPEND message is received before expiration of the connection_open timer, the host system 14 cancels the connection_open timer and transitions to a TRANSFER state 330.

[0045] When in the TRANSFER state 330, the host system 14 transmits XFER PKT messages to the hot-sync server 10 and receives XFER PKT messages from the hot-sync server 10. During this period, if the host system 14 detects a non-recoverable transfer protocol failure or receives a SVC DISBLD message (not shown in FIG. 3) from the hot-sync server 10, the host system hot-sync state machine 50 transitions to the IDLE state 310. If the transfer protocol completes successfully, the host system 14 transmits a XFER COMPL message to the hot-sync server 10, and the host system hot-sync state machine 50 transitions to the IDLE state 310.

[0046] Techniques for the wireless hot-synchronization of a PDA have been shown. Those skilled in the art will recognize that variations and modifications of the disclosed techniques are possible. For example, a hot-sync server may establish different hot-sync channels with host systems that are on different networks. Other variations are also possible. Accordingly, it is submitted that the invention should not be limited to the described embodiment but rather should be limited only by the scope and spirit of the appended claims.