Communication system and method with mobile devices

[0001] One of the most important milestones in the wireless communications is the arrival of third generation or 3G technology and devices that are capable of transferring voice and data at much higher speed. One new development in mobile device technology is the use of Internet Protocol (IP) addresses to identify and communicate with mobile devices. However, using IP addresses to identify and communicate with a mobile device brings some unresolved issues. For example, carriers responsible for the communication to and from the mobile devices may change the IP address assignment frequently and arbitrarily. Different carriers may also have different policies regarding the frequency and manner of assigning the IP addresses. Therefore, it is unknown, at any moment, what is the current IP address of the mobile devices.

[0008] The problem of not knowing what the current IP address for the IP-based mobile devices is addressed herein. Because these mobile devices are required to synchronize their data with enterprise data, such as electronic mail, calendar, tasks list, address book, notes, etc., the enterprise system needs to know the current IP addresses of the mobile devices in order to continuously synchronize the data. Described herein is a system and method that enables mobile devices to periodically update the enterprise system of its current IP address and other information, so that continuous data synchronization may be performed.

[0009] FIG. 1 is a simplified block diagram of an embodiment of a system 10 for communicating with mobile devices. A synchronizing server 12 is in communication with an enterprise data database 14. Database 14 may store enterprise or backend data associated with a business entity, an organization, an business activity, etc. The description herein will specifically refer to communications using UDP (User Datagram Protocol) and/or TCP/IP (Transmission Control Protocol/Internet Protocol), but system 10 may be adapted to use other suitable protocols now known or later developed. Both synchronizing server 12 enterprise data database 14 are in communication with the Internet or another computer network 16. Via the Internet 16, synchronizing server 12 may communicate with an IP gateway 18 and an IP data database 20 associated therewith. Database 20 may store data associated with a plurality of devices 22-24, which may be mobile devices. More specifically, database 20 is used to store data associated with communicating with devices 22-24 such as device identifiers (device IDs), IP addresses, IP port number, and the messages communicated or to be communicated therebetween. Synchronization server 12 is operable to maintain the user and device states and to perform data synchronization between devices 22-24 and enterprise data database 14. IP gateway 18 and devices 22-24 that have been registered remain in contact so that data synchronization can be performed. A client software code 26 executes on each of the devices 22-24 and is operable to contact IP gateway 18 periodically to inform it of its current IP address and other related data.

[0010] Referring also to FIG. 2 for a simplified flowchart of an embodiment of a process for setting up a system for communicating with IP-based devices. Synchronization server 12 and enterprise data database 14 are set up to be able to communicate with one another and with IP gateway 18 in block 30. Synchronization server 12, database 14 and IP gateway are provided with one another's IP address, for example. Further, IP gateway 18 and IP data database 20 are set up to communicate with one another in block 32. In block 34, devices 22-24 are also provisioned with the client software code and the IP address of IP gateway 18 so that it is able to contact and communicate with the IP gateway. Client software code 26 is operable to send a heartbeat to IP gateway 18 that contains its current IP address and other information.

[0011] FIG. 3 is a simplified flowchart of an embodiment of a process for communicating with IP-devices. As new devices are deployed in system 10, each device first registers with system 10, for example, such as registering with synchronization server 12 in block 40. The new device may provide synchronization server 12 its device ID, IP address, and port number, for example. Synchronization server 12 then informs IP gateway 18 that a new device has been added to the system in block 42. IP gateway 18 then adds the new device and its associated data to IP data database 20 in block 44. After device registration, the client software on the new device begins to send heartbeat messages to IP gateway 18 in block 46. The heartbeat messages include embedded device ID, current IP address, and port number to which the device listens. The device ID may be used as the index to look for the current IP address and port number in the IP data database. The IP gateway stores the received IP data in the heartbeat messages in the IP data database in block 48. Alternatively, the IP gateway may update the IP data database only if the IP information for the device has changed. In block 50, IP gateway 18 sends an acknowledgement message to the device. The IP gateway also may determine whether there are any pending messages or other data for the device in block 52 and transmits the message or data to the device in block 54. Each device in system 10 thus communicates with the IP gateway periodically by sending a heartbeat message with embedded communication data. Because the IP address and the port number are embedded in the messages, they are not altered by any network translation done by the carrier transmitting the messages. Depending on the properties of the carrier, network traffic conditions, and other parameters, the devices may send a heartbeat message at a suitable interval such as every few seconds or every few minutes. The IP gateway and the devices may communicate using UDP or TCP/IP protocols, or any other suitable protocol.

[0012] FIG. 4 is a message flow diagram of an embodiment of a process for communicating with IP-based devices. The user first registers the mobile device with the synchronization server, as indicated by arrow 60. The synchronization server notifies the IP gateway, as indicated by arrow 62. Thereafter, the device sends periodic heartbeat messages to the IP gateway, and the IP gateway stores the IP data embedded therein, as indicated by arrows 64 and 66. The IP gateway then sends an acknowledgement (ACK) back to the device, as indicated in arrow 68. If the mobile device does not receive an acknowledgement to its heartbeat message, then it is either out of range or, more unlikely, the IP gateway is not operational. The mobile device will continue to send the heartbeat message, either at the normal interval or at adjusted intervals, to reach the IP gateway. For example, the mobile device may send the heartbeat message at shorter intervals until it receives an acknowledgement from the IP gateway.

[0013] If a mobile device is turned off, when it is turned back on, it immediately resumes sending the heartbeat messages to the IP gateway, as indicated by arrow 70. The IP gateway stores the communication data such as IP address and port number embedded in the IP data database and sends an acknowledgement message back to the device, as indicated by arrows 72 and 74. If there are pending messages for the device that were undeliverable while the device was off, out of range or otherwise unresponsive, the IP gateway transmits the pending messages to the device, as indicated by arrow 76. The synchronization server may also notify the IP gateway if there is new data or if data has changed in the enterprise data database, as indicated by arrow 78. The IP gateway then looks up the device's IP address and notifies the device, as indicated by arrow 80. In response to receiving the notification, the mobile device sends a synchronization request to the synchronization server, as indicated by arrow 82. The synchronization server retrieves the requested data from the enterprise database and sends the new or changed data to the mobile device, as indicated by arrow 84. The mobile device, upon successfully receiving and processing the transmitted data, sends an acknowledgement back to the IP gateway, as indicated by arrow 86.

[0014] FIG. 5 is another message flow diagram of an embodiment of a process for communicating with IP-based devices. The synchronization server may send the new or the change data directly to the IP gateway, as indicated by arrow 90. The IP gateway may store this data in the IP data database and then transmits the new and change data to the mobile device, as indicated by arrows 92 and 94. If the device goes out of range or is turned off while this data transmission is taking place, then IP gateway does not receive an acknowledgement message from the mobile device indicating successful transmission. Therefore, the IP gateway may note that the stored data has not been successfully transmitted to the mobile device. When the device is turned back on, it immediately sends a heartbeat message to the IP gateway, as indicated by arrow 96. Similarly, if the mobile device is out of range, the IP gateway is not able to receive the heartbeat messages even though the mobile device continues to send them. Once the mobile device comes back into range, the IP gateway is able to receive the heartbeat messages and send back acknowledgements. The IP gateway stores the current IP data in the IP data database, as indicated by arrow 98. The IP gateway then sends an acknowledgement back to the mobile device, as indicated by arrow 100. Using the most current IP address, the IP gateway also sends the new and/or changed data that were not successfully delivered as well as any other pending messages stored in the IP data database to the mobile device, as indicated by arrow 102. The mobile device responds by sending an acknowledgement message to the IP gateway if the data is successfully received and processed.

[0015] The mobile devices and the IP gateway may share a secure identifier, which may be combined with an hash code using an encrypting algorithm. For example, an auto-increment index one-way hash and MD5 encryption may be used. Every message sent to the mobile device by the IP gateway includes the secure ID, the un-encrypted index, and a unique token generated using the secure ID and the index. Upon receiving the index, the client code in the mobile device compares it with its own index and ignores any message with an index that is less than or equal to its own index. If it finds an index that is greater than its own index, then it generates a MD5 hash of the index and the secure key and compares it with the token sent by the IP gateway. The client acts upon a message only if the two tokens match. Other suitable hash algorithms and encryption methods may be used.

[0016] Although embodiments of the present disclosure have been described in detail, those skilled in the art should understand that they may make various changes, substitutions and alterations herein without departing from the spirit and scope of the present disclosure. Accordingly, all such changes, substitutions and alterations are intended to be included within the scope of the present disclosure as defined in the following claims. In the claims, means-plus-function clauses are intended to cover the structures described herein as performing the recited function and not only structural equivalents, but also equivalent structures.