System and Method for Data Transport

Abstract

A data agnostic transport system that may be used for data objects such as email, calendar, notes, files, and multimedia.

Description

CROSS-REFERENCE TO RELATED APPLICATIONS

The present application claims the priority benefit of U.S. provisional patent application No. 61/062,797 filed Jan. 28, 2008 and entitled “Systems and Methods for Data Transport.”

This application is related to U.S. patent application Ser. No. 12/361,520, filed Jan. 28, 2009 and entitled “Integrated Messaging,” the disclosure of which is incorporated herein by reference.

BACKGROUND

1. Field of the Invention

The present invention is generally related to the transport of data in a network. More specifically, the present invention is related to the transport of data objects to a mobile device from a data store in a mobile network without relying upon a store-and-forward methodology.

2. Description of the Related Art

Prior art data transport systems rely upon a store-and-forward approach that requires enormous server farms. Due to the immense amount of data stored for eventual forwarding, these systems are prone to collapse. A collapse jeopardizes data that has already been processed from a native data source to the extent that a store-and-forward system does not utilize any backup or redundancy precautions.

There is a need in the art for a scalable data transport system that does not rely upon a store-and-forward methodology and, further, that maintains the integrity of an original data object at the initial data source.

SUMMARY OF THE CLAIMED INVENTION

In a first claimed embodiment, a system is recited. The system includes a mobile device, a facilitating server, and a data source, wherein a data object at the data source is transported to the mobile device by way of the facilitating server.

BRIEF DESCRIPTION OF THE FIGURES

FIG. 1 illustrates a data transport system.

DETAILED DESCRIPTION

FIG. 1 illustrates a data transport system 100 in an embodiment of the presently disclosed invention. System 100 is inclusive of mobile device 110, which hosts an SMS agent 120 and transport protocol application 130. Facilitating server 140 communicatively couples the mobile device 110 to data sources 150 over a network. System 100 may further include an optional proxy server 160 and a firewall 170.

Mobile device 110 is inclusive of any variety of mobile devices that are capable of communicating over the Internet. Mobile device 110 is inclusive of cellular telephones, smart phones, personal digital assistants (PDAs), wireless e-mail devices, and handheld computing devices. A variety of mobile networks and communications channels for enabling Internet access are well known in the art.

Mobile device 110 may be configured for communications over a Global System for Mobile communications (GSM), the General Packet Radio Service (GPRS), Enhanced Data rates for GSM Evolution (EDGE), Code Division Multiple Access (CDMA), or networks using the 3G mobile network standard. Mobile device 110 may include any number of applications or provisioned services. Exemplary applications hosted at the mobile device 110 include the aforementioned SMS agent 120 and Transport Protocol Application 130.

The SMS agent 120 may allow for operation in a hybrid mode (i.e., not purely Internet Protocol based). Keeping an Internet Protocol address open at all times, for some network operators, may be difficult as there is finite number of addresses available for numerous handsets. Time limits may be set for a particular Internet Protocol connection. Internet Protocol connections may be allowed so long as there is an active transmission. Keeping an Internet Protocol connection (and related address) open when the connection is really down (e.g., the mobile device 110 is on an airplane example), however, may be detrimental by using up an address that is not otherwise occupied or being used.

To avoid allocation of an address when an address is not (or need not be) in use, an SMS message may be sent to a device 110 by the facilitating server 140 or an SMS Message Center (SMSC). The SMSC may be operating in conjunction with the facilitating server 140 in order to wake up the device 110. The SMSC may similarly be used by the facilitating server 140 to verify that the device 110 is awake during periods of low activity at a data store 150 or extended periods of time with no connectivity. Failed responses or wakeups to an SMS message may be logged as an unavailable connection and the address reassigned. Likewise, the device 110 may request a connection by sending its own SMS message.

The transport protocol application 130 may operate in conjunction with facilitating server 140 to allow for updating a status table or index and to otherwise allow for the commencing of data transactions with data stores 150. The transport protocol application 130 may inform the facilitating server 140 that the device 110 is available for interaction. This interaction availability may include exchange of credentials or other registration information.

Facilitating server 140 is a rendezvous point or transaction router for system 100. Various applications and connectors for phones, data services, data stores, and so forth may be implemented at facilitating server 140. Facilitating server 140 (or servers) is scalable.

Various data sources (collectively 150) are exemplified by a Google mail account 150a, Yahoo! mail account 150b, and Exchange server 150c, and which may be accessed in quasi-real-time by facilitating server 140 and/or optional proxy server 160 as described below. Data sources 150 are not limited to electronic-mail and are inclusive of any variety of data objects such as e-mail, calendar data, to do lists, and document attachments such as word processing documents, spreadsheets, presentation slide decks, photos, sound files, and motion picture files. Data objects may reside at or are otherwise accessible by data store 150. Data source 150 may also be representative of certain services utilizing data objects such as picture sharing services like Flickr.

Mobile device 110 may connect and ‘register’ with facilitating server 140. The mobile device 110 may be registered as a particular end point. The mobile device 110 may be broken down further with respect to particular data end points, for example, electronic mail. Mobile device 110 may be registered as one end point (e.g., a service channel) and individual mail boxes or data stores (e.g., Gmail, Exchange, Yahoo! Mail, person domain mail, etc.) related to a user of that mobile device 110 may be characterized as sub- or individual end points (e.g., specific service channels within that service channel). Each end point may be considered its own service operating over the same data connection between mobile device 110 and facilitating server 140.

More specifically, the mobile device 110 may be considered a master end-point. The mobile device 110, in turn, hosts various provisioned services (e.g., electronic mail). At the other ‘end’ of the system 100, and through facilitating server 140, is a particular data store 150 (e.g., a Gmail account) to which the facilitating server 140 is communicatively coupled. The facilitating server 140 maintains a record indicating that the particular data store 150 is associated with and accessible by the master end-point (mobile device 110), which is inclusive of a service or application corresponding to that data store (the aforementioned Gmail account). A similar record is maintained at facilitating server 140 for any other active service at mobile device 110.

In the process of registering with the facilitating server 140, the mobile device 110 provides a set of credentials. These credentials may be manually entered at the mobile device 110 or automatically provided as a part of a registration process. In the latter instance, the log-in information may be provided to the mobile device 110 by the user during an initial registration process (e.g., upon purchase and initialization of the phone or an application associated with the facilitating server 140). Credentials may include a user name, password, domain, identifying token, and/or any combination of the foregoing.

A separate mobile device with the proper credential information (e.g., a user name and password) might likewise interact with the facilitating server 140 and, in turn, access the same data store. This allows for the same data store to be accessible on a series of mobile devices. The facilitating server 140, in this regard, allows for mapping of credentials to data store access rather than any particular device.

Facilitating server 140 may host and execute certain connection applications to recognize certain events or data changes at data sources 750. Alternatively, data sources 750 may host and execute certain connection applications to provide notifications as to certain events or data changes at data sources 750. Those notifications, in turn, are received and processed by facilitating server 140. As appropriate, the facilitating server will provide subsequent notifications to mobile device 110 with respect to responding to a change at data source 750. Alternatively, facilitating server 140 may automatically take responsive action following notification or having identified the existence of a certain event or data change at data source 150. Automatic responsive action may be reflected by certain credential information provided by mobile device 110, which is then stored and mapped at facilitating server 140.

An ‘always on’ data connection is maintained (or attempted to be maintained) between mobile device 110 and facilitating server 140. If facilitating server 140 is unable to forward data from data source 750 due to the fact that the data connection between the facilitating server 140 and mobile device 110 is down (e.g., the user is on an airplane and has turned off their phone), the facilitating server 140 does not operate as a store and forward mechanism. Any data from a data source 150 that was being processed by the facilitating server 140 (or, in certain embodiments, at the data store 150 as is described below) for transport to the mobile device 110 is ‘flushed’ and removed from the facilitating server 140. The original data object or other data transaction thus remains in a pending state at the data source 150 and awaiting transport from the facilitating server 140 to mobile device 110.

In the event that a connection is down, a processing index at the facilitating server 140 will indicate that a data change or event has taken place at data source 150. The processing index will further indicate that processing of data related to that change or event remains unprocessed. Once the mobile device 110 is again available, that processing should re-commence with respect to the unprocessed data at data source 150. This index is maintained with respect to the mapped user credentials at the facilitating server 140 and any particular data store 150 mapped to the same.

The facilitating server 140 may also inform the connector application that the transmission of the data object to the mobile device 110 has failed (e.g., no ACK) and not to attempt further data transactions. This stay on further data transactions may remain in place until the facilitating server 140 confirms a ‘live’ connection. This status of the connection with respect to a particular set of credentials, which may be associated with a particular mobile device, may likewise be maintained in a processing index at the facilitating server 140.

Once the mobile device 110 is back online, the facilitating server 140 will attempt to re-establish a connection with the mobile device 110, which will result in an update to the processing index or other related status table. Once back on-line, the connection application will inform the data stores 150 that the associated end point is now available to receive data object transactions. Processing of any outstanding transactions as reflected in the index table may then take place whereby the facilitating server 140 and/or data source 150 begins re-processing the data object subject to a transaction.

In the event that a connection is down or unavailable, the facilitating server 140 will first attempt to open a data connection with the mobile device 110. The facilitating server 140 will undertake such an attempt rather than automatically and immediately flushing the data. If a pool of facilitating servers is utilized, this task may be ‘passed around’ in an attempt to find a facilitating server 140 that may successfully open the data connection. Passing around this task may also involve finding a facilitating server 140 that is properly balanced (i.e., not overloaded) with respect to any number of other facilitating servers in the system 100.

It may be most efficient to begin processing a data object from the data source 150 prior to or concurrent with opening a communication channel with the mobile device 110. In this manner, the processed data object may immediately be sent to the mobile device as soon as the channel is opened (i.e., the data has been processed and merely awaits an open channel for transmission). If processing of the data from data source 150 were delayed until the data channel were opened, that data channel would remain open but un-utilized while processing of the data from the data source 150 is initially undertaken (e.g., pulling the data object from the data source 150 to the facilitating server 140).

Opening a channel between facilitating server 140 and mobile device 110 may involve attempting to re-open an otherwise dormant but previously used TCP/IP channel. Alternatively, the facilitating server 140 may trigger the delivery of an SMS message to the device to initiate a fresh connection. In an embodiment not utilizing SMS, the mobile device 110 may utilize a polling application (not shown) that periodically polls the facilitating server 140. Polling may be subject to a predetermined schedule (e.g., every 10-15 seconds). The facilitating server 140 may wait for the next scheduled poll within a predetermined margin of error or delay. If a channel cannot be opened (the device 110 is actually unavailable), then the data is flushed as previously described and the index updated and/or maintained as is appropriate in light of the unprocessed data from data source 150.

For example, data source 150b (Yahoo! Mail) may be representative of an empty e-mail inbox. An e-mail message may then arrive at message inbox 150b. The appropriate connector application (of which there may be many, each for an appropriate data store 150) indicates to the facilitating server 140 that an event or data change has taken place.

The message—or other data object—may be compressed, truncated, and otherwise processed for delivery to the mobile device 110. This processing may take place at the facilitating server 140 after the data has been pulled from the data source 150. This compression and so forth may likewise take place at the data source 150. The processed data object then may be pushed to the facilitating server 140 or await a command from the facilitating server 140 pulling that data object to the facilitating server 140. A push of the processed data object to the mobile device 110 then takes place. Where certain processing of a data object takes place may depend on a particular arrangement between the host of the data source 150 and the facilitating server 140.

In some embodiments, an optional proxy server 160 may be used. The proxy server 160 may be used to communicate through an optional firewall 170. Certain data sources 150 or a corresponding firewall 170 may not allow facilitating server 140 to directly communicate with the data source 150. Certain data sources 150 may require an enterprise type server to handle certain transactions (e.g., proxy server 160). Facilitating server 140 and proxy server 160 may execute a number of similar functions and operate utilizing a similar software code base.

In such an embodiment where a proxy server 160 is required, the facilitating server 140 will process incoming transactions from mobile device end points, which are in turn passed to the proxy server 160, which allows for communication through the firewall 170 and may, in fact, be behind the firewall 170. In this regard, FIG. 1 is purely illustrative as the proxy server 160 may be located on either side of the firewall 170 or in a DMZ or other protected sub-network. The proxy server 160 manages interactions with a particular data source 150 including receipt of notifications of events and existence of data objects. The proxy server 160 will, in turn, hand processed transactions off to the facilitating server 140, which will then push those objects to a corresponding mobile device end-point. The proxy server 160, too, will receive requests initially received by the facilitating server 140 from a mobile device end-point for that request to be processed as is appropriate at a give data source 150. Connection applications may, in some embodiments, be distributed across multiple devices (e.g., the relay server 140, proxy server 160, and/or at or in conjunction with data store 150.

The terms “computer-readable storage medium” and “computer-readable storage media” as used herein refer to a medium or media that participates in providing instructions to a CPU for execution. Such media can take many forms including, but not limited to, non-volatile and volatile media. Non-volatile media include, for example, optical or magnetic disks, such as a fixed disk. Volatile media include dynamic memory, such as system RAM. Common forms of computer-readable storage media include, for example, a floppy disk, a flexible disk, a hard disk, magnetic tape, any other magnetic medium, a CD-ROM disk, digital video disk (DVD), any other optical medium, punch cards, paper tape, any other physical medium with patterns of marks or holes, a RAM, a PROM, an EPROM, a FLASHEPROM, any other memory chip or cartridge.

Transmission media may include coaxial cables, copper wire and fiber optics and various computer bus. Transmission media can also take the form of acoustic or light waves such as those generated during radio frequency (RF) and infrared (IR) data communications. Carrier wave or other media for transmission of information may be used.

The above description is illustrative and not restrictive. Many variations of the invention will become apparent to those of skill in the art upon review of this disclosure. The scope of the invention should, therefore, be determined not with reference to the above description, but instead should be determined with reference to the appended claims along with their full scope of equivalents.

While the present invention has been described in connection with a series of preferred embodiment, these descriptions are not intended to limit the scope of the invention to the particular forms set forth herein. To the contrary, the present descriptions are intended to cover such alternatives, modifications, and equivalents as may be included within the spirit and scope of the invention as defined by the appended claims and otherwise appreciated by one of ordinary skill in the art

Claims

1. A system for the transport of data objects, the system including:

a mobile device;

a facilitating server; and

a data source, wherein a data object at the data source is transported to the mobile device by way of the facilitating server.

2. The system of claim 1, wherein an SMS (short message service) message is received by an SMS agent at the mobile device, the receipt of the SMS message by the SMS agent at the mobile device causing the mobile device to initiate an Internet Protocol connection with the facilitating server.

3. The system of claim 2, wherein the SMS message is sent by an SMS messaging center (SMSC).

4. The system of claim 3, wherein the SMSC delivers the SMS message to the mobile device in response to a trigger initiated by the facilitating server.

5. The system of claim 1, wherein an SMS (short message service) message is received by an SMS agent at the mobile device to verify that a previously established Internet Protocol connection between the mobile device and the facilitating server remains open.

6. The system of claim 5, wherein the facilitating server is configured to designate the mobile device as unavailable when the SMS agent does not send a response indicating receipt of the SMS message.

7. The system of claim 6, wherein the designation of the mobile device by the facilitating server as being unavailable results in the Internet Protocol address being reassigned.

8. The system of claim 5, wherein the facilitating server is configured to designate the mobile device is available for interaction when the SMS agent sends a response indicating receipt of the SMS message.

9. The system of claim 8, wherein the mobile device is configured to provide credentials to the facilitating server to allow for an interaction with the data source.

10. The system of claim 9, wherein the data object at the data source is selected from the group consisting of electronic-mail, calendar data, a to do list, and document attachments.

11. The system of claim 9, wherein the facilitating server is further configured to designate the mobile device as a registered end-point upon receipt of mobile device credentials.

12. The system of claim 11, wherein the facilitating server is further configured to designate individual end-points within the registered end-point, wherein at least one of the designated individual end-points is associated with the data store.

13. The system of claim 11, wherein the facilitating server is further configured to commence processing the data object at the data source upon registration of the mobile device as an end-point, the registered end-point associated with the data source.

14. The system of claim 13, wherein the facilitating server is further configured to terminate processing of the data object when the Internet Protocol connection is terminated prior to transport of the data object from the facilitating server to the mobile device.

15. The system of claim 14, wherein the facilitating server is further configured to update a processing index indicating the status of one or more data objects at the data store.

16. The system of claim 15, wherein the facilitating server is further configured to recommence processing of the data object in accordance with the processing index upon an Internet Protocol connection being re-established with the mobile device.

17. The system of claim 16, wherein the Internet Protocol connection is re-established as a result of a polling operation.

18. The system of claim 16, wherein the Internet Protocol connection is re-established as a result of an SMS exchange.

19. The system of claim 1, further comprising a proxy server configured to transport the data object to the facilitating server from the data source, the proxy server further configured to interact with the data source and the facilitating server through a firewall.