System and method for pushing information from a host system to a mobile data communication device in a wireless data network

CROSS-REFERENCE TO RELATED APPLICATIONS

0001This application claims priority from U.S. Provisional Application Ser. Nos. 60/268,824, filed on Feb. 14, 2001, Ser. No. 60/237,616, filed on Oct. 3, 2000, and Ser. No. 60/233,501, filed on Sep. 19, 2000. This application also claims priority from, and is a continuation-in-part of, U.S. patent application Ser. No. 09/528,495, filed on Mar. 17, 2000 which is a continuation of Ser. No. 09/087,623, filed on May 29, 1998, now U.S. Pat. No. 6,219,694. The complete disclosure of each of these provisional and utility applications, and the issued patent, including drawings and claims, is hereby incorporated into this application by reference.

BACKGROUND

00021. Field of the Invention

0003The present invention is directed to the field of data communications in a wireless network. More specifically, the invention relates to a system and method for communicating information to a mobile communication device (“mobile device”) within a wireless data network (such as an IP based wireless data network) and also for replicating information between a host system (or a host system with an associated messaging server) and the mobile device via the wireless data network.

00042. Description of the Related Art

0005Wireless data networks are known in this field. Early wireless data networks include the Mobitex network and the Datatac network. These early networks provided limited data capacity and also required to have fixed addresses for each mobile device. Such a fixed address is also known as a “static” network address. Recently, however, new types of wireless data networks have emerged having much greater data bandwidth. These new data networks, such as the GPRS network, may utilize the Internet Protocol (IP) for routing data to a mobile device. The inherent addressing limitations of the IP protocol (and other similar packet protocols) typically limit the use of have static addressing in these types of data networks, thus leading to a dynamic addressing scheme. In this type of addressing scheme, a pool of available network addresses is dynamically assigned to a much greater pool of user devices depending on which devices are accessing the network at a given instant.

0006As described in more detail in the co-pending, and co-owned application S/N, a wireless data network can be coupled to one or more redirector applications for enabling real-time mirroring (or redirection) of user data items from a user's office computer (or corporate server) to the user's mobile device. In such a redirector application, user data items, such as e-mail messages, calendar events, etc., are received at the user's office computer, which then redirects (or mirrors) the data items to the user's mobile device via the wireless data network. It would be advantageous to extend this redirection system to operate with newer wireless data networks such as the General Packet Radio Service (“GPRS”) network, or other networks that may utilize a packet protocol, such as IP, in which the wireless data network dynamically assigns network addresses on an as-needed basis.

SUMMARY

0007A system and method for redirecting data to one or more mobile data communication devices via a wireless packet data network is provided in which the network dynamically assigns network addresses to the mobile data communication devices on an as-needed basis. A redirector program preferably operating at a host system continuously redirects data to the wireless packet data network, as the data is received (or altered) at the host system. Two methods are provided for communicating the redirected data from the wireless network to the mobile device. In a first method, the mobile device is configured to periodically contact a store-and-forward server (or gateway) operating in conjunction with the wireless network, which, when contacted, transmits the data to the mobile device. In a second method, the wireless network transmits a connection request command to the mobile device via a parallel voice network, or via a control channel on the data network, or via some other type of low-bandwidth data channel. The mobile device then contacts the wireless data network and requests a network address so that the store-and-forward server can send the data to the mobile device. In this second embodiment the presence of a ‘push bearer’ channel is preferred. A push bearer network is defined as a network that can provide an address for the wireless device that is statically defined and always reachable. The push bearer network can have low capacity and very limited bandwidth, as is the case with the Short Message Service (SMS) messaging, used on many wireless networks.

0008The redirector program enables a user to redirect (or mirror) certain user-selected data items (or parts of data items) from the host system to the user's mobile data communication device upon detecting that one or more user-defined triggering events has occurred. Also operating at the host system are various sub-systems that can be configured to create triggering events, such as a screen saver sub-system or a keyboard sub-system, as well as sub-systems for repackaging the user's data items for transparent delivery to the mobile device, such as a TCP/IP sub-system or one or more E-Mail sub-systems. Other sub-systems for creating triggering events and repackaging the user's data items could also be present at the host system.

0009Using the redirector program, the user can select certain data items for redirection, such as E-mail messages, calendar events, meeting notifications, address entries, journal entries, personal reminders, etc. Having selected the data items for redirection, the user can then configure one or more event triggers, which are sensed by the redirector program to initiate redirection of the user's data items. These user-defined triggers (or event triggers) may include external events, internal events and networked events. Examples of external events include: receiving a message from the user's mobile data communication device to begin redirection; receiving a similar message from some external computer; sensing that the user is no longer in the vicinity of the host system; or any other event that is external to the host system. Internal events could be a calendar alarm, screen saver activation, keyboard timeout, programmable timer, or any other user-defined event that is internal to the host system. Networked events are user-defined messages that are transmitted to the host system from another computer coupled to the host system via a network to initiate redirection.

0010In addition to the functionality noted above, the redirector program provides a set of software-implemented control functions for determining the type of mobile data communication device and its address (if a static address is used), for programming a preferred list of message types that are to be redirected, and for determining whether the mobile device can receive and process certain types of message attachments, such as word processor or voice attachments.

0011The determination of whether a particular mobile device can receive and process attachments is initially configured by the user of that mobile device at the host system. This configuration can be altered on a global or per message basis by transmitting a command message from the mobile device to the host system. If the redirector is configured so that the mobile device cannot receive and process word processor or voice attachments, then the redirector program routes these attachments to an external machine that is compatible with the particular attachment, such as an attached printer or networked fax machine or telephone. Other types of attachments could be redirected to other types of external machines in a similar fashion, depending upon the capabilities of the mobile device. For example, if a user is traveling and receives a message with an attachment that the user's mobile device can process or display, the user may, from a mobile communications device, send a command message to the host system indicating that that attachment should be sent to a fax machine at a hotel where the user will be spending the evening. This enables the user to receive important E-mail attachments as long as the host system is provided with sufficient information about the destination where the attachment is to be forwarded.

0012Once an event has triggered redirection of the user data items, the host system repackages these items in a manner that is transparent to the mobile data communication device, so that the data at the mobile device appears similar to the same data at the user's host system. The preferred repackaging method includes wrapping the user data items in an E-mail envelope that corresponds to the address of the mobile data communication device, although, alternatively, other repackaging methods could be used with the present invention, such as special-purpose TCP/IP wrapping techniques, or other methods of wrapping the user selected data items. The repackaging method preferably results in a shared E-mail address for the user's host system and the user's mobile device. To a recipient of an E-mail generated at either the host or the mobile device, it appears as though the E-mail was generated at the host system. The repackaging method also provides encryption/decryption and compression/decompression.

0013In an alternative system and method, the redirector program executes at a network server, and the server is programmed to detect numerous redirection event triggers over a local area network (“LAN”) from multiple user desktop systems coupled to the server via the LAN. The server can receive internal event triggers from each of the user desktops via the LAN, and can also receive external event triggers, such as messages from the users' mobile data communication devices. In response to receiving one of these triggers, the server redirects the user's data items to the proper mobile data communication device. The user data items and addressing information for a particular mobile device can be stored at the server or at the user's desktop system. Using this alternative configuration, one redirector program can serve a plurality of users. This alternative configuration could also include an Internet or Intranet-based redirector program that could be accessible through a secure webpage or other user interface.

0014In another alternative configuration of the present invention, a redirector program operates at both the host system and at the user's mobile data communication device. In this configuration, the user's mobile device operates similarly to the host system, described below, and is configured in a similar fashion to redirect certain user-selected data items from the mobile device to the user's host system (or some other computer) upon detecting an event trigger at the mobile device. This configuration provides two-way redirection of information from the host to the mobile device and from the mobile device to the host.

0015The present invention can be used with many types of mobile data communication devices, including two-way pagers, cellular telephones having data messaging capabilities, PDAs, laptops, palmtops, or any other type of wireless communicator. These wireless communicators may be dual-mode devices that operate on both voice and data networks, such as a communicator capable of sending and receiving voice signals over a voice network like GSM, and also capable of sending and receiving data signals over a data network like GPRS. Or, the wireless communicator may be a single-mode device that operates on just a data network (like GPRS), or it may be a multimode device capable of operating on some other combination of voice and data networks.

BRIEF DESCRIPTION OF THE DRAWINGS

0016<figref idref="DRAWINGS">FIG. 1</figref> is a system diagram showing the redirection of user data items from a user's desktop PC (host system) to the user's mobile data communication device, where the redirector software is operating at the user's desktop PC.

0017<figref idref="DRAWINGS">FIG. 2</figref> is a system diagram showing the redirection of user data items from a network server (host system) to the user's mobile data communication device, where the redirector software is operating at the server.

0018<figref idref="DRAWINGS">FIG. 3</figref> is a block diagram showing the interaction of the redirector software with other components of the host system in <figref idref="DRAWINGS">FIG. 1</figref> (the user's desktop PC) to enable the pushing of information from the host system to the user's mobile data communication device.

0019<figref idref="DRAWINGS">FIG. 4</figref> is a flow chart showing the steps carried out by the redirector software operating at the host system.

0020<figref idref="DRAWINGS">FIG. 5</figref> is a flow chart showing the steps carried out by the mobile data communication device to interface with the redirector software operating at the host system.

0021<figref idref="DRAWINGS">FIG. 6</figref> is a system diagram showing the basic components of an IP based wireless data network, such as the GPRS network, for use with the present invention.

0022<figref idref="DRAWINGS">FIG. 7</figref> is a detailed illustration of how addresses are dynamically assigned and how data tunnels are created and used within an IP based wireless network.

0023<figref idref="DRAWINGS">FIG. 8</figref> sets forth the steps to redirect data items over the IP based wireless network to a mobile device.

0024<figref idref="DRAWINGS">FIG. 9</figref> is a data flow diagram that depicts how a store-and-forward gateway handles incoming data from redirector programs going to mobile devices.

0025<figref idref="DRAWINGS">FIG. 10</figref> is a continuation of <figref idref="DRAWINGS">FIG. 9</figref>, and is a data flow diagram of how a mobile address to IP address mapping database is updated with external and internal events.

0026<figref idref="DRAWINGS">FIG. 11</figref> is a data flow diagram of the mobile device's logic for communicating with the store-and-forward gateway.

0027<figref idref="DRAWINGS">FIG. 12</figref> is an illustrative system diagram of a proposed dual mode device that could be used with the invention.

0028<figref idref="DRAWINGS">FIGS. 13</figref><i>a </i>and <b>13</b><i>b </i>are sequence diagrams illustrating actions taken at the mobile, DHCP and store and forward gateway after a connection request command is made to the mobile.

DETAILED DESCRIPTION OF THE DRAWINGS

0029Referring now to the drawings, <figref idref="DRAWINGS">FIG. 1</figref> is an example system diagram showing the redirection of user data items (such as message A or C) from a user's office PC (host system) <b>10</b> to the user's mobile data communication device <b>24</b>, where the redirector software <b>12</b> is operating at the user's PC. Message A in <figref idref="DRAWINGS">FIG. 1</figref> represents an internal message sent from desktop <b>26</b> to the user's host system <b>10</b> via LAN <b>14</b>. Message C in <figref idref="DRAWINGS">FIG. 1</figref> represents an external message from a sender that is not directly connected to LAN <b>14</b>, such as the user's mobile data communication device <b>24</b>, some other user's mobile device (not shown), or any user connected to the Internet <b>18</b>. Message C also represents a command message from the user's mobile data communication device <b>24</b> to the host system <b>10</b>. As described in more detail in <figref idref="DRAWINGS">FIG. 3</figref>, the term “host system” <b>10</b> preferably includes, along with the typical hardware and software associated with a workstation or desktop computer, the redirector program <b>12</b>, a TCP/IP subsystem <b>42</b>, a primary message store <b>40</b>, an E-mail subsystem <b>44</b>, a screen saver subsystem <b>48</b>, and a keyboard subsystem <b>46</b>. The E-mail subsystem may be composed of one or more message servers (not necessarily the same type of message server) linked via communication means for the purposes of sending and receiving E-mail between workstations in the LAN, the Internet, and one or more Intranets or other proprietary private networks.

0030In <figref idref="DRAWINGS">FIG. 1</figref>, the host system <b>10</b> is the user's desktop system, typically located in the user's office. The host system <b>10</b> is connected to a LAN <b>14</b>, which also connects to other computers <b>26</b>, <b>28</b> that may be in the user's office or elsewhere. The LAN <b>14</b>, in turn, is connected to a wide area network (“WAN”) <b>18</b>, such as the Internet, which is defined by the use of the Transmission Control Protocol/Internet Protocol (“TCP/IP”) to exchange information, but which, alternatively, could be any other type of WAN. The connection of the LAN <b>14</b> to the WAN <b>18</b> is via high bandwidth link <b>16</b>, typically a T1 or T3 connection. The WAN <b>18</b>, in turn, is connected to a variety of gateways <b>20</b> via connections <b>32</b>. A gateway forms a connection or bridge between the WAN <b>18</b> and some other type of network, such as an RF wireless network, cellular network, satellite network, or other synchronous or asynchronous land-line connection.

0031In the example of <figref idref="DRAWINGS">FIG. 1</figref>, a wireless gateway <b>20</b> is connected to the Internet for communicating via wireless link <b>22</b> to a plurality of wireless mobile data communication devices <b>24</b>. For the purposes of this application description the term store-and-forward gateway <b>140</b> will also be used in place of the term wireless gateway <b>20</b>. In an embodiment, the store and forward gateway may be referenced as a Access Point Name (APN) as defined on a network like GPRS. Also shown in <figref idref="DRAWINGS">FIG. 1</figref> is external machine <b>30</b>, which could be a FAX machine, a printer, a system for displaying images (such as video) or a machine capable of processing and playing audio files, such as a voice mail system. The present invention includes the ability to redirect certain message attachments to such an external machine <b>30</b> if the redirector-program configuration data reflects that the mobile device <b>24</b> cannot receive and process the attachments, or if the user has specified that certain attachments are not to be forwarded to mobile device <b>24</b>, even if such device can process those attachments. By way of example, consider an E-mail sent to a user that includes three attachments—a word processing document, a video clip and an audio clip. The redirection program could be configured to send the text of the E-mail to the mobile device, to send the word processing document to a networked printer located near the user, to send the video clip to a store accessible through a secure connection through the Internet, and to send the audio clip to the user's voice mail system.

0032The preferred mobile data communication device <b>24</b> is a hand-held two-way wireless paging computer, a wirelessly enabled palm-top computer, a mobile telephone with data messaging capabilities, or a wirelessly enabled laptop computer, but could, alternatively be other types of mobile data communication devices capable of sending and receiving messages via a network connection <b>22</b>. Although it is preferable for the system to operate in a two-way communications mode, certain aspects of the invention could be beneficially used in a “one and one-half” or acknowledgment paging environment, or even with a one-way paging system. The mobile data communication device <b>24</b> includes software program instructions that work in conjunction with the redirector program <b>12</b> to enable the seamless, transparent redirection of user-selected data items. <figref idref="DRAWINGS">FIG. 4</figref> describes the basic method steps of the redirector program <b>12</b>, and <figref idref="DRAWINGS">FIG. 5</figref> describes the steps of the corresponding program operating at the mobile device <b>24</b>.

0033One example of a dual-mode device is shown in <figref idref="DRAWINGS">FIG. 12</figref>. The mobile communication device <b>24</b> shown in <figref idref="DRAWINGS">FIG. 12</figref> is preferably a two-way communication device having at least voice and data communication capabilities. The device preferably has the ability to communicate with other computer systems on the Internet. Depending on the functionality provided by the device, the device may be referred to as a data messaging device, a two-way pager, a cellular telephone with data messaging capabilities, a wireless Internet appliance or a data communication device (with or without telephony capabilities).

0034Where the device <b>24</b> is enabled for two-way communications, the device will incorporate a communication subsystem <b>1911</b>, including a receiver <b>1912</b>, a transmitter <b>1914</b>, and associated components such as one or more, preferably embedded or internal, antenna elements <b>1916</b> and <b>1918</b>, local oscillators (LOs) <b>1913</b>, and a processing module such as a digital signal processor (DSP) <b>1920</b>. As will be apparent to those skilled in the field of communications, the particular design of the communication subsystem <b>1911</b> will be dependent upon the communication network in which the device is intended to operate. For example, a device <b>24</b> destined for a North American market may include a communication subsystem <b>1911</b> designed to operate within the Mobitex™ mobile communication system or the DataTAC™ mobile communication system, whereas a device <b>24</b> intended for use in Europe may incorporate a General Packet Radio Service (GPRS) communication subsystem <b>1911</b>.

0035Network access requirements will also vary depending upon the type of network <b>1919</b>. For example, in the Mobitex and DataTAC networks, mobile devices <b>24</b> are registered on the network using a unique personal identification number or PIN associated with each device. In GPRS networks, however, network access is associated with a subscriber or user of a device <b>24</b>. A GPRS device therefore requires a subscriber identity module (not shown), commonly referred to as a SIM card, in order to operate on a GPRS network. Without a SIM card, a GPRS device will not be fully functional. Local or non-network communication functions (if any) may be operable, but the device <b>24</b> will be unable to carry out any functions involving communications over the network <b>1919</b>. When required network registration or activation procedures have been completed, a device <b>24</b> may send and receive communication signals over the network <b>1919</b>. Signals received by the antenna <b>1916</b> through a communication network <b>1919</b> are input to the receiver <b>1912</b>, which may perform such common receiver functions as signal amplification, frequency down conversion, filtering, channel selection and the like, and in the example system shown in <figref idref="DRAWINGS">FIG. 19</figref>, analog to digital conversion. Analog to digital conversion of a received signal allows more complex communication functions, such as demodulation and decoding to be performed in the DSP <b>1920</b>. In a similar manner, signals to be transmitted are processed, including modulation and encoding, for example, by the DSP <b>1920</b> and input to the transmitter <b>1914</b> for digital to analog conversion, frequency up conversion, filtering, amplification and transmission over the communication network <b>1919</b> via the antenna <b>1918</b>.

0036The DSP <b>1920</b> not only processes communication signals, but also provides for receiver and transmitter control. For example, the gains applied to communication signals in the receiver <b>1912</b> and transmitter <b>1914</b> may be adaptively controlled through automatic gain control algorithms implemented in the DSP <b>1920</b>.

0037The device <b>24</b> preferably includes a microprocessor <b>1938</b>, which controls the overall operation of the device. Communication functions, including at least data and voice communications, are performed through the communication subsystem <b>1911</b>. The microprocessor <b>1938</b> also interacts with other device subsystems, such as the display <b>1922</b>, flash memory <b>1924</b>, random access memory (RAM) <b>1926</b>, auxiliary input/output (I/O) subsystems <b>1928</b>, serial port <b>1930</b>, keyboard <b>1932</b>, speaker <b>1934</b>, microphone <b>1936</b>, a short-range communications subsystem <b>1940</b> and any other device subsystems generally designated as <b>1942</b>.

0038Some of the subsystems shown in <figref idref="DRAWINGS">FIG. 12</figref> perform communication-related functions, whereas other subsystems may provide “resident” or on-device functions. Notably, some subsystems, such as keyboard <b>1932</b> and display <b>1922</b>, for example, may be used for both communication-related functions, such as entering a text message for transmission over a communication network, and device-resident functions, such as a calculator or task list.

0039Operating system software used by the microprocessor <b>1938</b> is preferably stored in a persistent store, such as flash memory <b>1924</b>, which may alternately be a read only memory (ROM) or similar storage element. Those skilled in the art will appreciate that the operating system, specific device applications, or parts thereof, may be temporarily loaded into a volatile store, such as RAM <b>1926</b>. It is contemplated that received communication signals may also be stored to RAM <b>1926</b>.

0040The microprocessor <b>1938</b>, in addition to its operating system functions, preferably enables execution of software applications on the device. A predetermined set of applications that control basic device operations, including at least data and voice communication applications, for example, may be installed on the device <b>24</b> during manufacture. A preferred application that may be loaded onto the device may be a personal information manager (PM) application having the ability to organize and manage data items relating to the device user such as, but not limited to, e-mail, calendar events, voice mails, appointments, and task items. Naturally, one or more memory stores would be available on the device to facilitate storage of PIM data items on the device. Such PIM application would preferably have the ability to send and receive data items, via the wireless network. In a preferred embodiment, the PIM data items are seamlessly integrated, synchronized and updated, via the wireless network, with the device user's corresponding data items stored or associated with a host computer system. Further applications may also be loaded onto the device <b>24</b> through the network <b>1919</b>, an auxiliary I/O subsystem <b>1928</b>, serial port <b>1930</b>, short-range communications subsystem <b>1940</b> or any other suitable subsystem <b>1942</b>, and installed by a user in the RAM <b>1926</b> or preferably a non-volatile store for execution by the microprocessor <b>1938</b>. Such flexibility in application installation increases the functionality of the device and may provide enhanced on-device functions, communication-related functions, or both. For example, secure communication applications may enable electronic commerce functions and other such financial transactions to be performed using the device <b>24</b>.

0041In a data communication mode, a received signal, such as a text message or web page download, will be processed by the communication subsystem <b>1911</b> and input to the microprocessor <b>1938</b>, which will preferably further process the received signal for output to the display <b>1922</b>, or alternatively to an auxiliary I/O device <b>1928</b>. A user of device <b>24</b> may also compose data items, such as email messages, for example, using the keyboard <b>1932</b>, which is preferably a complete alphanumeric keyboard or telephone-type keypad, in conjunction with the display <b>1922</b> and possibly an auxiliary I/O device <b>1928</b>. Such composed items may then be transmitted over a communication network through the communication subsystem <b>1911</b>.

0042For voice communications, overall operation of the device <b>24</b> is substantially similar, except that received signals would preferably be output to a speaker <b>1934</b> and signals for transmission would be generated by a microphone <b>1936</b>. Alternative voice or audio I/O subsystems, such as a voice message recording subsystem, may also be implemented on the device <b>24</b>. Although voice or audio signal output is preferably accomplished primarily through the speaker <b>1934</b>, the display <b>1922</b> may also be used to provide an indication of the identity of a calling party, the duration of a voice call, or other voice call related information for example.

0043The serial port <b>1930</b> in <figref idref="DRAWINGS">FIG. 12</figref> would normally be implemented in a personal digital assistant (PDA)-type communication device for which synchronization with a user's desktop computer (not shown) may be desirable, but is an optional device component. Such a port <b>1930</b> would enable a user to set preferences through an external device or software application and would extend the capabilities of the device by providing for information or software downloads to the device <b>24</b> other than through a wireless communication network. The alternate download path may, for example, be used to load an encryption key onto the device through a direct and thus reliable and trusted connection to thereby enable secure device communication.

0044A short-range communications subsystem <b>1940</b> is a further optional component, which may provide for communication between the device <b>1924</b> and different systems or devices, which need not necessarily be similar devices. For example, the subsystem <b>1940</b> may include an infrared device and associated circuits and components or a Bluetooth™ communication module to provide for communication with similarly-enabled systems and devices.

0045In an alternative embodiment of the present invention, the mobile device <b>24</b> also includes a redirector program. In this embodiment, user selected data items can be replicated from the host to the mobile device and vice versa. The configuration and operation of the mobile device <b>24</b> having a redirector program is similar to that described herein with respect to <figref idref="DRAWINGS">FIGS. 1-4</figref>.

0046A user of the present invention can configure the redirector program <b>12</b> to push certain user-selected data items to the user's mobile device <b>24</b> when the redirector <b>12</b> detects that a particular user-defined event trigger (or trigger point) has taken place. User-selected data items preferably include E-mail messages, calendar events, meeting notifications, address entries, journal entries, personal alerts, alarms, warnings, stock quotes, news bulletins, corporate data (from an Intranet or from behind the corporate firewall), etc., but could, alternatively, include any other type of message that is transmitted to the host system <b>10</b>, or that the host system <b>10</b> acquires through the use of intelligent agents, such as data that is received after the host system <b>10</b> initiates a search of a database or a website or a bulletin board. In some instances, only a portion of the data item is transmitted to the mobile device <b>24</b> in order to minimize the amount of data transmitted via the wireless network <b>22</b>. In these instances, the mobile device <b>24</b> can optionally send a command message to the host system to receive more or all of the data item if the user desires to receive it.

0047Among the user-defined event triggers that can be detected by the redirector program <b>12</b> are in the preferred embodiment external events, internal events and networked events. External events preferably include: (1) receiving a command message (such as message C) from the user's mobile data communication device to begin redirection, or to execute some other command at the host, such as a command to enable the preferred list mode, or to add or subtract a particular sender from the preferred list; (2) receiving a similar message from some external computer; and (3) sensing that the user is no longer in the vicinity of the host system; although, alternatively, an external event can be any other detectable occurrence that is external to the host system. Internal events could be a calendar alarm, screen saver activation, keyboard timeout, programmable timer, or any other user-defined event that is internal to the host system. Networked events are user-defined messages that are transmitted to the host system from another computer coupled to the host system via a network to initiate redirection. These are just some of the events that could be used with the present invention to initiate replication of the user-selected data items from the host system <b>10</b> to the mobile device <b>24</b>.

0048<figref idref="DRAWINGS">FIG. 1</figref> shows an E-mail message A being communicated over LAN <b>14</b> from computer <b>26</b> to the user's desktop system <b>10</b> (also shown in <figref idref="DRAWINGS">FIG. 1</figref> is an external message C, which could be an E-mail message from an Internet user, or could be a command message from the user's mobile device <b>24</b>). Once the message A (or C) reaches the primary message store of the host system <b>10</b>, it can be detected and acted upon by the redirection software <b>12</b>. The redirection software <b>12</b> can use many methods of detecting new messages. The preferred method of detecting new messages is using a message server like Microsoft's® Messaging API (MAPI), IMAP4 server or Lotus Notes messaging API, in which programs, such as the redirector program <b>12</b>, register for notifications or ‘advise syncs’ when changes to a mailbox take place. Other methods of detecting new messages could also be used with the present invention. This tight integration between the redirection program <b>12</b> and a messaging server effectively means the two programs are co-operating to provide a wireless extension to an existing messaging product. In another embodiment, the redirection program is an embedded component of the message server.

0049Assuming that the redirector program <b>12</b> is activated, and has been configured by the user (either through the sensing of an internal, network or external event) to replicate certain user data items (including messages of type A or C) to the mobile device <b>24</b>, when the message A is received at the host system <b>10</b>, the redirector program <b>12</b> detects its presence and prepares the message for redirection to the mobile device <b>24</b>. In preparing the message for redirection, the redirector program <b>12</b> could compress the original message A, could compress the message header, or could encrypt the entire message A to create a secure link to the mobile device <b>24</b>.

0050Also exchanged between the mobile device and the redirector <b>12</b> is a personal identification number (PIN) of the user's mobile device <b>24</b> such that the redirector <b>12</b> associates the mailbox of the user with a PIN. The PIN value could be selected by the manfacturer of the mobile device <b>24</b> and programmed into the mobile device <b>24</b>. Alternatively, this PIN could be a network identifier such as MSISDN, or another value associated with the Subscriber Identity Module (SIM) such as the IMSI. This PIN will be processed by the store-and-forward gateway as it maps the PIN of the mobile device <b>24</b> to the currently assigned IP address. Other values that could be saved by the redirector program <b>12</b> could include: the type of device, and whether the device <b>24</b> can accept certain types of attachments, such as word processing or voice attachments. If the user's type of mobile device cannot accept these types of attachments, then the redirector <b>12</b> can be programmed to route the attachments to a fax or voice number where the user is located using an attached fax or voice machine <b>30</b>.

0051The redirector may also be programmed with a preferred list mode that is configured by the user either at the host system <b>10</b>, or remotely from the user's mobile data communication device by transmitting a command message C. The preferred list contains a list of senders (other users) whose messages are to be redirected or a list of message characteristics that determine whether a message is to be redirected. If activated, the preferred list mode causes the redirector program <b>12</b> to operate like a filter, only redirecting certain user data items based on whether the data item was sent from a sender on the preferred list or has certain message characteristics that if present will trigger or suppress redirection of the message. In the example of <figref idref="DRAWINGS">FIG. 1</figref>, if desktop system <b>26</b> was operated by a user on the preferred list of host system <b>10</b>, and the preferred list option was activated, then message A would be redirected. If, however, desktop <b>26</b> was operated by a user not on the host system's preferred list, then message A would not be redirected, even if the user of the host system had configured the redirector to push messages of type A. The user of the host system <b>10</b> can configure the preferred list directly from the desktop system, or, alternatively, the user can then send a command message (such as C) from the mobile device <b>24</b> to the desktop system <b>10</b> to activate the preferred list mode, or to add or delete certain senders or message characteristics from the preferred list that was previously configured. It should be appreciated that a redirection program could combine message characteristics and preferred sender lists to result in a more finely-tuned filter. Messages marked as low priority or that are simple return receipts or message read receipts, for example, could always be suppressed from redirection while messages from a particular sender would always be redirected.

0052After the redirector has determined that a particular message should be redirected, and it has prepared the message for redirection, the software <b>12</b> then sends the message A to a secondary memory store located in the mobile device <b>24</b>, using whatever means are necessary. In the preferred embodiment this method is to send the message A back over the LAN <b>14</b>, WAN <b>18</b>, and through the store-and-forward gateway <b>20</b> to the mobile data communication device <b>24</b>. In doing so, the redirector preferably repackages message A as an E-mail with an outer envelope B that contains the addressing information of the mobile device <b>24</b>, although alternative repackaging techniques and protocols could be used, such as a TCP/IP repackaging and delivery method (most commonly used in the alternative server configuration shown in <figref idref="DRAWINGS">FIG. 2</figref>). The wireless gateway <b>20</b> requires this outer envelope information B in order to know where to send the redirected message A. Once the message (A in B) is received by the mobile device <b>24</b>, the outer envelope B is removed and the original message A is placed in the secondary memory store within the mobile device <b>24</b>. By repackaging and removing the outer envelope in this manner, the present invention causes the mobile computer <b>24</b> to appear to be at the same physical location as the host system <b>10</b>, thus creating a transparent system.

0053In the case where message C is representative of an external message from a computer on the Internet <b>18</b> to the host system <b>10</b>, and the host <b>10</b> has been configured to redirect messages of type C, then in a similar manner to message A, message C would be repackaged with an outer envelope B and transmitted to the user's mobile device <b>24</b>. In the case where message C is representative of a command message from the user's mobile device <b>24</b> to the host system <b>10</b>, the command message C is not redirected, but is acted upon by the host system <b>10</b>.

0054If the redirected user data item is an E-mail message, as described above, the user at the mobile device <b>24</b> sees the original subject, sender's address, destination address and carbon copy. When the user replies to this message, or when the user authors a new message, the software operating at the mobile device <b>24</b> adds a similar outer envelope to the reply message (or the new message) to cause the message to be routed first to the user's host system <b>10</b>, which then removes the outer envelope and redirects the message to the final destination, such as back to computer <b>26</b>. In the preferred embodiment, this results in the outgoing redirected message from the user's host system <b>10</b> being sent using the E-mail address of the host mailbox, rather than the address of the mobile device, so that it appears to the recipient of the message that the message originated from the user's desktop system <b>10</b> rather than the mobile data communication device. Any replies to the redirected message will then be sent to the desktop system <b>10</b>, which if it is still in redirector mode, will repackage the reply and resend it to the user's mobile data device, as described above.

0055<figref idref="DRAWINGS">FIG. 2</figref> is an alternative system diagram showing the redirection of user data items from a network server <b>11</b> to the user's mobile data communication device <b>24</b>, where the redirector software <b>12</b> is operating at the server <b>11</b>. This configuration is particularly advantageous for use with message servers such as Microsoft's® Exchange Server, Lotus™ Notes Message Server and IMAP4 Message Servers which is normally operated so that all user messages are kept in one central location or mailbox store on the server instead of in a store within each user's desktop PC. This configuration has the additional advantage of allowing a single system administrator to configure and keep track of all users having messages redirected. If the system includes encryption keys, these too can be kept at one place for management and update purposes.

0056In this alternative configuration, server <b>11</b> preferably maintains a user profile for each user's desktop system <b>10</b>, <b>26</b>, <b>28</b>, including information such as whether a particular user can have data items redirected, which types of message and information to redirect, what events will trigger redirection, the PIN of the users' mobile data communication device <b>24</b>, the type of mobile device, and the user's preferred list, if any. The event triggers are preferably detected at the user's desktop system <b>10</b>, <b>26</b>, <b>28</b> and can be any of the external, internal or network events listed above. The desktop systems <b>10</b>, <b>26</b>, <b>28</b> preferably detect these events and then transmit a message to the server computer <b>11</b> via LAN <b>14</b> to initiate redirection. Although the user data items are preferably stored at the server computer <b>11</b> in this embodiment, they could, alternatively, be stored at each user's desktop system <b>10</b>, <b>26</b>, <b>28</b>, which would then transmit them to the server computer <b>11</b> after an event has triggered redirection.

0057As shown in <figref idref="DRAWINGS">FIG. 2</figref>, desktop system <b>26</b> generates a message A that is transmitted to and stored at the host system <b>11</b>, which is the network server operating the redirector program <b>12</b>. The message A is for desktop system <b>10</b>, but in this embodiment, user messages are stored at the network server <b>11</b>. When an event occurs at desktop system <b>10</b>, an event trigger is generated and transmitted to the network server <b>11</b>, which then determines who the trigger is from, whether that desktop has redirection capabilities, and if so, the server (operating the redirector program) uses the stored configuration information to redirect message A to the mobile computer <b>24</b> associated with the user of desktop system <b>10</b>.

0058As described above with reference to <figref idref="DRAWINGS">FIG. 1</figref>, message C could be either a command message from a user's mobile data communication device <b>24</b>, or it could be a message from an external computer, such as a computer connected to the Internet <b>18</b>. If the message C is from an Internet computer to the user's desktop system <b>10</b>, and the user has redirection capabilities, then the server <b>11</b> detects the message C, repackages it using electronic envelope B, and redirects the repackaged message (C in B) to the user's mobile device <b>24</b>. If the message C is a command message from the user's mobile device <b>24</b>, then the server <b>11</b> simply acts upon the command message.

0059Turning now to <figref idref="DRAWINGS">FIG. 3</figref>, a block diagram showing the interaction of the redirector software <b>12</b> with additional components of the host system <b>10</b> of <figref idref="DRAWINGS">FIG. 1</figref> (the desktop PC) to enable more fully the pushing of information from the host system <b>10</b> to the user's mobile data communication device <b>24</b> is set forth. These additional components are illustrative of the type of event-generating systems that can be configured and used with the redirector software <b>12</b>, and of the type of repackaging systems that can be used to interface with the mobile communication device <b>24</b> to make it appear transparent to the user.

0060The desktop system <b>10</b> is connected to LAN <b>14</b>, and can send and receive data, messages, signals, event triggers, etc., to and from other systems connected to the LAN <b>14</b> and to external networks <b>18</b>, <b>22</b>, such as the Internet or a wireless data network, which are also coupled to the LAN <b>14</b>. In addition to the standard hardware, operating system, and application programs associated with a typical microcomputer or workstation, the desktop system <b>10</b> includes the redirector program <b>12</b>, a TCP/IP sub-system <b>42</b>, an E-mail sub-system <b>44</b>, a primary data storage device <b>40</b>, a screen saver sub-system <b>48</b>, and a keyboard sub-system <b>46</b>. The TCP/IP and E-mail subsystems <b>42</b>, <b>44</b> are examples of repackaging systems that can be used to achieve the transparency of the present invention, and the screen saver and keyboard sub-systems <b>46</b>, <b>48</b> are examples of event generating systems that can be configured to generate event messages or signals that trigger redirection of the user selected data items.

0061The method steps carried out by the redirector program <b>12</b> are described in more detail in <figref idref="DRAWINGS">FIG. 4</figref>. The basic functions of this program are: (1) configure and setup the user-defined event trigger points that will start redirection; (2) configure the types of user data items for redirection and optionally configure a preferred list of senders whose messages are to be redirected; (3) configure the type and capabilities of the user's mobile data communication device; (4) receive messages and signals from the repackaging systems and the event generating systems; and (5) command and control the redirection of the user-selected data items to the mobile data communication device via the repackaging systems. Other functions not specifically enumerated could also be integrated into this program.

0062The E-Mail sub-system <b>44</b> is the preferred link to repackaging the user-selected data items for transmission to the mobile data communication device <b>24</b>, and preferably uses industry standard mail protocols, such as SMTP, POP, IMAP, MIME and RFC-822, to name but a few. The E-Mail sub-system <b>44</b> can receive messages A from external computers on the LAN <b>14</b>, or can receive messages C from some external network such as the Internet <b>18</b> or a wireless data communication network <b>22</b>, and stores these messages in the primary data store <b>40</b>. Assuming that the redirector <b>12</b> has been triggered to redirect messages of this type, the redirector detects the presence of any new messages and instructs the E-Mail system <b>44</b> to repackage the message by placing an outer wrapper B about the original message A (or C), and by providing the addressing information, i.e. PIN value of the mobile data communication device <b>24</b> on the outer wrapper B. As noted above, this outer wrapper B is removed by the mobile device <b>24</b>, and the original message A (or C) is then recovered, thus making the mobile device <b>24</b> appear to be the desktop system <b>10</b>.

0063In addition, the E-Mail sub-system <b>44</b> receives messages back from the mobile device <b>24</b> having an outer wrapper with the addressing information of the desktop system <b>10</b>, and strips this information away so that the message can be routed to the proper sender of the original message A (or C). The E-Mail sub-that it has a current valid IP address for the particular mobile device <b>100</b>. It can run an inactivity timer that matches the wireless network's <b>145</b> inactivity timer for tearing down tunnels, and clear the IP address for that mobile when the timer expires. Otherwise, it can implement an address assignment server <b>335</b> and monitor when IP addresses are revoked and assigned to mobiles. Following the two described IP tracking methods, the gateway <b>140</b> determines if it does have a valid IP address. If a valid address does exist, then the gateway <b>140</b> will attempt to bypass steps <b>2</b>-<b>5</b> in <figref idref="DRAWINGS">FIG. 8</figref> and proceed directly to step <b>6</b> directly, which is to send the stored data immediately to the mobile device <b>100</b>.

0064If the validity of the mobile device's <b>100</b> IP address is in question, or if there is no mapping of the particular mobile (i.e., there has never been a packet sent to the device, or if the DHCP has indicated that the IP address was revoked), then the gateway <b>140</b> performs the additional steps <b>2</b>-<b>5</b>.

0065In step <b>2</b>, the gateway <b>140</b> sends a connection request command over the voice network control channel to the mobile device's <b>100</b> voice address, in this case shown as an SMS phone number <b>410</b>. In some networks, like GPRS, it is also possible to send the connection request command over an SMS channel (or some other control channel) of the data network. In this case, the SMS phone number is also used but it does not interfere with the voice component of the device. This connection request command could be implemented in many ways. In one embodiment, the connection request command could be a PING command. For single-mode devices that only communicate over the wireless packet network <b>145</b>, the connection request command could be sent over a low-bandwidth control channel of the packet network <b>145</b>.

0066There are two responses to step <b>2</b>. At this point, in addition to <figref idref="DRAWINGS">FIG. 8</figref> reference may also be made to <figref idref="DRAWINGS">FIGS. 13</figref><i>a </i>and <i>b </i>to further illustrate the two responses. <figref idref="DRAWINGS">FIGS. 13</figref><i>a </i>and <b>13</b><i>b </i>are sequence diagrams illustrating actions taken at the mobile, DHCP and store and forward gateway after a connection request command is made to the mobile. <figref idref="DRAWINGS">FIG. 13</figref><i>a </i>is applicable if the store and forward gateway can directly detect an assignment of a network address by the DHCP while <figref idref="DRAWINGS">FIG. 13</figref><i>b </i>is applicable if the store and forward gateway cannot directly detect the assignment. Preferably, the mobile device <b>100</b> knows which of the two responses to execute because the gateway <b>140</b> instructs the mobile in the connection request command sent in step <b>2</b>. Alternatively, the mobile knows which of the two responses to execute based on the operator of the wireless network (i.e., the operator may program each device at initialization). If the store-and-forward gateway <b>140</b> includes a DHCP server <b>335</b>, has control over the data channel to the DHCP server <b>335</b>, or has some capability to directly detect the assignment of a network address by the DHCP server <b>335</b>, then the mobile simply needs to perform step <b>3</b> and can skip step <b>4</b>. In step <b>3</b>, the mobile device transmits a network address request to the network <b>145</b>, which then allocates a network address to the mobile device <b>100</b>. In this situation, the store-and-forward gateway <b>140</b> will be automatically aware of the new IP address assignment after step <b>3</b> has taken place and will immediately perform steps <b>5</b> and <b>6</b>, which results in the data arriving to the mobile. If the gateway has no control over the DHCP server <b>335</b> or detection capabilities of assignments by the DHCP server, however, then the mobile device <b>100</b> performs step <b>3</b> followed by step <b>4</b>, which causes the newly acquired network address to be sent back to the store-and-forward gateway <b>140</b>. In this example the network address is shown as an IP address, as it is assumed the mobile device <b>100</b> is operating on a IP based wireless network. Other forms of packet addressing, however, could be used with this invention.

0067Alternatively, the mobile device <b>100</b> could be configured to periodically execute step <b>3</b> in order to acquire an IP address, without first receiving the connection request command in step <b>2</b>. In this situation, step <b>2</b> could be omitted. This automatic sending of the IP address at a configured interval is seen as less efficient, however, as the user may have to wait for several minutes for information that is waiting to be delivered to their mobile device <b>100</b>. Normally, the configured interval will be loaded into the mobile device as part of its initial configuration, although it could be updated over-the-air using a secure device updating protocol.

0068When step <b>4</b> is complete, the store-and-forward gateway <b>140</b> will be provided with enough information to map a mobile device <b>100</b> to an IP address. This mapping, shown as step <b>5</b>, is a necessary step for building, addressing and sending an IP packet to the mobile device <b>100</b>. The initial versions of most IP based wireless networks <b>145</b>, like the GPRS network, do not allow a gateway <b>140</b> to initiate a data link (PDP context) to the mobile device <b>100</b>. One of the main reasons for this limitation is because most networks continue to focus on IPv4 (Internet Protocol version 4), which is the original IP definition used within the Internet. This has resulted in a very limited address space and the inability to assign each mobile device <b>100</b> with a fixed IP address. Therefore, wireless network operators have allocated only a small number of ‘real IP addresses’ and use a dynamic address assignment as a preferred strategy. Mobile devices <b>100</b> must therefore have an alternate permanent identifier, and servers must maintain a dynamic link between that permanent identifier of the mobile devicde and the temporary IP address of the mobile device.

0069After the association of mobile device <b>100</b> to IP address is completed, step <b>6</b> can be performed. In this final step, the store-and-forward gateway <b>140</b> sends an IP Packet (either TCP or UDP packet) via the network tunnel to the same mobile device <b>100</b> that established the tunnel <b>325</b>. With the current IP address available to the gateway <b>140</b>, each data packet can be addressed correctly and sent to the device <b>100</b> until the inactivity or out-of-coverage timer expires and the entire IP address reacquiring sequence is performed again. <figref idref="DRAWINGS">FIGS. 9A and 9B</figref> provide a detailed algorithm to describe these steps programmatically.

0070<figref idref="DRAWINGS">FIG. 9A</figref> is a data flow diagram that depicts how a store-and-forward gateway <b>140</b> handles incoming data from redirector programs going to mobile devices. Beginning at step <b>505</b>, data items (<b>215</b>) from a multitude of redirector programs <b>12</b> arrive at the gateway <b>140</b>. Each time a data item <b>215</b> arrives at the gateway <b>140</b>, the gateway <b>140</b> performs a lookup to determine the IP address to mobile device mapping relationship <b>510</b>. The data item <b>205</b> provides information about the destination mobile to enable this lookup, as part of the packaging technique described above. This interaction takes place with a database that holds the IP address to mobile address mapping <b>525</b>A. For one skilled in the art, this database could be a cache mechanism within RAM. This mapping database <b>525</b>A could be an Oracle™ database, a Sybase™ database, or some form of LDAP database. This database is labeled (A). Once the database mapping information is retrieved, the gateway <b>140</b> determines, in step <b>515</b>, if an IP address is present in the database for the particular mobile device. If there is an address present, then the data item can be immediately sent to the mobile device <b>100</b> in step <b>520</b>. In this step <b>520</b>, the gateway <b>140</b> also starts a retry timer in case the data item does not arrive at the mobile device <b>100</b> in a specified time period, in which event it is retransmitted from the gateway <b>140</b>. If the mobile cannot receive the data item after multiple retries, as indicated by the lack of receive acknowledgements, then an expired time value is placed in the mobile's record within the database <b>525</b> to indicate that the IP address has gone stale and should not be used.

0071If there is no IP address for the particular mobile in the database <b>525</b>A, or if the address has expired, then the gateway <b>140</b> determines whether the mobile supports a control channel, such as a connection over a parallel voice network, or a low bandwidth (i.e. supporting only very small data messages) control channel on the data network. If a command channel is not supported, then the gateway <b>140</b> must wait for a spontaneous address request message from the mobile device <b>100</b> in step <b>535</b>. If the network does support command messages, however, then the gateway <b>140</b> determines if it has implemented a DHCP server in step <b>540</b>. If the gateway has implemented a DHCP server, then a flag is set to indicate this support within the command message in step <b>550</b>. In this instance, the command message is a connection request command. Then, in step <b>545</b>, the connection request command is sent to the mobile, with or without the DHCP supported flag set. A timer is also set to indicate that data is pending for this mobile, and a timer is set to catch any situations where the response is missed <b>555</b>.

0072At this point, the gateway <b>140</b> is waiting for a message from the mobile device <b>100</b>, or from the DHCP server <b>335</b>. As shown in <figref idref="DRAWINGS">FIG. 9B</figref>, a signal from the mobile device <b>100</b>, or the DHCP server <b>335</b> will be written to the IP Address mapping storage area <b>525</b>. When this happens, the database <b>525</b> will notify the gateway in step <b>560</b> using traditional callback methods. This callback notification of an event <b>560</b> will cause the gateway <b>140</b> to check whether a new IP address has been assigned to this mobile device <b>100</b> at step <b>565</b>. If the signal from the mobile indicates that a new IP address has been assigned, then control passes to step <b>570</b>, which determines if the data pending flag is set for this particular mobile device. If there is no data pending, then the signal is ignored <b>575</b>. If, however, there is data pending for the mobile device <b>100</b>, then at step <b>585</b> the gateway starts to push TCP or UDP data packets over IP to the mobile device using the new IP address assigned. After each data packet is sent, the idle timer is set or reset for this mobile device <b>100</b> to help ensure the <b>1</b>P address is kept current and is valid.

0073<figref idref="DRAWINGS">FIG. 10</figref> is a continuation of <figref idref="DRAWINGS">FIG. 9</figref>, and is a data flow diagram of how a mobile address to IP address mapping database <b>525</b>A is updated with external and internal events. Beginning at step <b>605</b> in <figref idref="DRAWINGS">FIG. 10A</figref>, data packets arrive at the gateway <b>140</b> from the mobile devices <b>100</b>. These packets are checked to see if they are normal data messages or control messages in step <b>610</b>. If the packet is a normal data packet, then the header of the packet is opened at step <b>615</b>, and the gateway <b>140</b> routes the data to the correct redirector <b>12</b>. The idle timer is also set or reset for this mobile device to ensure that the IP address is kept current and valid at step <b>620</b>. Additionally, the IP mapping database <b>525</b>A is updated in case the IP address for this mobile changed and an expiry timer is set for the mobile to indicate when the IP address might go stale.

0074If the packet is not a normal data packet, however, then the gateway <b>140</b> determines, in step <b>625</b>, if it is a response control packet from the mobile device, such as a PING response control packet <b>640</b> to the connection request command sent in <figref idref="DRAWINGS">FIG. 9</figref>. As indicated previously, this connection request command could be a PING command message. If it is not a PING response packet, then the gateway <b>140</b> determines if the packet is a spontaneous update packet at step <b>630</b>. This spontaneous update packet (or spontaneous address request packet) may be used by the mobile to obtain a valid IP address if the wireless network <b>145</b> does not support a command channel. In either case, the packet is opened and the new IP address is used to update the mobile to IP address mapping <b>640</b> within the address mapping database <b>525</b>A. If the message from the mobile device <b>100</b> is not one of these two control data types, then further checks may be performed at step <b>635</b>.

0075The second type of events that can affect the mapping database <b>525</b>A are internal timer events. The gateway <b>140</b> includes several timers that are set and reset for tracking mobile device <b>100</b> states. When one of these timers expires at step <b>650</b> it must be checked. Another method to perform this would be to keep an expiry time within the table entry for this device, shown in several parts within <figref idref="DRAWINGS">FIGS. 9 and 10</figref>. This expiry timer would be read each time a packet is to be sent to the device to see if the IP address had gone stale. Each time a packet is sent or received from the device, the expiry time is updated to reflect the new activity. In this example, if a timer expires the gateway <b>140</b> will check the mobile's database entry to determine the state of the mobile device in step <b>652</b>. If there has been no response to a PING request packet (i.e., a connection request command) at step <b>656</b>, then the gateway will send another PING packet to the mobile device <b>654</b>. Once this is done, or if there has been no missed PING responses, the gateway <b>140</b> determines if the IP address has expired at step <b>658</b>. If the address has not expired, then other timer related checks are performed at step <b>660</b>. If the IP address has expired, however, then the gateway <b>140</b> will clear the IP address value from the database entry for this mobile device at step <b>662</b> to ensure it cannot be used later.

0076The third type of event that can effect the mobile IP address mapping database <b>525</b>A is external DHCP requests (step <b>670</b>). The first check on these events is to see if a DHCP IP de-register is being requested at step <b>672</b>. If it is, then a flag is set to indicate that the mapping entry for this mobile should be cleared at step <b>680</b>. If it is not this type of DHCP request, then the gateway <b>140</b> determines if it is a DHCP IP register request at step <b>674</b>. If it is, then a flag is set to indicate that the IP address should be set for this mobile at step <b>682</b>. If the DHCP request is neither of these two, however, then it is passed to the normal DHCP processing logic at step <b>676</b>. If the mobile's IP address mapping must be modified, then the IP address mapping database <b>525</b>A is updated at step <b>684</b>. This will either cause the mapping to be cleared (step <b>680</b>) or to be set (step <b>682</b>), which in turn will cause a database event notification to occur. Once this update is complete the normal DHCP processing is completed with the requests <b>684</b>.

0077<figref idref="DRAWINGS">FIG. 11A</figref> is a data flow diagram of the mobile devices' logic for communicating with the store-and-forward gateway <b>140</b>. At step <b>705</b>, data items arrive in from the wireless network, either from the IP based wireless network <b>145</b>, or the voice wireless network <b>150</b>. If the data item is a data packet <b>710</b> from the IP based wireless network <b>145</b>, then it will be delivered to higher-level applications for processing and possibly presentation to the user. Whenever data is received, a poll timer is reset to indicate that the current IP address is valid. Otherwise, the mobile determines if the data item is a connection request command at step <b>715</b>. If the data item is not a connection request command, then at step <b>720</b> the mobile determines if the data item is a tunnel confirmation packet. The tunnel confirmation packet is transmitted from the wireless data network <b>145</b> to the mobile device after a wireless network tunnel <b>325</b> has been established. If it is not a tunnel confirmation packet, then the mobile may perform other checks at step <b>725</b>, depending on the other features of the mobile device.

0078If the packet is a connection request command as determined at step <b>715</b>, then a flag is set at step <b>730</b> to indicate that the gateway <b>140</b> is able to support connection requests on the current wireless network <b>145</b> and/or <b>150</b>. At step <b>735</b>, an additional check of the packet is performed to see if the gateway <b>140</b> also supports DHCP. If so, then a flag is set <b>740</b> to indicate that after the tunnel confirmation packet is received, there is no need to forward the new IP address to the gateway <b>140</b>, as it automatically receives this information when the tunnel is created.

0079Whether or not the gateway <b>140</b> supports DHCP, a tunnel request (or address request) is made by the mobile device <b>100</b> to request a new tunnel and a new IP address at step <b>745</b>. If the packet received is a tunnel confirmation message at step <b>720</b>, then the flow diagram proceeds to <figref idref="DRAWINGS">FIG. 11B</figref>.

0080In <figref idref="DRAWINGS">FIG. 11B</figref> the gateway first determines if the DHCP flag is turned on at step <b>785</b>. If it is, then the new IP address is saved <b>795</b> in the IP address mapping database <b>525</b>B. This address mapping database <b>525</b>B is a smaller version of the host address mapping database <b>525</b>A, which contains all mobile devices and their current states. If there is no DHCP support, then the new IP address is saved at step <b>780</b>, and the mobile sends an address request response message to the gateway <b>140</b> to inform it of the new IP address for data exchange at step <b>775</b>.

0081When the mobile device <b>100</b> first starts it is necessary to run a poll timer just in case the gateway <b>140</b> is unable to send connection request packets. Whenever the poll timer expires <b>742</b>, the software in the mobile determines if a long or a short timer is running <b>750</b>. The long timer is used as a fail-safe mechanism to ensure the gateway <b>140</b> never gets confused about the state of the device. The long timer is used primarily when connection requests are supported. The long timer could be hours or days long and when it expires causes a tunnel check operation to be executed <b>755</b>. If a short poll timer is running, the mobile determines if a connection request has ever been received by checking the connection request flag <b>760</b>. If a connection request was received, then the flag is turned on, which will cause the poll timer to be lengthened to the long timeout value. Otherwise, the mobile will perform a tunnel checking operation, which would involve sending an IP packet to itself or to the gateway, on what should be a valid tunnel <b>755</b>. The IP based wireless network <b>145</b> will return an error if the device <b>100</b> does not have a valid tunnel established with the gateway <b>140</b>. If the tunnel <b>765</b> is invalid or not present, the mobile device <b>100</b> performs a tunnel request operation <b>745</b> to the network to acquire a new tunnel and a new IP address. If the tunnel is valid, then the current IP address is saved and immediately sent to the gateway <b>140</b> via a connection response message.

0082Having described in detail the preferred embodiments of the present invention, including the preferred methods of operation, it is to be understood that this operation could be carried out with different elements and steps. This preferred embodiment is presented only by way of example and is not meant to limit the scope of the present invention, which is defined by the following claims.