US20080133712A1 - Asynchronous real-time retrieval of data - Google Patents

Abstract

A data retrieval system includes a gateway server and an access client. The gateway server is communicatively connected to the access client through a network. The gateway server provides a presentation service (PS) and a real-time service (RTS), which cooperate with the access client to retrieve data from a data store and then provide the retrieved data to a user's remote communication device. More particularly, when a user wishes to retrieve data from the data store or to send data to the data store, the user establishes a communication connection between his or her remote communication device and the gateway server, and then requests the desired data from the gateway server. In response, the gateway server sends a command to the access client, instructing it to retrieve the requested data. The access client retrieves the requested data from the data store, and returns the retrieved data to the gateway server. The gateway server then relays the requested information back to the user's remote communication device.

Description

• The present application is a continuation of U.S. application Ser. No. 10/770,841, filed Feb. 2, 2004, and in turn claims priority to U.S. Application Ser. No. 60/444,213, filed Jan. 31, 2003, entitled “Asynchronous Real-Time Retrieval Of Data,” the entire contents of each of which are hereby incorporated herein by reference.
BACKGROUND OF THE INVENTION
• 1. Field of the Invention
• The present invention relates to the asynchronous real-time retrieval of data. Various aspects of the present invention are particularly applicable to the asynchronous real-time retrieval of data from a corporate database to a remote device, such as a wireless telephone or personal digital assistant.
• 2. Description of the Related Art
• Recently, digital information has become more and more important to people of all walks of life. As the importance of digital information has increased, the need for convenient remote access to a variety of types of digital information has increased as well. For example, traveling businessmen may desire continual access to information contained in electronic spreadsheets, attorneys may desire access to word processing documents from a client's location, and students may want to send or retrieve electronic mail while in school.
• In order to address this need, many communication service providers allow their customers to access remote digital information through a communication network. For example, a wireless telephone service provider may allow its customers to use their wireless telephones or other communication devices to send and receive retrieve electronic mail, retrieve image information from a network, obtain contact information from a centralized database, or the like. Similarly, some companies have established remote high-speed Internet connections, both wired and wireless, at public locations such as restaurants, hotels, and airports, which can be accessed by a customer's computer.
• While communication service providers have created an infrastructure that potentially allows their customers remote access to digital information, many practical issues still prevent this infrastructure from being fully utilized. For example, some customers seek to access digital information stored behind a barrier, such as digital information stored in their employer's database and protected by a firewall. With this arrangement, if the employer's network did not support an access tool allowing external connections through the firewall then a customer would be prevented from accessing the desired digital information through the communication service provider's network. These access tools include, for example, the use of a virtual private network (VPN) or similar techniques for enabling secure and authenticated connections from devices not directly connected to the employer's network. Moreover, even if the employer's network supported such a tool, the customer's communication device could still not access the data if the user's device itself was not configured to support that tool.
• In other situations, a customer may attempt to use an unsuitable communication device to retrieve data. For example, a user may attempt to employ a personal digital assistant or wireless telephone with a relatively simple browser to retrieve a Web page with a large amount of image or audio data. Before the large amount of data can be fully retrieved, the personal digital assistant or wireless telephone may “time out” and sever the connection. Alternately or additionally, the user may seek to download more data than the personal digital assistant or wireless telephone may store.
SUMMARY OF THE INVENTION
• Advantageously, various examples of the invention allow a user to more conveniently send data to and retrieve data from a remote data store using a remote communication device. With different aspects of the invention, a data retrieval system includes an in-box (IB) server, referred to hereafter more generally as a “gateway server,” and a desktop access client (DAC), referred to hereafter more generally simply as an access client. The gateway server is communicatively connected to the access client through a network. The gateway server provides a presentation service (PS) and a real-time service (RTS), which cooperate with the access client to retrieve data from a data store and then provide the retrieved data to a user's remote communication device using a presentation protocol appropriate to the device's capabilities.
• With various implementations of the invention, the access client will create a connection to the gateway server. When the user wishes to retrieve data from the data store or to send data to the data store, the user establishes a communication connection between his or her remote communication device and the gateway server, and then requests the desired data from the gateway server. In response, the gateway server sends a command to the access client, instructing it to retrieve the requested data. The access client retrieves the requested data from the data store, and returns the retrieved data to the gateway server. The gateway server then relays the requested information back to the user's remote communication device through the presentation server using a presentation protocol appropriate to the device's capabilities.
BRIEF DESCRIPTION OF THE DRAWINGS
• FIG. 1 illustrates a network environment including a system for asynchronous retrieval of data according to various embodiments of the invention.
• FIG. 2 illustrates an example of a computing system that may be used to implement various embodiments of the invention.
• FIGS. 3A-3D illustrate a flowchart showing a method for asynchronously retrieving data according to various embodiments of the invention.
• FIGS. 4A-4E illustrate a flowchart showing a method of retrieving data from a data store according to various embodiments of the invention.
• FIG. 5 illustrates a system for asynchronous retrieval of data employing multiple gateway servers according to various embodiments of the invention.
DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS
• FIG. 1 shows a schematic block diagram of adata retrieval system100 according to various embodiments of the invention. Theretrieval system100 allows for the retrieval of data, such as data from a corporate data store, to a remote device. As seen in this figure, thedata retrieval system100 includes at least one gateway (IB)server101 and an access client (DAC)103. In the illustrated example, theaccess client103 is hosted by a user'scomputer105. Thecomputer105 is located in, for example, acorporate network environment107 that includes thedata store109 from which data is to be retrieved. Thedata store109 may be any type of data store, such as a database that organizes data, a server device that provides services to one or more client devices or a combination of the two. Thedata store109 may be, for example, a Lotus Domino server or a Microsoft Exchange server that manages a variety of data including electronic mail messages, calendar information, contact information and the like. Thecorporate network environment107 may also include afirewall111 or other barrier for preventing unwanted access to thecorporate network environment107. Thedata store109 may also be a publicly available data store, such as, for example, a Yahoo email server or the like. Still further, the data store may be a generic IMAP or POP3 mail store, or even a store employing a desired file system, such as the NTFS file system.
• As shown in this figure, thegateway server101 is communicatively connected to theaccess client103 through anetwork113, such as a wide-area network. Thenetwork113 may be a publicly accessible network, such as the Internet. Alternately, the network may be a private network (often referred to as an intranet), or a combination of public and private networks. Thegateway server101 provides a presentation service (PS)115 and a real-time service (RTS)117, each of which will be explained in detail below. Thepresentation service115 and the real-time service117 of thegateway server101 cooperate with theaccess client103 to retrieve data from thedata store109 and then provide the retrieved data to the user'sremote communication device119.
• More particularly, theaccess client103 creates a connection121 (which may be, for example, a persistent connection) to thegateway server101 through thefirewall111. Theaccess client103 then lies dormant until it receives commands from thegateway server101 to retrieve data from thegateway server101 or to provide data to thegateway server101. When the user wishes to retrieve data from thedata store109 to the user's remote communication device119 (or, alternately, to send data from the user'sremote communication device119 to the data store109), the user establishes acommunication connection123 between theremote communication device119 with thegateway server101. Through the user'sremote communication device119, the user then requests the desired data from thegateway server101. In response, thegateway server101 sends a command over theconnection121 to theaccess client103, instructing theaccess client103 to retrieve the requested data. In response, theaccess client103 retrieves the requested data from thedata store109, and returns the retrieved data to thegateway server101. Thegateway server101 then relays the requested information back to the user'sremote communication device119. This process, together with the components of thesystem100, will be discussed in more detail below.
Operating Environment
• As will be appreciated by those of ordinary skill in the art, thegateway server101 may be implemented using one or more computing devices, such as a programmable computer that may be programmed to send, retrieve and store the data files that make up electronic messages. This type of computer can be embodied by, for example, an electronic mail account server.FIG. 2 shows one example of such aprogrammable computer system201 capable of retrieving and caching electronic mail data files from one or more outside electronic mail accounts. Thecomputer system201 includes aprocessing unit203, asystem memory205, and asystem bus207 that couples various system components, including thesystem memory105, to theprocessing unit203. Thesystem memory205 may include a read-only memory (ROM)209 and a random access memory (RAM)211.
• A basic input/output system213 (BIOS), containing the routines that help to transfer information between elements within thecomputer system201, such as during startup, may be stored in the read-only memory (ROM)209. If thecomputer system201 is embodied by a personal computer, it may further include ahard disk drive215 for reading from and writing to a hard disk (not shown), amagnetic disk drive217 for reading from or writing to a removable magnetic disk (not shown), anoptical disk drive219 for reading from or writing to a removable optical disk (not shown) such as a CD-ROM or other optical media, or amemory card221, such as a flash memory card.
• A number of program modules may be stored on theROM209, thehard disk drive215, themagnetic disk drive217, and theoptical disk drive219. A user may enter commands and information into thecomputer system201 through aninput device223, such as a keyboard, a pointing device, a touch screen, a microphone, a joystick or any other suitable interface device. Of course, thecomputer system201 may employ a variety ofdifferent input devices223, as is known in the art. Anoutput device225, such as a monitor or other type of display device, is also included to convey information from thecomputer system201 to the user. As will be appreciated by those of ordinary skill in the art, a variety ofoutput devices225, such as speakers and printers, may alternately or additionally be included in thecomputer system201.
• In order to access electronic mail accounts, thecomputer system201 preferably is capable of operating in a networked environment using logical connections to one or more remote computers, such as the remote computer227. Thecomputer system201 may be connectable to the remote computer227 through a local area network (LAN)229 or a wide area network (WAN), such as the Internet. When used in a networking environment, thecomputer system201 may be connected to the network through aninterface228, such as a wireless transceiver, a modem, an Ethernet connection, or any other suitable interface. While theinterface228 is illustrated as an internal interface inFIG. 2, it may alternately be an external interface as is well known in the art. Of course, it will be appreciated that the network connections described above are exemplary, and other means of establishing a communications link with other computers may be used.
Use of the Presentation Service and the Real-Time Service
• With various embodiments of the invention, the data retrieved from thedata store109 may be requested and received over a wide area network, such as the -Internet. This type of communication medium is relatively unpredictable, however, and the existing level of traffic over the network may affect the speed at which the real-time service117 receives requested data. Further, a request for data from the user'sremote communication device119 will not typically specify the size of the requested data. For example, a user may employ theremote communication device119 to request his or her most recent email message from thedata store109 without knowing the size of the message. Accordingly, when thepresentation service115 receives a request for data from the user'sremote communication device119, thepresentation service115 typically cannot ascertain when it will receive the requested data from theaccess client103.
• This uncertainty presents a problem in that thepresentation service115 cannot determine in advance how long to maintain theconnection123 to the user'sremote communication device119. Typically, theremote communication device119 will maintain an idle connection for only a preset time period before severing the connection. Thus, in some situations, the time between when thepresentation service115 requests the data from the real-time service117 and when thepresentation service115 receives the requested data in reply may be longer than the amount of time that the user'sremote communication device119 will wait for a reply from thepresentation service115 before severing theconnection123.
• In addition, the communications network supporting the communication device also may implement timeout procedures that are configured separately and independently from either theremote communications device119 or thegateway server101. These procedures may be used by communications service providers to prevent idle connections from consuming network resources that might otherwise be allocated to active connections. Thus, the communications network itself may timeout and sever theconnection123 to thegateway server101 before a reply from thepresentation service115 has been received.
• Moreover, different types ofremote communication devices119 will have different waiting periods before severing an idle connection (that is, a connection where data is not being exchanged). More particularly, some types ofremote communication devices119 may employ a relatively sophisticated communication software application that will maintain an idle connection for several minutes. For example, if theremote communication device119 is a laptop personal computer, it may use a version of the Microsoft Internet Explorer browser to communicate with thepresentation service115. This type of communication software application is typically configured to receive rich data with graphics and colors, and thus will wait a relatively long time for a reply from thepresentation service115 before “timing out” and severing theconnection123.
• On the other hand, a less sophisticatedremote communication device119 may employ a communication software application intended to receive only very simple data and that will only briefly maintain an idle connection. For example, a wireless telephone may communicate with thepresentation service115 using a streamlined browser that receives only text data and is designed to be navigated with a keypad. This type of simply communication software application will typically wait only a relatively short period of time for a reply from thepresentation service115 before timing out and severing theconnection123.
• To address this discrepancy between different types ofremote communication devices119 and their different supporting communications networks, thegateway server101 according to various embodiments of the invention may employ both thepresentation service115 and the real-time service117. More particularly, with various embodiments of the invention, the real-time service117 maintains theconnection121, which may be a persistent connection, to theaccess client103. Thepresentation service115 then manages theconnection123 with variousremote communication devices119 through various communications networks. Thus, thepresentation service115 and the real-time service117 cooperate together to provide asynchronous retrieval of data from thedata store109 to the user'sremote communication device119. That is, the timing of communications between the real-time service117 and the data store109 (through the access client103) is independent of the timing of communications between thepresentation service115 and a user'sremote communication device119.
• According to various embodiments of the invention, theconnection121, theconnection123, or both may be encrypted. For example, theconnection121, theconnection123, or both may be encrypted using the Secure Sockets Layer (SSL) protocol. The encryption may be on a connection-by-connection basis. Thus, theconnection121 may be encrypted using one set of encryption information shared between theaccess client103 and the real-time service117, while theconnection123 may be encrypted using another set of encryption information shared between the user'sremote communication device119 and thepresentation service115. Alternately, with various embodiments of the invention, theconnections121 and123 may be commonly encrypted “end-to-end,” using encryption information shared between the user'sremove communication device119 and theaccess client103.
Asynchronous Retrieval of Data
• Referring now toFIGS. 3A-3D, these figures illustrate a flowchart for one process that may occur according to various embodiments of the invention when the user desires to send data to or retrieve data from thedata store109. As shown inFIG. 3A, in order to employ thesystem100, a user first installs theaccess client103 on a computer that has access to the data store109 (that is, on the computer105) in step301. For example, if thedata store109 is a Microsoft Exchange server that manages the user's electronic mail messages, the user will install theaccess client103 on a computer that has access to the user's electronic mail account on thedata store109. As part of the installation process for some embodiments of the invention, the user may submit authentication information. This authentication information then later can be used to authenticate the user's identity when the user attempts to retrieve data to or send data from the user'sremote communication device119.
• In many situations, the user will employ thesystem100 to send or receive electronic mail messages or other data from adata store109 maintained by the user's employer. Accordingly, thedata store109 is illustrated inFIG. 1 as being within acorporate network environment107, which may be behind thefirewall111, as previously noted. In these situations, thecomputer105 may be the user's personal work computer that is also within thecorporate network environment107 and behind thefirewall111, and thus has easy access to thedata store109. It should be appreciated, however, that various embodiments of the invention may be employed to retrieve data from or send data to adata store109 located within any computing environment. Also, any computing device having the desired access to thedata store109 may serve as thecomputer105. Further, as will be explained in detail below, a user may employmultiple access clients103 ondifferent computers105 to retrieve data from or send data to thedata store109, and multiple users may employ a sharedaccess client103 on asingle computer105 to retrieve data from or send data to thedata store109.
• It should be appreciated that, while theaccess client103 is described in the illustrated embodiment as a client hosted on asingle computer105, various alternate embodiments of the invention may employ any configuration for theaccess client103. For example, theaccess client103 may itself be implemented by a “server” computer that servers other computers in a network. Thus, theaccess client103 may provide access to thedata store109 for more than one user. Further, theaccess client103 may provide centralized management and administration tools that enable a system administrator (e.g., a system administrator for the data store109) to manage and control utilization of theaccess client109 by individual users by e.g., selecting them from a directory or company address list. Moreover, theaccess client103 may thus be implemented on a server that performs other functions, which may or may not be related to the operation of theaccess client103. For example, theaccess client103 may be implemented on a public email server, such as a Yahoo or Hotmail email server, or on a private email server. Still further, with different embodiments of the invention, the operation of theaccess client103 may be distributed among a plurality ofcomputers105.
• Returning now toFIG. 3A, once theaccess client103 has been installed on thecomputer105 in step301, theaccess client103 establishes a secure communication connection to thegateway server101 instep303. More particularly, theaccess client103 establishes asecure connection121 with the real-time service117 hosted by thegateway server101. An entry for the connection, referred to as a real-time session, also is created in thedirectory127. Thedirectory127 may be, for example, an Oracle database or other suitable database, or a Novell directory or other suitable directory. The entry for theconnection121 identifies both the user and thegateway server101 hosting the real-time service117 to which theconnection121 is made.
• According to various embodiments of the invention, theconnection121 may be a persistent connection that is maintained as long as both theaccess client103 and the real-time service117 are operating to provide service to a user. With still other embodiments of the invention, however, theconnection121 may be established on an as-instructed or periodic basis. Thus, various embodiments of the invention may employ heuristics to determine when theaccess client103 establishes theconnection121 with the real-time service117. These heuristics may determine, for example, that theaccess client103 will connect every minute (or some other time period) if it services a user (or users) who have not frequently retrieved data from thedata store109. These heuristics may also determine that theaccess client103 will persistently maintainconnection121 if it services a user (or users) who have frequently retrieved data from thedata store109. Still further, various embodiments of the invention may employ these heuristics only under certain conditions, such as when network traffic for the network carrying theconnection121 increases above a threshold level, or when the real-time service117 reaches some threshold ofsimultaneous connections121 withmultiple access clients103.
• In order to subsequently retrieve data from thedata store109 to the user's remote communication device119 (or to send data from the user'sremote communication device119 to the data store109), the user connects to thegateway server101 through the user'sremote communication device119 in step305. More particularly, the user establishes thecommunication connection123 from the user'sremote communication device119 to thepresentation service115 hosted by thegateway server101.
• As will be appreciated by those of ordinary skill in the art, in addition to personally initiating a connection with thegateway server101 and requesting data from thedata store109, one or more software applications running on the user'sremote communication device119 may also initiate theconnection123 to thepresentation service115 hosted bygateway server101 on the user's behalf. Depending upon the purpose and needs of the particular software application, the software application can initiate theconnection123 on a periodic, scheduled, or event-driven basis and make one or more data requests asking to retrieve data from or sending data to thedata store109. This approach relieves the user of the need to pro-actively initiate all connections and data requests or transfers and greatly improves the overall user experience.
• In the embodiment illustrated inFIG. 1, the user'sremote communication device119 is a wireless communication device that exchanges data or voice information over a wide-area wirelesstelephone communication network125. For example, the user'sremote communication device119 may be a wireless telephone, or a personal digital assistant (PDA) or portable computer equipped with a wireless communication unit, such as a PCMCIA card like the Sierra Wireless AirCard®. With still other embodiments of the invention, however, the user'sremote communication device119 may be connected to thegateway server101 through any suitable connection, including a public communication network such as the Internet. For example, the user'sremote communication device119 may alternately be connected to thegateway server101 using a wired connection, such as a conventional “dial-up” or DSL telephone connection, a high-speed broadband connection provided by a cable television service provider, or even an optical connection. Further, the user'sremote communication device119 may be connected to thegateway server101 through another communication device, such as a public Internet kiosk. Thus, rather than connecting to thegateway server101 over thewireless network125, the user'sremote communication device119 may connect to thegateway server101 over any suitable medium, including a wireless communication network, a wired communication network or a composite wired and wireless communication network.
• Similarly, theconnection121 between theaccess client103 and the real-time service117 can be made over any suitable medium. In the illustrated embodiment, theconnection121 is established over a public, wide-area communication network, such as the Internet. With alternate embodiments of the invention, however, theconnection121 may be the established over, for example, a private communication network, such as a private wireless telephone communication network. Thus, theconnection121 also may be established over a wireless communication network, a wired communication network, or a composite wired/wireless communication network.
• As will be appreciated by those of ordinary skill in the art, a variety of communication techniques and protocols have been developed for exchanging data between devices. For example, communications over both high and low bandwidth connections may be made using well-known extensible markup language protocols, such as the Hypertext Markup Language (HTML) protocol, the Extensible Markup Language (XML) or the Synchronization Markup Language (SyncML) or other messaging-centric protocols such as the Post Office Protocol (POP) or the Internet Message Access Protocol (IMAP). Similarly, communications over lower-bandwidth wireless connections (such as wireless telephone connections) may be made using the well-known Wireless Markup Language (WML) protocol. Any suitable protocol, including any of these known protocols, may be used to exchange data between theremote communication device119 and thepresentation service115, and between theaccess client103 and the real-time service117. Thus, communications over theconnection121 between theaccess client103 and thegateway server101 may be made using HTML or XML pages, while communications over theconnection123 between the user'sremote communication device119 and thegateway server101 may be made using HTML, XML, SyncML, or WML pages, or other protocols including, but not limited to, IMAP and POP3. Because the equipment and procedures for communicating data between devices using these protocols are well-known in the art, they will not be described in further detail here.
• Returning now toFIG. 3A, the user authenticates his or her identity for thepresentation service115 in step307. For example, thepresentation service115 may transmit one or more authentication inquiries to the user'sremote communication device119. These inquiries, which may be contained on a single markup language page, may ask the user for a username and password. In response, the user transmits the requested authentication information back to thepresentation service115. Of course, the user'sremote communication device119 may alternately or additionally provide one or more software applications for managing and presenting data, which includes user interface elements for collecting, storing, and submitting authentication information to thepresentation service115 without requiring the user to manually reenter the authentication information for each session with thepresentation service115.
• When the user wishes to retrieve data from thedata store109, the user sends a request for the desired data over theconnection123 to thepresentation service115 instep309. For example, the user may request the header information for the most recent 10 electronic mail messages in the user's electronic mail account on thedata store109. This request can be made using any suitable technique. For example, once the user'sremote communication device119 has established theconnection123 with thepresentation service115, thepresentation service115 may transmit WML pages with prompts to the user'sremote communication device119. These pages may, for example, contain a list of possible information that can be requested by the user. After the user selects the prompts corresponding to the desired information, the selected prompts are transmitted back to thepresentation service115 as a request for the desired data. Of course, still other techniques for retrieved desired information from thedata store109 may be employed, including techniques where data is retrieved automatically by an application on theremote communication device119 without requiring the user's intervention, as previously noted.
• Instep311, thepresentation service115 establishes a presentation session for theconnection123 with the user's •remote communication device119. Thepresentation service115 thus associates all subsequent communications related to the request for the desired data with the user'sremote communication device119. For example, the presentation session may be an entry in memory, such as a data table, associating the user's username and password with a presentation session value. The presentation session may also identify a location in memory,cache1151, at which the desired data will be stored upon retrieval, and a flag indicating if the desired data as been stored to thecache1151. The use of the presentation session to retrieve data from thedata store109 to theremote communication device119 will be discussed in further detail below.
• Instep313, thepresentation service115 checks to see if the desired information has already been cached in thecache1151. As will be discussed in detail below, if thepresentation service115 determines that it already has cached the desired information then, instep315, thepresentation service115 immediately retrieves the desired information from thecache1151 and returns the desired information to the user'sremote communication device119. When the request for the desired data is initially made to thepresentation service115, however, the desired data probably will not have already been cached by thepresentation service115.
• Accordingly, when the desired data is not currently in thecache1151, a request for the desired data is sent from thepresentation service115 to the real-time service117 instep317. In response, the real-time service117 issues a command over theconnection121 to theaccess client103 instep319, instructing theaccess client103 to retrieve the desired information from thedata store109. Upon receiving the command from the real-time service117, theaccess client103 retrieves the desired data from thedata store109 instep321. Then, instep323, theaccess client103 returns the retrieved data to the real-time service117, which in turn provides the retrieved data to thepresentation service115 instep325. Thepresentation service115 then stores the retrieved data in thecache1151 instep327.
• Instep329, thepresentation service115 determines if the request for the data is still pending from the user'sremote communication device119. That is, thepresentation service115 determines if the user'sremote communication device119 is still maintaining theconnection123 in wait for the desired data. If the request is still pending, then the retrieved data is provided to the user'sremote communication device119 instep331.
• Thus, if the desired data can be retrieved by thegateway server101 from thedata store109 within the idle time of the user'sremote communication device119, then the desired data can be immediately provided to the user. In many situations, however, thegateway server101 will not be able to retrieve the desired data before the idle time for the user'sremote communication device119 expires and the user'sremote communication device119 terminates theconnection123. As will be discussed in more detail below, thepresentation service115 addresses these situations by responding to the user'sremote communication device119 before its idle time expires.
• More particularly, if the desired data is not retrieved before the user'sremote communication device119 terminates theconnection123, then thepresentation service115 will send a message to the user'sremote communication device119 instructing the user (or the user's remote communication device119) to resubmit the request for the desired data. This response may be repeated until the desired data is retrieved from thedata store109 and stored in thecache1151. By using the presentations session to associate these subsequent requests with the initial request for the desired data, the desired data can be transmitted to the user'sremote communication device119 once it has been stored in thecache1151. That is, the desired data stored in thecache1151 can be transmitted to the user'sremote communication device119 in response to an existing request for the data (i.e., over the existing connection123) or when the request is resubmitted to thepresentation service115. Accordingly, desired data can be retrieved from thedata store109 on a real-time basis, regardless of the disparity between the idle time of the user'sremote communication device119 and the time required to obtain the desired data from thedata store109.
Communication with the Remote Communication Device
• As previously noted, thepresentation service115 manages communications with the user'sremote communication device119, to ensure that the user'sremote communication device119 does not time out without receiving a reply to its request for data.FIGS. 4A-4E illustrate a flowchart showing one method that may be employed by thepresentation service115 according to various embodiments of the invention to reliably communicate with the user'sremote communication device119.
• As previously noted, instep309 of the flowchart shown inFIGS. 3A-3D, the user sends the presentation service115 a request for desired data from thedata store109. Instep401, thepresentation service115 determines if the request is a new request for the desired data, or if it is a resubmission of an earlier request for the desired data. If the request is a new request for the desired data, thepresentation service115 creates a presentation session instep403, and then passes the request along to the real-time service117 to retrieve the desired data from thedata store109.
• According to various embodiments of the invention, the process of creating the presentation session instep403 includes designating thecache1151 to be used for caching information relating to the request for the desired data from the user'sremote communication device119. As will be appreciated by those of ordinary skill, thepresentation service115 may employ any memory resource available to thegateway server101. Because the requested data will be stored in thecache1151 for immediate transmission to the user'sremote communication device119, however, a memory resource that can be quickly accessed to provide the requested data to the user'sremote communication device119 may conveniently be used for thecache1151. With various embodiments of the invention, thecache1151 may be encrypted or unencrypted.
• The process of creating the presentation session instep401 also includes designating identification information identifying the presentation session. This identification information is then provided to the real-time service117 with the request for the desired information. When the real-time service117 then returns the retrieved data retrieved from thedata store109, it also provides the corresponding presentation session identification information. Using this returned presentation session identification information, thepresentation service115 stores the retrieved data in thecache1151 associated with the presentation session. It should be appreciated that any suitable identification information may be used to identify the presentation session for the data request. For example, the identification information may be a specific code or password. Alternately, with some embodiments of the invention, the identification information may be the memory address of the location of thecache1151 for the presentation session.
• Instep405, thepresentation service115 also initiates atimer1153 for the user'sremote communication device119 corresponding to the presentation session. As will be discussed in more detail below, thetimer1153 will be used to predict when the user'sremote communication device119 will time out and sever theconnection123 to thepresentation service115. Further, instep407, thepresentation service115 determines device type information for thedevice119 that has requested the data. That is, thepresentation service115 determines information about the type of device making the request that will allow thepresentation service115 to identify operational characteristics for the user'sremote communication device119.
• With some implementations of the invention, thepresentation service115 may determine only a general category into which the user'sremote communication device119 can be classified. For example, with some embodiments of the invention, thepresentation service115 may determine whether the user'sremote communication device119 is employing WML, HTML, SyncML, IMAP or POP or the like to communicate. If the user'sremote communication device119 is using HTML, thepresentation service115 then determines if the user'sremote communication device119 is a personal computer or a personal digital assistant (PDA). Thus, if the user is employing, for example, a Toshiba PocketPC® PDA device to access thepresentation service115, thepresentation service115 may categorize that device as a personal digital assistant HTML device.
• Still other embodiments of the invention, however, may determine different or more detailed information regarding the user'sremote communication device119. For example, with some embodiments of the invention, thepresentation service115 may determine the specific browser (or other communication software) being used by the user'sremote communication device119 to communicate with thepresentation service115, particular settings for that communication software, or any other information that might be useful to determine how the user'sremote communication device119 will communicate with thepresentation service115.
• With some embodiments of the invention, this device type information may conventionally be provided by the user'sremote communication device119 when it initiates theconnection123. For example, if the user'sremote communication device119 sends a request for data using an HTML page, that page may conventionally include information that thepresentation service115 can use to determine the type of browser that the user'sremote communication device119 is employing to communicate with thepresentation service115. Alternate embodiments of the invention, however, may employ alternate techniques to provide the device type information to thepresentation service115.
• For example, with some implementations of the invention, the user may specify the device type information for the user'sremote communication device119 when the user installs theaccess client103 on thecomputer105. Alternately or additionally, the user may specify the device type information using a survey or questionnaire page (such as a HTML page) provided to theaccess client103 or to the user'sremote communication device119. Once the user has specified the device type information with the questionnaire page, thegateway server101 may generate and place a cookie on the user'sremote communication device119. When the user then employs the user'sremote communication device119 to request data from thepresentation service115 thereafter, thepresentation service115 can solicit the device type information from the cookie on the user'sremote communication device119 in reply. Of course, still other techniques for determining the device type information will be apparent to those of ordinary skill in the art, and may be used with various embodiments of the invention.
• Once thepresentation service115 has determined the device type information for the user'sremote communication device119 instep407, thepresentation service115 employs that device type information to determine the communication characteristics of the user'sremote communication device119 instep409. Among various communication characteristics that may be identified by thepresentation service115, thepresentation service115 determines how long the user'sremote communication device119 will wait for a reply to the request from thepresentation service115 before severing theconnection123. That is, thepresentation service115 uses the device type information for the user'sremote communication device119 to determine the idle time of the user'sremote communication device119.
• For example, as previously noted, with the illustrated embodiment of the invention thepresentation service115 may determine if the user'sremote communication device119 is using WML or HTML to communicate and, if the user'sremote communication device119 is using HTML, whether the user'sremote communication device119 is a personal computer or a personal digital assistant. If thepresentation service115 determines that the user'sremote communication device119 is using WML to communicate, then theremote device119 is probably a wireless telephone using a simple browser software application. Accordingly, thepresentation service115 may determine that the user'sremote communication device119 will only wait a small period of time (for example, 5 seconds) after submitting the request to receive a reply from thepresentation service115 before severing theconnection123. On the other hand, if the user'sremote communication device119 is a personal computer employing HTML to communicate, then the user'sremote communication device119 is probably using a sophisticated browser software application, such as Microsoft Internet Explorer. Thepresentation service115 may therefore determine that the user'sremote communication device119 will wait for a relatively long period of time (for example, two minutes) to receive a reply from thepresentation service115 before severing the connection.
• Various embodiments of the invention may employ different types of device type information to determine the device communication characteristics, as explained in detail above. Accordingly, different embodiments of the invention may also determine different types of device communication characteristics from the device type information. For example, if thepresentation service115 employs device type information that only identifies the user'sremote communication device119 as one of three broad categories of devices (e.g., a WML device, an HTML personal digital assistant device or an HTML personal computer device), then thepresentation service115 may correspondingly identify only one of three broad types of device communication characteristics. For example, it may determine that all WML devices will wait only 5 seconds for a reply, all HTML personal digital assistant devices will wait only 90 seconds for a reply, and that all HTML personal computer devices will wait only 2 minutes for a reply, regardless of the specific configuration of any particular device.
• If, however, thepresentation service115 employs more detailed device type information, such as the particular browser being used by theremote communication device119, then thepresentation service115 may correspondingly employ more specific device communication characteristics information. For example, thepresentation service115 may determine that adevice119 using the Microsoft Internet Explorer, Version 6.0, will wait only three minutes for a reply from thepresentation service115 before severing theconnection123, while a device using a Sony-Ericsson browser for wireless GSM telephones will wait only 45 seconds for a reply from thepresentation service115 before severing theconnection123. As will be apparent to those of ordinary skill in the art, the level of detail of the device characteristics information may depend upon the level of detail of the device type information obtained by thepresentation service115.
• With various embodiments of the invention, thepresentation service115 may obtain the device characteristics information from, for example, a look-up table such as the device characteristics table1155. The table1155 may be populated using any conventional technique. For example, the device characteristics in the table1155 may be populated when the server is initialized. Alternately, thegateway server101 may populate the table1155 by seeking the appropriate device characteristics information from a remote source, such as, for example, the Internet, for each new type ofremote communication device119 that is employed by a user.
• In the illustrated embodiment, the table1155 is a component of thepresentation service115, in order to allow thepresentation service115 to more quickly retrieve the device characteristics information. Alternate embodiments of the invention, however, may have the table1155 located in the real-time service117, an independent database directly or indirectly accessible by thepresentation service115, or even in theaccess client103. Still other embodiments of the invention may employ other techniques to determine the device characteristics information. For example, if the user'sremote communication device119 provides a cookie to thepresentation service115 with the device type information, as discussed above, this cookie may also include the device characteristics information for thedevice119. Further, with various embodiments of the invention, the use of the device information to determine the device characteristics information may be omitted entirely. Instead, for example, with these embodiments of the invention the user'sremote communication device119 may provide the appropriate device characteristics information directly to thepresentation service115 when making a request for data.
• It should also be appreciated that, in addition to the idle time for the user'sremote communication device119, the device characteristics information may include other data as desired. For example, the device characteristics information may identify a particular data format employed by the user'sremote communication device119, a transmission speed for transmitting the retrieved data to the user'sremote communication device119, or other useful information corresponding to the device type of the user'sremote communication device119.
• Returning now toFIG. 4B, when thepresentation service115 has determined the device characteristics for the user'sremote communication device119, thepresentation service115 sets a threshold for thetimer1153 instep411 using the determined device characteristic information for the user'sremote communication device119. More particularly, thepresentation service115 sets a value for thetimer1153 at which thepresentation service115 will generate and send a reply to the request for data from the user'sremote communication device119. The threshold value is selected to allow thepresentation service115 time to reply to the user's remote communication device's request for data before the user'sremote communication device119 times out and severs theconnection123.
• As will be appreciated by those of ordinary skill in the art, the specific threshold set for atimer115 can be predicated upon a variety of factors, including the amount of time necessary to prepare and send a suitable reply. Thus, if adevice119 is using a sophisticated browser that requires a complex reply (including, for example, graphics), then the threshold may be set to allow more time for a reply than when the user'sremote communication device119 is using a simple browser that requires only a text reply.
• For example, if thepresentation service115 has determined that the user'sremote communication device119 is using a simple browser and will wait only 5 seconds for a reply before severing theconnection123, then thepresentation service115 may set the threshold for thetimer1153 to be 3 seconds, allowing 2 seconds to generate and send the reply message. If, however, thepresentation service115 has determined that the user'sremote communication device119 is using a sophisticated browser and will wait two minutes for a reply before severing theconnection123, then thepresentation service115 may set the threshold for thetimer1153 to be 1 minute, 50 seconds, thereby allowing more time (i.e., 10 seconds) to prepare and send a more complex reply before the user'sremote communication device119 times out and severs theconnection123.
• With various embodiments of the invention, still other factors can be taken into account when determining the threshold value for thetime1153, including, for example, current traffic conditions for thenetwork125 and the degree of reliability desired for theconnection123. Alternately, a single threshold value can be designated for each category of device type. Thus, for example, allcommunication devices119 using WML may have a first threshold value for thetimer1153, allcommunication devices119 that are HTML-using personal digital assistant devices can have a second threshold value for thetimer1153, and allcommunication devices119 that are HTML-using personal computers can have a third threshold value for thetimer1153.
• Of course, with still other embodiments of the invention, a single time period can be used to determine the timer threshold value for all types ofcommunication devices119, regardless of their individual device communication characteristics. For example, the timer threshold value can be set for all types of devices so that thepresentation service115 employs only a single time period for all types of devices. With these embodiments of the invention, the determination of both the device type information and the corresponding device characteristics information may be omitted.
• It should also be noted that, while steps401-411 have been described above as being in a specific order, other embodiments of the invention may order these steps in any desired manner. For example, some embodiments of the invention may set the threshold value and initiate thetimer1153 before relaying the request for data to the real-time service117. Alternately, some embodiments of the invention may relay the request for data to the real-time service117 before determining the threshold value and initiating thetimer1153. Still further, with some embodiments of the invention, thepresentation service115 may set the threshold value for thetimer1153 before initiating thetimer1153, while, with still other embodiments of the invention, thetimer1153 can be started before the threshold value for thetimer1153 is determined. Moreover, for example, with some embodiments of the invention, thepresentation service115 may designate thecache1151 after the request for data has been relayed to the real-time service117, before the request for data has been relayed to the real-time service117, before thetimer1153 has been set, or after thetimer1153 has been set.
• In any case, once the threshold value for thetimer1153 has been set and the request for data relayed to the real-time service117, thepresentation service115 then monitors the real-time service117 instep413 for a reply containing the retrieved data and the identification information identifying the presentation session corresponding to the request for the retrieved data. If a reply is not received, then instep415 thepresentation service115 determines if thetimer1153 has reached its threshold value. If thetimer1153 has not reached its threshold value, then thepresentation service115 continues to monitors the real-time service117 for a reply with the requested data. If, however, thetimer1153 has reached its threshold value, then thepresentation service115 sends a reply to the user'sremote communication device119 instep417, indicating that the desired data has not yet been retrieved from thedata store109.
• More particularly, when thepresentation service115 determines that the threshold value has been reached, it formulates and sends a reply to the user'sremote communication device119 indicating that the desired data has not yet been retrieved. It should be appreciated that any suitable type of reply message may be employed by various embodiments of the invention. For example, with some embodiments of the invention, the reply message may be a page (such as an HTML or WML page) that displays a message to the user stating that the desired data has not yet been retrieved. With some embodiments of the invention, the reply message may additionally prompt the user to manually resubmit the request for the desired data. Thus, the reply message may display an invitation to the user to resubmit the request, along with a command prompt to resubmit the request. When the user activates the command prompt, associated software code in the reply page will instruct the user'sremote communication device119 to resubmit the request. Such automatic reply operations are well known, and thus will not be discussed in further detail. With still other embodiments of the invention, however, the reply message may simply include software instructing the user'sremote communication device119 to automatically resubmit the request of the desired data. With these embodiments of the invention, the reply message may thus omit displaying a message to the user.
• For various embodiments of the invention, the reply message will also include presentation session identification data identifying the presentation session associated with the request. This presentation session identification information may be the same presentation session identification information provided to the real-time service117, or it may be different from the presentation session identification information provided to the real-time service117. Also, while the presentation session information provided to the user'sremote communication device119 may conveniently be transmitted with the reply message, it may also be transmitted in a separate communication. For example, the presentation session identification may be provided to the user'sremote communication device119 immediately after the user'sremote communication device119 has submitted an initial request for desired information.
• In any case, when the user'sremote communication device119 resubmits the request for the desired information, the resubmitted request includes the presentation session information associated with the initial request for the desired data. Thus, when the resubmitted request is received by thepresentation service115, thepresentation service115 determines that the request matches an existing presentation session instep401. Thepresentation service115 then proceeds immediately to step413 to determine if the desired data has been retrieved from thedata store109 and stored in thecache1151.
• If the desired data has been retrieved and cached incache1151, then the desired data is immediately returned to the user'sremote communication device119, as noted above. If, however, the desired data has still not been cached in thecache1151, then the process ofsteps401 and413-417 are repeated until the desired data is retrieved from thedata store109, stored in thecache1151, and then provided to the user'sremote communication device119 instep419.
• It should be noted that, with the illustrated embodiment, thepresentation service115 translates the retrieved data into a format that can be processed by the user'sremote communication device119 before transmitting the retrieved data to the user'sremote communication device119. It should also be appreciated, however, that this translation can be made at any point. For example, with some embodiments of the invention, the retrieved data can be translated into an appropriate format before it is stored in thecache1151, while with other embodiments of the invention the retrieved data may be translated into an appropriate format just before it is transmitted to the user'sremote communication device119. With still other embodiments of the invention, however, the requested data may alternately or additionally be translated by theaccess client103, the real-time service117, thedata store109 or even the user'sremote communication device119 itself. Still further, the translation may even be performed by a combination of these components (including the presentation service115).
• The request for data may thus be submitted and resubmitted by the user'sremote communication device119 until the desired data is retrieved from thedata store109 by the real-time service117 and stored in thecache1151. If there is an error in retrieving the desired data, then the real-time service117 may generate an error message informing the user'sremote communication device119 that the data cannot be retrieved. With some embodiments of the invention, this error message may be stored in thecache1151 instead of the desired data. When the user'sremote communication device119 then retrieves data from thecache1151, it will retrieve the error message informing the user that the desired data could not be successfully retrieved from thedata store109. Still other embodiments of the invention, however, may relay the error message immediately after receiving the error message from the real-time service117.
• With some embodiments of the invention, thepresentation service115, the real-time service117, or both may “pre-fetch” data from thedata store109. Thus, various embodiments of the invention may employ heuristics to predict how much data a user will request from thedata store109 base upon, e.g., the user's previous pattern of data retrieval. For example, some users will frequently retrieve new email messages from their email account. For such a user, the presentation service115 (or the real-time service117) may independently periodically request all new email messages for the user from thedata store109. Accordingly, when the user employs theremote communication device119 to retrieve his or her new email messages, that data will already be stored in thecache1151. Still other users, however, may only occasionally request new email messages. For these users, the presentation service115 (or the real-time service117) may not independently request new email messages from thedata store109.
• Similarly, some users will regularly request particular combinations of data. For example, some users will typically request retrieval of an email message, and then immediately request retrieval of any attachments to retrieved email messages. With these users, the presentation service115 (or the real-time service117) may independently request attachment data with any requests to retrieve new email messages for the user from thedata store109. Accordingly, when such a user then follows a request to retrieve a new email message with a request to retrieve attachment data for the retrieved email message, that attachment data will already be stored in thecache1151.
• Of course, various embodiments of the invention may employ further heuristics instead of or in addition to heuristics relating to retrieval frequency or the type of data retrieved. Such heuristics may include, for example, the level of service subscribed to by a user, the size of the data typically retrieved, or any other desired heuristics evaluation. Also, in addition to storing independently retrieved data in thecache1151, various embodiments of the invention may also go ahead and forward the independently retrieved data to theremote communication device119 without receiving an express request to retrieve that data.
Communication with the Access Client
• As previously noted, the real-time service117 retrieves the desired data from thedata store109 through theaccess client103. More particularly, when the real-time service117 receives a request for data from thepresentation service115, it relays that request to theaccess client103. Because theaccess client103 is hosted on thecomputer105 that has access to thedata store109, theaccess client103 can instruct thecomputer105 to retrieve the desired data from thedata store109. When thecomputer105 has obtained the desired data from thedata store109, theaccess client103 returns the desired data to the real-time service117.
• With some embodiments of the invention, the real-time service117 may communicate with theaccess client103 using conventional communication techniques available to thecomputer105, to thereby establish theconnection121. In some situations, however, thecomputer105 will be located in an environment shielded from unauthorized access by a barrier, such as thefirewall111 illustrated inFIG. 1. In these situations, the barrier may prevent many types of conventional two-way communication between the computer105 (and thus the access client103) and the real-time service117. With these embodiments of the invention, the real-time service117 and theaccess client103 may communicate using any suitable communication technique, such as the use of a virtual private network (VPN). In some situations, however, even if the barrier can be configured to allow for conventional two-way communication between thecomputer105 and the real-time service117, the process of reconfiguring the barrier may be onerous, particularly if a large number of users are employingdifferent computers105 to retrieve data from a remote communication device.
• Accordingly, with various embodiments of the invention the real-time service117 may employ a connection to theaccess client103 through thenetwork113 that will pass through the firewall. As will be appreciated by those of ordinary skill in the art, various firewall systems will typically allow one or more specific access points by which a computer, such as thecomputer105, may receive data from sources outside of the firewall. For example, conventional firewalls typically designate a port (sometimes identified as Port 80) through which a computer may receive data from outside sources. The real-time service117 according to various embodiments of the invention may thus use such an access port to employ a one-way communication connection with theaccess client103 through this type of designated port.
• Using this one-way communication connection, hereafter referred to as the command channel, the real-time service117 may send instructions to theaccess client103. More particularly, the real-time service117 may send instructions commanding theaccess client103 to retrieve and relay information, such as the desired information, back to the real-time service117. It also should be noted that the real-time service117 may use the one-way command channel to instruct theaccess client103 to retrieve information from a location other than thedata source109 as well. For example, a user may wish to add information, such as a new electronic mail message, to thedata store109 for storage or action. Upon receiving the new data from the user'sremote communication device119, the presentation service115 (through the real-time service117) may then instruct theaccess client103 to retrieve the new data from the real-time service117 for delivery to thedata store109.
• Thus, with various embodiments of the invention, the command channel may be used only to send commands from thegateway server101 to theaccess client103. Because a command typically will be an instruction to take some action (e.g., retrieve headers for the first ten messages in the electronic mail folder “inbox” of the user, retrieve today's appointments from the electronic calendar for the user, perform a search for the text “Mike” in the electronic mail folder “contacts” of the user, etc.), the commands will usually be relatively small (e.g., less than 1 kB). As a result of their small size, multiple commands can be multiplexed on the command channel.
• In turn, theaccess client103 can send data associated with the command to the real-time service117 (or retrieve data associated with the command from the real-time service117) over one or more alternate connections, collectively referred to hereafter as data channels. For example, the commands may include a specific address to which the associated data should be posted (or from which the associated data should be retrieved). The command may also include a parameter that can subsequently be used by theaccess client103 to identify that its response (either posting or retrieving data) is a reply to that specific command. Using this information, theaccess client103 may then post data to the specified address (or retrieve data from the specified address) through a different socket from the socket used by the command channel. Similarly, theaccess client103 may also post various commands to the real-time service117. These commands may, for example, relate to the authorization of additional users for theaccess client103.
• Thus, a reply to a command from the real-time service117 will not interfere with the access client's receipt of new commands from the real-time service117, or with the transmission of data associated with responses to earlier commands. Advantageously, this arrangement improves the performance by allowing data channels to be established on as-needed basis directly to the physical server currently serving the user's device Together, the command channel and the data channels provide theconnection121 that allows two-way communication between the real-time service117 and theaccess client103 through a barrier such as a firewall.
• For example, the real-time service117 may command theaccess client103 to retrieve the desired data from thedata store109, and then post the retrieved data, along with the presentation session identification information corresponding to the request, back to a specific address. The address may be a universal resource location (URL) address for a location maintained by the real-time service117, thereby allowing the real-time service117 to retrieve the desired data from theaccess client103. The instructions (or a preceding or subsequent instruction) may also command theaccess client103 to take some action with respect to the new data, such as storing the new data in thedata store109 or sending the new data to another location.
• As previously noted, when theaccess client103 establishes thepersistent connection121 with the real-time service117, the real-time service117 creates a real-time session for that connection. The real-time session may be, for example, a data object containing any desired data about the user and the connection, such as the port of thecomputer105 through which theconnection121 is established. With some embodiments of the invention, the real-time session may be stored in thedirectory127. Alternately, the real-time session may be stored in another suitable memory location.
• For various embodiments of the invention, a proxy service may be employed between theaccess client103 and the real-time service117 (e.g., in the public wide area network113). With this type of arrangement, the proxy service may close theconnection121 on its own accord after a predetermined amount of time without an exchange of data over the connection. Alternately or addition, other problems could occur relating to the proxy service, causing it to sever theconnection121. It would therefore be beneficial for theaccess client103 to be able to detect when theconnection121 is severed, so that it can reestablish theconnection121. Conventional application programming interfaces for network communications, however, such as conventional application programming interfaces for communicating using TCP/IP, are typically not convenient for providing an application feedback when a network connection suddenly closes. Moreover, the real-time service117 will not necessarily know that theconnection121 has been severed until, for example, it tries to write to the socket through which theconnection121 was established.
• Accordingly, with various examples of the invention, the real-time service117 may regularly send “heartbeat” messages to theaccess client103. These heartbeats may be, for example, small groups of data packets that can be sent to continually maintain the one-way connection between the real-time service117 and theaccess client103. By periodically trying to send these heartbeats, the real-time service117 can immediately detect when theconnection121 has been severed. Thus, by maintaining a continuous connection between the real-time service117 and theaccess client103, the real-time service117 will be prepared to immediately process requests for desired data from the user'sremote communication device119 without having to initiate a new command channel for each new request.
• With some embodiments of the invention, the heartbeat may include data indicating to theaccess client103 when the next heartbeat from the real-time service117 should be received. If theaccess client103 then does not receive the next heartbeat within the indicated time period (and any additional buffer period, as desired), then theaccess client103 can conclude that theconnection121 is severed and needs to be reestablished. Also, because the heartbeat is generated by the real-time service117, the time value indicating the rate of the heartbeat can be controlled by the real-time service117. More particularly, the rate data for the heartbeats can be adjusted by the real-time service117 based upon, for example, the amount of traffic being handled by thegateway server101. Thus, the heartbeat is dynamically schedulable.
• For some implementations of the invention, the scheduled rate of the heartbeat may be the same for everyconnection121. Alternate embodiments of the invention, however, may have two separate intervals for heartbeats. More particularly, some embodiments of the invention may have one heartbeat rate for active presentation sessions where a user is presently using acommunication device119 to communicate with thegateway server101, and another heartbeat rate for inactive sessions. This arrangement can provide a quicker connection error detection time for sessions where a user will notice when theconnection121 is erroneously severed, and a less resource intensive connection error detection time where a user will not immediately notice when theconnection121 has been erroneously severed.
Multiple Use of the Access Client
• While the use of theaccess client103 was described above with reference to asingle access client103 accessing thedata store109, various embodiments of the invention may havemultiple access clients103 communicating with thegateway server101. That is, each of a plurality of users can maintain anaccess client103 communication with thegateway server101. Moreover, a user can employmultiple access clients103 to communicate with thegateway server101.
• Additionally, various embodiments of the invention may allow asingle access client103 to service more than one user. For example, with these embodiments, when a user installs theaccess client103 on thecomputer105, theaccess client103 may inquire as to whether the user wants to delegate remote access to the user's data in thedata store109 through anyone else (i.e., another user employing a different access client103). If the user would like the ability to access desired data in thedata store109 through another user'saccess client103, then theaccess client103 may facilitate that arrangement.
• For example, if theaccess client103 is being employed in a corporate network environment as illustrated inFIG. 1, theaccess client103 may provide the user with a list of other persons having access to the corporate data store109 (e.g., everyone in a corporate email server). When the user selects another person from the list, theaccess client103 may, e.g., arrange for the selected person to receive an email reporting his or her selection (along with instructions on how to obtain and install anaccess client103, if necessary). The user'saccess client103 may also convey an encrypted message to the selected person, either by electronic mail or by another transmission technique. The encrypted message contains the information necessary to obtain the user's access to thedata store109. Thus, if the selected person agrees to provide access to thedata store109 for the user, the selected person'saccess client103 can employ the access information contained in the encrypted message to obtain the user's access to thedata store109.
• Advantageously, with some of the embodiments of the invention described above that employ a one-way command channel, the one-way command channel can service multiple users of theaccess client103. More particularly, commands corresponding to different users may be multiplexed over the single command channel. With this arrangement, when theaccess client103 establishes theconnection121 with the real-time service117, it identifies the users that it is serving to the real-time service117.
Use of Multiple Gateway Servers
• While the previous discussion described the user of only asingle gateway server101 for ease of understanding, many implementations of the invention would employmultiple gateway servers101, as shown inFIG. 5, to both increase capacity and redundancy. For example, some embodiments of the invention may employgateway servers101 in an N+1 architecture, including asmany gateway servers101 as needed for a desired capacity, plus anextra gateway server101 for redundancy.
• A conventional N-tier Web service system may typically have between one and four tiers, depending upon the purpose of the service. For example, a conventional Web service system may include a first-tier Web server, a second-tier application server, and then a third-tier database server. In general, a user may access such a Web service system by presenting the Web server tier with a request, which then flows to the application server, and onto the database server in a vertical manner. This type of conventional network will often include one or more load balancers that route incoming requests based upon the current use of each server (i.e., the load balancer will route incoming requests to servers that are less occupied).
• With various embodiments of the invention, however, each user has at least oneaccess client103 installed on acomputer105, which in turn establishes a persistent connection to agateway server101. Thus, when a user employs aremote communication device119 to transmit a request to thedata retrieval system100′, it would be more efficient to specifically route the request to thegateway server101 that has already established apersistent connection121 to the user'saccess client103.
• Advantageously, various implementations of the invention may conveniently match a user's incoming request to send or retrieve data with the user'saccess client103. As noted above, when anaccess client103 connects with a real-time service117, the real-time service117 creates a real-time session for that connection. While a real-time session exists for apersistent connection121, it may exist across multiple requests fromremote communication devices119. That is, when a request from aremote communication device119 is received by thepresentation service115, it can be mapped through a real-time session to the real-time service117 maintaining theconnection121 to the user'saccess client103. Moreover, each time that the request is subsequently received from theremote communication device119, it can again be mapped back to the proper real-time service117 through the real-time session. Thus, these embodiments of the invention provide a collocation process to collocate a user's presentation session, maintained by apresentation service115, with the user's real-time session corresponding to the persistent connection established between the user'saccess client103 and a real-time service117.
• Referring now toFIG. 5, with collocation, when anaccess client103A is turned on, it negotiates a secure connection to a real-time service117 provided by a gateway server (e.g., the real-time service117A provided by gateway server101A). In the process of establishing this connection, information pertaining to the connection is stored in thedirectory127. For example, when a user USER1 employs theaccess client103A, the real-time service117 may note that USER1 has established a connection from theaccess client103A to gateway server101A (or to real-time service117A). It should be noted that, with some embodiments of the invention, a user may delegate his or access to a data store (e.g., data store109A inFIG. 5) tomultiple access clients103 as described above. If a user thereby is associated with connections to multiple real-time services117, then suitable heuristics may be employed to select one connection to agateway server101 that is preferable to the others for the purpose of collocating a presentation session with a real-time session.
• When a user subsequently employs aremote communication device119 to, e.g., submit a request for data from thedata store109, thepresentation service115 receiving the request will initially authenticate the request, as discussed in detail above. For example, as previously noted, thepresentation service115 may provide the user'sremote communication device119 with an authentication user interface requesting the user's name, password, etc. Once the remote communication device119 (i.e., the user) has been authenticated, thepresentation service115 makes a query to its associated real-time service117, which in turn queries thedirectory127 as to the gateway server101 (or, alternately, the real-time service117) corresponding to the user. More specifically, the real-time service117 may query to thedirectory127 whether the user has established an existingconnection121 between anaccess client103 and agateway server101, and if such aconnection121 currently exists, whichgateway server101 is maintaining theconnection121.
• If, for example, a request for data from USER1 is initially routed to gateway server101 B, by querying thedirectory127 the gateway server101 B can determine that the user'saccess client103 is currently connected to the gateway server101A (i.e., to the real-time service117A). Based upon this information, thepresentation service115B generates a redirect response for theremote communication device119. The redirect response may be device specific, but may not require any special software. Instead, the response may be, for example, a conventional HTML, WML or HDML redirect command. The redirect response then causes theremote communication device119 to issue its subsequent requests for the desired data specifically to the gateway server101A. More particularly, the redirect response may, for example, provide theremote communication device119 with software instructions, such an HTTP “cookie.” These software instructions contain routing information (or, alternately, are themselves routing information) to be included in subsequent submissions of the request for the desired data.
• Accordingly, when theremote communication device119 resubmits a request for desired information, the routing information can be used to route the request directly to thepresentation service115 associated with the real-time service117 maintaining a connection to the user'saccess client103. For example, as shown inFIG. 5, adata retrieval system100′ according to various implementations of the invention may employ one or more load balancers501. These load balancers501 route both incoming data retrieval requests and incoming data submission requests fromremote communication devices119 to agateway server101. With these embodiments, when a load balancer receives a request, it first checks to determine if the request contains routing information, such as a cookie as described above. If the request does not contain routing information, then the load balancer501 assigns the request to agateway server101 based upon the current load distribution of all of thegateway servers101, as known in the art. If, however, the load balance501 determines that a request does contain routing information, then it routes the request to thegateway server101 identified in the routing information.
• As will be appreciated by those of ordinary skill in the art, with this arrangement each load balancer501 may have a public network address, such as a public Internet protocol (IP) address. Thegateway servers101 behind the load balancers501 may then have virtual network addresses that cannot be directly accessed from outside of the network. For these implementations of the invention, the routing information will provide the virtual network address for the desiredgateway server101, and the load balancer501 receiving a request containing the routing information can then map the request to the identifiedgateway server101.
• With various examples of the invention, the redirect response may also contain additional “handoff’ information to be inserted into the subsequent requests for the desired data. When the routedgateway server101 then receives a subsequent request for the desired, it can determine from the handoff information that the request is a handoff from anothergateway server101. The handoff information may also contain a time stamp, so that the routedgateway server101 can confirm that the handoff was recent. Using this information, it will associate the request with a presentation session on theinitial gateway server101. The routedgateway server101 can thus collocate the presentation session from thepresentation service115 of theinitial gateway server101 to itsown presentation service115, so that itsown presentation service115 returns the desired data to theremote communication device119 when it is retrieved.
• According to still other embodiments of the invention, the routedgateway server101 may use the handoff information to employ the authentication performed by theinitial gateway server101, thereby avoiding requiring that the user reauthenticate himself or herself. Accordingly, for these embodiments, the handoff information may be encrypted, to prevent unauthorized users from creating false handoff information to avoid authentication. Of course, the handoff information may be encrypted even if the routedgateway server101 does not employ the authentication performed by theinitial gateway server101. Also, it should be noted that, with various embodiments of the invention, the collocation process can alternately be performed by the load balancers501, but this may require customized code.
• Thus, referring back to the above example for USER1, after a request for data from USER1 is initially routed to gateway server101B, the gateway server101B may determine from a query to thedirectory127 that the user'saccess client103 is currently connected to the gateway server101A (i.e., to the real-time service117A). Accordingly, the gateway server101 B provides a redirect response to theremote communication device119A with handoff information. The handoff information will include routing information, such as, e.g., a virtual network address, for the gateway server101A. The handoff information may also be encrypted, and may include a time stamp and, e.g., confirmation of USER1's authentication. When USER1 resubmits requests for the desired information, the new requests will include the handoff information. Accordingly, when theload balancer501A receives the resubmitted requests, it will route the requests to the gateway server101A for handling.
• As will be appreciated by those of ordinary skill in the art, there may be some situations where this collocation process may not be employed. For example, a user may initially employ afirst access client103 to retrieve data. If thatfirst access client103 then fails before the data is retrieved, the user may be forced to employ a second delegatedaccess client103 to retrieve the information. In this scenario, it would not be desirable to reroute subsequent requests to anothergateway server101, as thegateway server101 corresponding to thefirst access client103 may already have some or all of the requested data in thecache1151. Also, collocation may not be desirable when a user first signs up to the data retrieval system with thecomputer105, but does not have anaccess client103 installed yet.
• It also should be appreciated that, with different embodiments of the invention, a separate locator service may perform one or more of the collocation functions instead of thepresentation service115. For example, with some embodiments of the invention, a locator service may query thedirectory127 to determine thegateway server101 to which the user'saccess client103 is currently connected, and then generate a corresponding redirect response for theremote communication device119.
• Of course, various embodiments of the invention may alternately or additionally employ conventional remote call procedures to associate a presentation session maintained by apresentation service115 on agateway server111 with aconnection121 maintained by a real-time service117 on adifferent gateway server101. Such remote call procedures may be employed, for example, instead of the collocation process described above, or if the collocation process fails for some reason.
Secure Communication Between the Access Client and the Real-Time Server
• To establish a secure connection to a computer, a browser will typically use an encryption protocol, such as the Hypertext Transfer Protocol Secure, which employs the Secure Sockets Layer (SSL) encryption technique. With this protocol, encryption key certificates are preinstalled, and public key and private keys are used during a “handshake” process to negotiate a session key for the connection. With an SSL handshake, a third party cannot determine the session key, even if all of the exchanged data is intercepted. This type of protocol requires a great deal of resource overhead to begin, however, and requires a great deal of resource overhead to maintain. Moreover, with various examples of the invention, thepresentation service115 may be implemented using a conventional Web server, but the real-time service117 may be implemented using a different type of server. With this arrangement, the real-time service117 may use HTTP and/or HTTPS communications, but only to deliver messages through firewalls (e.g., for requests to Port 80, which conventionally are passed by firewalls).
• Accordingly, it would be beneficial to allow theaccess client103 and the real-time service117 without maintaining an SSL session. Advantageously, various embodiments of the invention allow theaccess client103 to communicate with the real-time service117 without having to maintain an SSL session. According to these embodiments, the load balancers501 also serve as encryption protocol terminators in addition to load balancers. That is, the load balancer may have SSL software or hardware (e.g., SSL accelerator cards) that handles SSL communications very quickly. When the load balancer passes a communication onto agateway server101, the communication thus is decrypted to a regular HTTP format (i.e., the load balancer501 decrypts the communication before passing it to the gateway server101). These specialized load balancers are known in the art and may be obtained from a variety of sources, and thus will not be discussed in further detail.
• When theaccess client103 attempts to establish a connection to the real-time service117, it does not communicate directly with the real-time service117. Instead, theaccess client103 initially transmits an encrypted message, such as a HTTPS message, through a load balancer501 to apresentation server115. The HTTPS message is received at the load balancer501, which decrypts the message and routes the message to apresentation service115 as a HTTP message. More particularly, the load balancer501 routes the request to thepresentation service115 of agateway server101 according to its balancing algorithm (e.g., to thegateway server101 that is the least busy). Thepresentation service115 then calls into the real-time service117 to report that theaccess client103 will soon be providing a request to establish a connection.
• In response, the real-time service117 creates an entry in a list of pending connections (e.g., a table ofaccess clients103 that will soon be connecting to the real-time service117). In response, a unique session encryption key is generated (e.g., a 128-bit key), which is unrelated to the initial SSL communication between theaccess client103 and the load balancer501. Any desired encryption algorithm, such as RC4, may be used to generate the encryption key. The entry in the table will thus include the identity of theaccess client103, a public session identification and a private encryption key.
• Thepresentation service115 then sends an HTTP reply that contains the address (such as a universal resource location (URL) address) corresponding to the real-time service117 to which theaccess client103 should connect. The reply also includes the public session identification and the private encryption key. Theaccess client103 can then transmit a message to the real-time service117 using the address (e.g., using a URL of the form http://www.gateway.com/real-timeserver sessionID=xxxxxx). Using this arrangement, the message sent from theaccess client103 to the real-time service117 may be an unencrypted HTTP message, but the data in the message can be encrypted using the private encryption key. The real-time service117 can then use the session identification in the message to locate the appropriate entry in the table with the corresponding private encryption key. The real-time service117 will then decrypt the contents of the message with the private encryption key.
• Thus, theaccess client103 and the real-time service117 can communicate without maintaining an encryption session. Instead, theaccess client103 and the real-time service117 can use the public session identification and the private encryption key to securely communicate. Moreover, by handing off the connection directly to the real-time service117, these embodiments of the invention can avoid maximizing the limit of the load balancer501. Of course, with still other embodiments of the invention, theaccess client103 and the real-time service117 can securely communicate while maintaining an encryption session (such as a SSL encryption session), but also have the data exchanged over the secure connection separately encrypted. That is, the data exchanged over the secure connection may use different encryption information, as described in detail above, than the encryption information used to maintain the secure connection.
CONCLUSION
• While the invention has been described with respect to specific examples including presently preferred modes of carrying out the invention, those skilled in the art will appreciate that there are numerous variations and permutations of the above described systems and techniques that fall within the spirit and scope of the invention as set forth in the appended claims.

Claims (1)

1. A gateway server, comprising:

receiving means for receiving data requests from a plurality of remote communication devices, the data requests requesting to send data to or receive data from a storing means for storing data, such data requests corresponding to users of the plurality of remote communication devices which originate the data requests therefrom; and

exchanging means for exchanging the data requests from the receiving means to an access client associated with the storing means,

wherein the receiving means establishes a communication instance for conveying data between a requesting remote communication device and the exchanging means, and associates the communication instance established for an initial data request of the requesting remote communication device with subsequent data requests from the same requesting remote communication device; and

the receiving means utilizes device characteristics corresponding to the requesting remote communication device to determine a threshold time to return a reply to a data request to the requesting remote communication device.

Images