Patent Application
20080045267
1. Field of the Invention
The 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.
2. Description of the Related Art
Wireless 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 arc accessing the network at a given instant.
As described in more detail in the co-pending, and co-owned application Ser. No., 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.
A 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.
The 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.
Using 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.
In 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.
The 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.
Once 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.
In 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.
In 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.
The 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.
a and 13b 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.
Referring now to the drawings,
In
In the example of
The preferred mobile data communication device 24 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 22. 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 24 includes software program instructions that work in conjunction with the redirector program 12 to enable the seamless, transparent redirection of user-selected data items.
One example of a dual-mode device is shown in
Where the device 24 is enabled for two-way communications, the device will incorporate a communication subsystem 1911, including a receiver 1912, a transmitter 1914, and associated components such as one or more, preferably embedded or internal, antenna elements 1916 and 1918, local oscillators (LOs) 1913, and a processing module such as a digital signal processor (DSP) 1920. As will be apparent to those skilled in the field of communications, the particular design of the communication subsystem 1911 will be dependent upon the communication network in which the device is intended to operate. For example, a device 24 destined for a North American market may include a communication subsystem 1911 designed to operate within the Mobitex™ mobile communication system or the DataTAC™ mobile communication system, whereas a device 24 intended for use in Europe may incorporate a General Packet Radio Service (GPRS) communication subsystem 1911.
Network access requirements will also vary depending upon the type of network 1919. For example, in the Mobitex and DataTAC networks, mobile devices 24 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 24. 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 24 will be unable to carry out any functions involving communications over the network 1919. When required network registration or activation procedures have been completed, a device 24 may send and receive communication signals over the network 1919. Signals received by the antenna 1916 through a communication network 1919 are input to the receiver 1912, 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
The DSP 1920 not only processes communication signals, but also provides for receiver and transmitter control. For example, the gains applied to communication signals in the receiver 1912 and transmitter 1914 may be adaptively controlled through automatic gain control algorithms implemented in the DSP 1920.
The device 24 preferably includes a microprocessor 1938, which controls the overall operation of the device. Communication functions, including at least data and voice communications, are performed through the communication subsystem 1911. The microprocessor 1938 also interacts with other device subsystems, such as the display 1922, flash memory 1924, random access memory (RAM) 1926, auxiliary input/output (I/O) subsystems 1928, serial port 1930, keyboard 1932, speaker 1934, microphone 1936, a short-range communications subsystem 1940 and any other device subsystems generally designated as 1942.
Some of the subsystems shown in
Operating system software used by the microprocessor 1938 is preferably stored in a persistent store, such as flash memory 1924, 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 1926. It is contemplated that received communication signals may also be stored to RAM 1926. L
The microprocessor 1938, 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 24 during manufacture. A preferred application that may be loaded onto the device may be a personal information manager (PIM) 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 24 through the network 1919, an auxiliary I/O subsystem 1928, serial port 1930, short-range communications subsystem 1940 or any other suitable subsystem 1942, and installed by a user in the RAM 1926 or preferably a non-volatile store for execution by the microprocessor 1938. 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 24.
In a data communication mode, a received signal, such as a text message or web page download, will be processed by the communication subsystem 1911 and input to the microprocessor 1938, which will preferably further process the received signal for output to the display 1922, or alternatively to an auxiliary IPO device 1928. A user of device 24 may also compose data items, such as email messages, for example, using the keyboard 1932, which is preferably a complete alphanumeric keyboard or telephone-type keypad, in conjunction with the display 1922 and possibly an auxiliary I/O device 1928. Such composed items may then be transmitted over a communication network through the communication subsystem 1911.
For voice communications, overall operation of the device 24 is substantially similar, except that received signals would preferably be output to a speaker 1934 and signals for transmission would be generated by a microphone 1936. Alternative voice or audio I/O subsystems, such as a voice message recording subsystem, may also be implemented on the device 24. Although voice or audio signal output is preferably accomplished primarily through the speaker 1934, the display 1922 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.
The serial port 1930 in
A short-range communications subsystem 1940 is a farther optional component, which may provide for communication between the device 1924 and different systems or devices, which need not necessarily be similar devices. For example, the subsystem 1940 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.
In an alternative embodiment of the present invention, the mobile device 24 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 24 having a redirector program is similar to that described herein with respect to
A user of the present invention can configure the redirector program 12 to push certain user-selected data items to the user's mobile device 24 when the redirector 12 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 10, or that the host system 10 acquires through the use of intelligent agents, such as data that is received after the host system 10 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 24 in order to minimize the amount of data transmitted via the wireless network 22. In these instances, the mobile device 24 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.
Among the user-defined event triggers that can be detected by the redirector program 12 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, F 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 10 to the mobile device 24.
Assuming that the redirector program 12 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 24, when the message A is received at the host system 10, the redirector program 12 detects its presence and prepares the message for redirection to the mobile device 24. In preparing the message for redirection, the redirector program 12 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 24.
Also exchanged between the mobile device and the redirector 12 is a personal identification number (PIN) of the user's mobile device 24 such that the redirector 12 associates the mailbox of the user with a PIN. The PIN value could be selected by the manfacturer of the mobile device 24 and programmed into the mobile device 24. 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 24 to the currently assigned IP address. Other values that could be saved by the redirector program 12 could include: the type of device, and whether the device 24 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 12 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 30.
The redirector may also be programmed with a preferred list mode that is configured by the user either at the host system 10, 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 12 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
After the redirector has determined that a particular message should be redirected, and it has prepared the message for redirection, the software 12 then sends the message A to a secondary memory store located in the mobile device 24, using whatever means are necessary. In the preferred embodiment this method is to send the message A back over the LAN 14, WAN 18, and through the store-and-forward gateway 20 to the mobile data communication device 24. 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 24, 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
In the case where message C is representative of an external message from a computer on the Internet 18 to the host system 10, and the host 10 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 24. In the case where message C is representative of a command message from the user's mobile device 24 to the host system 10, the command message C is not redirected, but is acted upon by the host system 10.
If the redirected user data item is an E-mail message, as described above, the user at the mobile device 24 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 24 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 10, which then removes the outer envelope and redirects the message to the final destination, such as back to computer 26. In the preferred embodiment, this results in the outgoing redirected message from the user's host system 10 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 10 rather than the mobile data communication device. Any replies to the redirected message will then be sent to the desktop system 10, 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.
In this alternative configuration, server 11 preferably maintains a user profile for each user's desktop system 10, 26, 28, 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 24, 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 10, 26, 28 and can be any of the external, internal or network events listed above. The desktop systems 10, 26, 28 preferably detect these events and then transmit a message to the server computer 11 via LAN 14 to initiate redirection. Although the user data items are preferably stored at the server computer 11 in this embodiment, they could, alternatively, be stored at each user's desktop system 10, 26, 28, which would then transmit them to the server computer 11 after an event has triggered redirection.
As shown in
As described above with reference to
Turning now to
The desktop system 10 is connected to LAN 14, and can send and receive data, messages, signals, event triggers, etc., to and from other systems connected to the LAN 14 and to external networks 18, 22, such as the Internet or a wireless data network, which are also coupled to the LAN 14. In addition to the standard hardware, operating system, and application programs associated with a typical microcomputer or workstation, the desktop system 10 includes the redirector program 12, a TCP/IP sub-system 42, an E-mail sub-system 44, a primary data storage device 40, a screen saver sub-system 48, and a keyboard sub-system 46. The TCP/IP and E-mail subsystems 42, 44 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 46, 48 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.
The method steps carried out by the redirector program 12 are described in more detail in
The E-Mail sub-system 44 is the preferred link to repackaging the user-selected data items for transmission to the mobile data communication device 24, 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 44 can receive messages A from external computers on the LAN 14, or can receive messages C from some external network such as the Internet 18 or a wireless data communication network 22, and stores these messages in the primary data store 40. Assuming that the redirector 12 has been triggered to redirect messages of this type, the redirector detects the presence of any new messages and instructs the E-Mail system 44 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 24 on the outer wrapper B. As noted above, this outer wrapper B is removed by the mobile device 24, and the original message A (or C) is then recovered, thus making the mobile device 24 appear to be the desktop system 10.
In addition, the E-Mail sub-system 44 receives messages back from the mobile device 24 having an outer wrapper with the addressing information of the desktop system 10, 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-system system also receives command messages C from the mobile device 24 that are directed to the desktop system 10 to trigger redirection or to carry out some other function. The wireless enablement of the E-Mail sub-system 44 is made possible through the redirector program 12.
The TCP/IP sub-system 42 is an alternative repackaging system. It includes all of the functionality of the E-Mail sub-system 44, but instead of repackaging the user-selected data items as standard E-mail messages, this system repackages the data items using special-purpose TCP/IP packaging techniques. This type of special-purpose sub-system is useful in situations where security and improved speed are important to the user. The provision of a special-purpose wrapper that can only be removed by special software on the mobile device 24 provides the added security, and the bypassing of E-mail store and forward systems can improve speed and real-time delivery.
As described previously, the present invention can be triggered to begin redirection upon detecting numerous external, internal and networked events, or trigger points. The screen saver and keyboard sub-systems 46, 48 are examples of systems that are capable of generating internal events. Functionally, the redirector program 12 provides the user with the ability to configure the screen saver and keyboard systems so that under certain conditions a event trigger will be generated that can be detected by the redirector 12 to start the redirection process. For example, the screen saver system can be configured so that when the screen saver is activated, after, for example, 10 minutes of inactivity on the desktop system, an event trigger is transmitted to the redirector 12, which starts redirecting the previously selected user data items. In a similar manner the keyboard sub-system can be configured to generate event triggers when no key has been depressed for a particular period of time, thus indicating that redirection should commence. These are just two examples of the numerous application programs and hardware systems internal to the host system 10 that can be used to generate internal event triggers.
The redirector program preferably adds a permanent identifier on the outer envelop during the repackaging step. Advantagously this permits association of the data items upon arrival at the store-and-forward gateway with the mobile devices newly assigned network address. Since the IP address associated to the mobile device could change, the permanent identifier used by the redirector program could be a manufacturing number assigned when the unit is built, a value from the SIM card, or a network specific identifier.
Once the redirector program is configured 50, the trigger points (or event triggers) are enabled at step 52. The program 12 then waits 56 for messages and signals 54 to begin the redirection process. A message could be an E-Mail message or some other user data item than may have been selected for redirection, and a signal could be a trigger signal, or could be some other type of signal that has not been configured as an event trigger. When a message or signal is detected, the program determines 58 whether it is one of the trigger events that has been configured by the user to signal redirection. If so, then at step 60 a trigger flag is set, indicating that subsequently received user data items (in the form of messages) that have been selected for redirection should be pushed to the user's mobile data communication device 24.
If the message or signal 54 is not a trigger event, the program then determines at steps 62, 68 and 66 whether the message is, respectively, a system alarm 62, an E-Mail message 64, or some other type of information that has been selected for redirection. The other event might also be if the user turns off the triggering flag, by either placing the device back into the serial cradle, or by sending a command to the redirector software to stop redirection. If the message or signal is none of these three items, then control returns to step 56, where the redirector waits for additional messages 54 to act upon. If, however the message is one of these three types of information, then the program 12 determines, at step 68, whether the trigger flag has been set, indicating that the user wants these items redirected to the mobile device. If the trigger flag is set, then at step 70, the redirector 12 causes the repackaging system (E-Mail or TCP/IP) to add the outer envelope to the user data item, and at step 72 the repackaged data item is then redirected to the user's mobile data communication device 24 via LAN 14, WAN 18, wireless gateway 20 and wireless network 22. Control then returns to step 56 where the program waits for additional messages and signals to act upon. Although not shown explicitly in
At step 82, the mobile device waits for messages and signals 84 to be generated or received. Assuming that the redirector software 12 operating at the user's desktop system 10 is configured to redirect upon receiving a message from the user's mobile device 24, at step 86, the user can decide to generate a command message that will start redirection. If the user does so, then at step 88 the redirection message is composed and sent to the desktop system 10 via the wireless network 22, through the wireless gateway 20, via the Internet 18 to the LAN 14, and is finally routed to the desktop machine 10. In this situation where the mobile device 24 is sending a message directly to the desktop system 10, no outer wrapper is added to the message (such as message C in
In addition to the redirection signal, the mobile device 24 could transmit any number of other commands to control the operation of the host system, and in particular the redirector program 12. For example, the mobile 24 could transmit a command to put the host system into the preferred list mode, and then could transmit additional commands to add or subtract certain senders from the preferred list. In this manner, the mobile device 24 can dynamically limit the amount of information being redirected to it by minimizing the number of senders on the preferred list. Other example commands include: (1) a message to change the configuration of the host system to enable the mobile device 24 to receive and process certain attachments; and (2) a message to instruct the host system to redirect an entire data item to the mobile device in the situation where only a portion of a particular data item has been redirected. Another embodiment of a command process would be when the mobile device 24 sends a search command (preferably with search parameters associated therewith) to the host system 10, which in turn triggers (or initiates) a search on an associated database that in turn produces search results that are returned to the mobile device 24 at a later time.
Turning back to
If the mobile device 24 determines that a message has not been received at step 90, then control passes to step 100′, where the mobile determines whether there is a message to send. If not, then the mobile unit returns to step 82 and waits for additional messages or signals. If there is at least one message to send, then at step 102 the mobile determines whether it is a reply message to a message that was received by the mobile unit. If the message to send is a reply message, then at step 108, the mobile determines whether the desktop redirection flag is on for this message. If the redirection flag is not on, then at step 106 the reply message is simply transmitted from the mobile device to the destination address via the wireless network 22. If, however, the redirection flag is on, then at step 110 the reply message is repackaged with the outer envelope having the addressing information of the user's desktop host system 10, and the repackaged message is then transmitted to the host system 10 at step 106. As described above, the redirector program 12 executing at the host system then strips the outer envelope and routes the reply message to the appropriate destination address using the address of the user's e-mail account associated with the host system as the “from” field, so that to the recipient of the redirected message, it appears as though it originated from the user's host system rather than the mobile device. In an alternative embodiment a tag or signature line is added to the message (at either the device or the host system) to indicate that it has been sent from a mobile device 24 whilst the mobile device and host system continue to share a common single email address. This integrated common email address provides the host system (desktop or server system) with seamless wireless connectivity to the mobile device.
If, at step 102, the mobile device determines that the message is not a reply message, but an original message, then control passes to step 104, where the mobile determines if the user is using the redirector software 12 at the host system 10, by checking the mobile device's configuration. If the user is not using the redirector software 12, then the message is simply transmitted to the destination address at step 106. If, however, the mobile determines that the user is using the redirector software 12 at the host system 10, then control passes to step 110, where the outer envelope is added to the message. The repackaged original message is then transmitted to the host system 10 at step 106, which, as described previously, strips the outer envelope and routes the message to the correct destination. Following transmission of the message at step 106, control of the mobile returns to step 82 and waits for additional messages or signals.
Turning now to the remaining drawing figures,
In one embodiment, when a serial docking cradle 110 is used as a means of docking or undocking the mobile device 100, the serial docking cradle preferably has the ability to inform the redirector program 12 when the mobile device 100 is not in the cradle and therefore should be reached by the IP based wireless network 145. Preferably, only when the mobile device 100 is in the serial cradle 110, and behind the company's firewall 160, can it exchange shared secrets such as encryption keys, with the user's host system 120. Advantageously, these shared secrets can then be used by the redirection system to encrypt all data items being exchanged over the network 145.
The redirector program 12 may also have the ability to compress information that is redirected to the mobile device 100, and thus increase data transfer rates through any delivery mechanism that is used. The redirector program 12 may also connect to a wide range of other devices, such as home or office alarm systems, personal monitoring equipment, such as a vital sign monitor, motion detectors, Internet web sites, e-mail message stores, PBX information storage, customer databases, proprietary software applications, Intranet-based data stores and other information sources, for the purpose of collecting information to redirect to the mobile device 100.
As described above, the present invention preferably provides a redirection computer program (“redirector program”) 12, operating within (or in conjunction with) the host system 120, behind a corporate firewall 160. Preferably in conjunction with a message server or some other hardware or software mechanism, the redirector 12 senses that a particular event has occurred, and redirects user-selected data items from the host system 120 to the user's mobile device 100. In one embodiment, the redirector program 12 also interfaces to a mobile device cradle component 110, over a serial connection 115, or some other suitable computer communication method, so that the redirector program 12 can detect the physical location, as well as other information, of the mobile device 100. The mobile device cradle component 110 provides a communication node (or a physical serial link 105) for the mobile device 100 that allows the user to dock the mobile device 100 when the user is in their office. Alternatively, connection 105 could be a wireless connection, such as a short-range RF connection. This docking procedure is one method for exchanging bulk personal information locally (versus over a wireless communication network), such as, but not limited to, e-mail messages, calendar events, contacts, notes, and security information like encryption keys.
The host system/redirector program 120/12 are also coupled to an external network 18, such as the Internet. The external network 18 could be the Internet, a company Intranet, and Extranet, a private network like an America On Line (“AOL™”) network, a LAN, or some other network capable of exchanging information. The connection between the host system 120 and this external network 18 could use a range of existing technologies, such as Ethernet, Cable Modem, DSL, ISDN, or Frame Relay.
By coupling to the external network 18, the redirector program 12 has another communication path to reach the mobile device 100, if the mobile device is not docked with the host system 120. As shown in
The store-and-forward gateway 140 performs routing and addressing functions allow information to be pushed to a mobile device 100 in the IP based wireless network 145. The store-and-forward gateway 140 stores information from the redirector program 12 for a particular user until the user's mobile device 100 has acquired a network address (on the IP based wireless network 145). Once a network address is acquired, the store-and-forward gateway 140 forwards the stored, redirected information to the user's mobile device 100. In this manner, the gateway 140 operates as a store-and-forward system. Another function of the store-and-forward gateway 140 is to bridge dissimilar networks and allow for data flow in both directions to and from the mobile device 100. In the illustration these dissimilar networks include the Internet and the IP-based wireless network. Although they share a common network layer, i.e. the IP layer, their speeds and capabilities are so different that protocols like TCP cannot work reliably over both at the same time. Once data is delivered to the IP based wireless network 145, it can be routed to the mobile device 100 and received via an RF link 155.
The term IP based wireless network includes, but is not limited to (1) the Code Division Multiple Access (CDMA) network that has been developed and operated by Qualcomm, (2) the General Packet Radio Service (GPRS) for use in conjunction with the Global System for Mobile Communications (GSM) network both developed by the standards committee of CEPT, and (3) future third-generation (3G) networks like EDGE and UMTS. GPRS is a data communications overlay on top of the GSM wireless network. It is to be understood that although an IP based wireless network is shown in
The redirector program 12 operates either at a desktop workstation, or within a network server 120, or in conjunction with a message server, or directly within a message server which receives data items 205 for a particular user. When the redirector program 12 is configured at a network server, it can monitor the data items 205 for many users simultaneously. The data items 205 may originate from Internet sources 18, from other LAN workstations 26, 28, from other mobile users, or from some external source, such as a PSTN connection into the host system. These data items 205 could include: (1) company phone calls, (2) corporate intranet and Internet e-mail, (3) corporate inventory records, (4) corporate sales projects, (5) corporate sales and marketing forms, (6) company field service records, (7) company call dispatch requests, (8) real-time phone calls, (9) instant messages from instant messaging gateways, (10) company or home alarm data, (11) motion and video sensors, (12) heart monitors and vital statistic monitors, (13) fluid levels and large equipment feedback statistics, (14) corporate and personal PIM data, as well as other data types not explicitly mentioned.
To understand the flow of data in the system shown in
The second step (B) occurs when the redirector application 12 detects the data items 205 at the host system 120, and the redirection criteria set up by the user or network administrator have been met. Having preferably pre-selected the type(s) and class(es) of data items 205 for redirection, the redirector 12 may provide the user with additional controls for limiting, filtering and monitoring all data items 205 that could be redirected to their mobile device 100. The redirector program 12 may provide the following functions: (a) when to redirect data items 205 based on user-defined triggers such as location information, heat sensors, motion detectors and screen savers, (b) providing configuration information, such as filters, desired data types 205 and mobile device 100 capabilities, and (c) continuously redirecting data items 205 as they arrive at the host system 120, in real-time, to the mobile device 100.
Finally, in step (C), the redirector program 12 repackages the data items 215 so that complete transparency is maintained for the sender and the receiver of the data item, and transmits the data items out through the corporate firewall 160 to the mobile device 100 via the external network 18 and the wireless packet data network 145. Preferably, the transparency feature permits all addressing information (such as the ‘TO’, ‘CC’, and ‘FROM’ fields), subjects and content fields to be kept intact provided that the mobile device can support all elements of the original data item 205.
Once the original data item 205 is repackaged it is delivered along a path to the IP based wireless network 145, via the store-and forward gateway normally through a connection to the Internet 18. A person skilled in the art would also appreciate that there may be many other methods to reach the store-and-forward gateway like a direct point-to-point connection, which is more common when security and speed are major issues. Step (C) may be optionally skipped when the device is docked at the host system 120. The user may not want any data items 215 forwarded to the mobile device 100 when they are sitting at their desktop computer system 120, or logged into the office network computer system and are capable of accessing their message store associated with the message server at the host system (via a networked computer).
The GPRS IP based data network is an overlay over the GSM voice network. In this network, the GPRS components will either extend existing GSM components, such as the base stations, or could cause additional components to be added, like an advanced Gateway GPRS Support Node (GGSN) network entry point 305.
The network entry point 305 is generally used to multiplex and demultiplex between many gateways, corporate servers and bulk connections like the Internet 18. There are normally very few of these network entry points 305 as they are also intended to centralize externally available wireless network services. The network entry point 305 often uses some form of address assignment component 335 that assists in address assignment and lookup between gateways 145 and mobile devices 100. In this example, the dynamic host configuration protocol (DHCP 335) is shown as one method for providing an address assignment mechanism. The invention, however, is not limited to networks that use DHCP.
A component of the wireless data network 145 is a network router 315. Normally these network routers 315 are proprietary to the particular network, but they could be constructed from standard off-the-shelf hardware as well. Their purpose is to centralize the thousands of base stations 320 into a central location for a long-haul connection back to the network entry point 305. In some networks there could be multiple tiers of network routers 315, and cases where there are master and slave network routers 315, but in all cases the functions are similar. Often the network router 315 will access a name server 310, in this case shown as a Domain Name System (DNS) 310 as used in the Internet, to look up destinations for routing data messages. The base stations 320 act as the Radio Frequency (RF) link to the mobile devices 100.
A problem faced by most IP based wireless networks 145 is that the wireless equipment (
This tunneling operation is illustrated in
The wireless network tunnel 325 typically has a very limited life, depending on the mobile's 100 coverage profile and activity. The wireless network 145 will tear down the tunnel 325 after a certain period of inactivity or out-of-coverage period, in order to recapture the resources held by this tunnel 325 for other users. The main reason for this is to reclaim the IP address temporarily reserved for that mobile device 100 when the tunnel 325 was first opened. Once the IP address is lost, i.e. re-assigned to another mobile device 100 and the tunnel is broken down, the store and forward gateway 140 then loses all ability to initiate IP data packets to the device, either over TCP or over UDP. If the mobile device 100 has been out of coverage for some time, and has nothing to send to the store-and-forward gateway 145, then the mobile devices may not be informed that the tunnel 325 has been lost. This can occur when the network idle timer expires and the mobile device 100 is out of coverage and cannot receive the notification that that tunnel has been closed. Therefore the mobile device 100 cannot request a new tunnel to get a new IP address to give to the store-and-forward gateway 145. If data arrives sometime later for the mobile device one aspect of the present invention solves this problem. Specifically when an IP address is unassigned the DHCP server is utilized and the DHCP monitor by the store-and-forward gateway will also be informed. Then when data arrives an SMS message is sent to the mobile device 100 requesting the tunnel be re-opened.
In some wireless networks 145 it is possible that the gateway 140 itself implements the DHCP server 335, or whatever address assignment method is used, that is accessed by the network entry point 305. In this configuration, the store-and-forward gateway 140 is able to know when a mobile device 100 loses its IP address, which will ensure that data is not pushed to an ‘invalid’ IP address by the gateway. Without an integral address assignment mechanism, however, the store-and-forward gateway 140 may have to implement a timeout mechanism (or some other form of mechanism) to indicate when an IP-to-mobile address mapping has become stale and could be invalid. This timeout mechanism could be configurable, and set to match a network timeout value for inactivity or out-of-coverage tunnel breakdown.
In step 1 of
If the validity of the mobile device's 100 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 140 performs the additional steps 2-5.
In step 2, the gateway 140 sends a connection request command over the voice network control channel to the mobile device's 100 voice address, in this case shown as an SMS phone number 410. 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 145, the connection request command could be sent over a low-bandwidth control channel of the packet network 145.
There are two responses to step 2. At this point, in addition to
Alternatively, the mobile device 100 could be configured to periodically execute step 3 in order to acquire an IP address, without first receiving the connection request command in step 2. In this situation, step 2 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 100. 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.
When step 4 is complete, the store-and-forward gateway 140 will be provided with enough information to map a mobile device 100 to an IP address. This mapping, shown as step 5, is a necessary step for building, addressing and sending an IP packet to the mobile device 100. The initial versions of most IP based wireless networks 145, like the GPRS network, do not allow a gateway 140 to initiate a data link (PDP context) to the mobile device 100. 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 100 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 100 must therefore have an alternate permanent identifier, and servers must maintain a dynamic link between that permanent identifier of the mobile device and the temporary IP address of the mobile device.
After the association of mobile device 100 to IP address is completed, step 6 can be performed. In this final step, the store-and-forward gateway 140 sends an IP Packet (either TCP or UTDP packet) via the network tunnel to the same mobile device 100 that established the tunnel 325. With the current IP address available to the gateway 140, each data packet can be addressed correctly and sent to the device 100 until the inactivity or out-of-coverage timer expires and the entire IP address reacquiring sequence is performed again.
If there is no IP address for the particular mobile in the database 525A, or if the address has expired, then the gateway 140 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 140 must wait for a spontaneous address request message from the mobile device 100 in step 535. If the network does support command messages, however, then the gateway 140 determines if it has implemented a DHCP server in step 540. If the gateway has implemented a DHCP server, then a flag is set to indicate this support within the command message in step 550. In this instance, the command message is a connection request command. Then, in step 545, 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 555.
At this point, the gateway 140 is waiting for a message from the mobile device 100, or from the DHCP server 335. As shown in
If the packet is not a normal data packet, however, then the gateway 140 determines, in step 625, if it is a response control packet from the mobile device, such as a PING response control packet 640 to the connection request command sent in
The second type of events that can affect the mapping database 525A are internal timer events. The gateway 140 includes several timers that are set and reset for tracking mobile device 100 states. When one of these timers expires at step 650 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
The third type of event that can effect the mobile IP address mapping F database 525A is external DHCP requests (step 670). The first check on these events is to see if a DHCP IP de-register is being requested at step 672. If it is, then a flag is set to indicate that the mapping entry for this mobile should be L cleared at step 680. If it is not this type of DHCP request, then the gateway 140 determines if it is a DHCP IP register request at step 674. If it is, then a flag is set to indicate that the IP address should be set for this mobile at step 682. If the DHCP request is neither of these two, however, then it is passed to the normal DHCP processing logic at step 676. If the mobile's IP address mapping must be modified, then the IP address mapping database 525A is updated at step 684. This will either cause the mapping to be cleared (step 680) or to be set (step 682), 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 684.
If the packet is a connection request command as determined at step 715, then a flag is set at step 730 to indicate that the gateway 140 is able to support connection requests on the current wireless network 145 and/or 150. At step 735, an additional check of the packet is performed to see if the gateway 140 also supports DHCP. If so, then a flag is set 740 to indicate that after the tunnel confirmation packet is received, there is no need to forward the new IP address to the gateway 140, as it automatically receives this information when the tunnel is created.
Whether or not the gateway 140 supports DHCP, a tunnel request (or address request) is made by the mobile device 100 to request a new tunnel and a new IP address at step 745. If the packet received is a tunnel confirmation message at step 720, then the flow diagram proceeds to
In
When the mobile device 100 first starts it is necessary to run a poll timer just in case the gateway 140 is unable to send connection request packets. Whenever the poll timer expires 742, the software in the mobile determines if a long or a short timer is running 750. The long timer is used as a fail-safe mechanism to ensure the gateway 140 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 755. If a short poll timer is running, the mobile determines if a connection request has ever been received by checking the connection request flag 760. 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 755. The IP based wireless network 145 will return an error if the device 100 does not have a valid tunnel established with the gateway 140. If the tunnel 765 is invalid or not present, the mobile device 160 performs a tunnel request operation 745 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 140 via a connection response message.
Having 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.
This application claims priority from U.S. Provisional Applications Ser. No. 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. The complete disclosure of each of these provisional applications, including drawings and claims, is hereby incorporated into this application by reference.
| Number | Date | Country | |
|---|---|---|---|
| Parent | 10381163 | Mar 2003 | US |
| Child | 11925866 | Oct 2007 | US |
