Instant messaging HTTP gateway

In accordance with at least one embodiment, a system comprising an HTTP gateway which is adapted to establish a communication link with an HTTP server. The system further comprises an instant messaging communication subsystem which is adapted to enable communication between a plurality of instant messaging user interfaces coupled to the instant messaging communication subsystem. The HTTP gateway also establishes a communication link with the instant messaging communication subsystem and receives commands from the instant messaging user interfaces. The received commands are converted to HTTP requests, which are then sent to the HTTP server. The HTTP gateway receives HTTP responses to the HTTP requests from the HTTP server and sends the HTTP responses to the instant messaging user interfaces via the instant messaging communication subsystem.

BACKGROUND

Information is generally transported around the internet using a technology called Hypertext Transfer Protocol (“HTTP”). HTTP servers can receive and process HTTP requests and issue HTTP responses. HTTP requests are generally command-based messages issued when, for example, an internet user clicks on a hyperlink or enters a website address, also referred to as a uniform resource locator (“URL”), on a computing device, such as a desktop computer or portable internet-ready device.

To visit a particular web page, an internet user will typically enter a URL by one of several methods, including entering the URL into an address field, selecting the URL from a list of previously “bookmarked” URLs, or clicking on a hyperlink. This action causes an HTTP request to be sent to an HTTP server. The HTTP server then issues a response to generate a web page, commonly in the form of a language that can be translated into a graphical display for a user. Hypertext Markup Language (“HTML”) and Active Server Pages (“ASP”) are exemplary languages used for such a purpose.

HTTP responses may incorporate information not stored on the HTTP server. For instance, back-end databases and other data stores may be linked to the HTTP server to supply additional information to be provided in an HTTP response. Such may be the case when a user performs a search on a website. Detailed information may be stored on a back-end database or other data store and provided to the HTTP server for translation into the HTTP response.

HTTP servers can process HTTP requests from fixed locations and portable electronic devices. Many personal digital assistants (PDAs), cell phones and other internet-ready portable electronic devices are capable of interacting with an HTTP server. Generally, operating on the Wireless Access Protocol (“WAP”), the portable electronic device may send a device-specific request to the HTTP server. A WAP gateway may receive the data request and translate it into an HTTP request readable by the HTTP server. The HTTP server may then issue an HTTP response in a language understandable by the WAP device, such as Wireless Markup Language (“WML”).

Instant messaging (“IM”) technology is used with growing frequency to allow users to message one another at or near real-time. Generally, end-users log in to an IM infrastructure, such as ICQ Instant Messenger, AOL Instant Messenger, Yahoo Messenger or MSN Messenger, using IM client software, which relays user-entered messages from one end-user to another. The term “bot” is derived from the word robot and in general comprises a computer program that acts as an intelligent agent to perform a given task. IM bots are sometimes logged in to IM services, mimicking a human user, to provide greetings and responses to simple commands. Generally, these bots operate from a script located on the IM end-user's computer, which hosts the bot and responds to simple commands via the pathway between the end-user's computer and the IM infrastructure. It is desired to allow an IM bot that is logged into an IM infrastructure to interact, via a HTTP gateway, with an HTTP server and its linked databases to permit the IM bot to provide responses to end-user queries by allowing an end-user to interact with the bot that is logged into the IM system.

SUMMARY

In accordance with at least one embodiment, a system comprising an HTTP gateway which is adapted to establish a communication link with an HTTP server. The system further comprises an instant messaging communication subsystem which is adapted to enable communication between a plurality of instant messaging user interfaces coupled to the instant messaging communication subsystem. The HTTP gateway also establishes a communication link with the instant messaging communication subsystem and receives commands from the instant messaging user interfaces. The received commands are converted to HTTP requests, which are then sent to the HTTP server. The HTTP gateway receives HTTP responses to the HTTP requests from the HTTP server and sends the HTTP responses to the instant messaging user interfaces via the instant messaging communication subsystem.

NOTATION AND NOMENCLATURE

DETAILED DESCRIPTION

Referring now toFIG. 1, a representative embodiment is shown of an Instant Messaging (IM) HTTP gateway100for linking an IM infrastructure200and an HTTP server300. An IM bot110appears on an IM messaging service as another user. However, the bot110is a computer program that may log into the IM infrastructure200and receive instructions from a human via “IM user”210, preferably in the form of command-line text. “IM user” is an IM client application program with an interface for interacting with humans. For example, the client application program used by humans to access and use the Yahoo Messenger service may be an IM user. Generally, IM user210runs on a human user's computer, such as a desktop PC, laptop or other hand held computing device. A human may interact with IM bot110, IM infrastructure200(e.g., the Yahoo Messenger service) and other IM users via IM user210. After receiving a user-entered command from IM user210, IM bot110may take programmatic action, such as querying a database310and formulating a response to be sent back through the IM infrastructure200for viewing by a human via the interface of IM user210.

The IM HTTP gateway100may receive a specifically formatted data request from IM user210via IM bot110, which the gateway100translates and relays to the HTTP server300. While WAP gateways, such as WAP gateway510, generally translate WAP-enabled, device-specific data requests, the IM HTTP gateway100translates IM-infrastructure-specific data requests. Each IM infrastructure200(such as Yahoo Messenger or ICQ Instant Messenger) may use a uniquely formatted data request that is used by IM user210to send requests to IM HTTP gateway100. The gateway100translates the data requests into an HTTP request that may be processed by HTTP server300. The HTTP server300may contain the requested information or may query back-end databases310or other linked data stores320for the desired information. The HTTP server300may also provide data to various websites400and/or WAP devices500.

In operation, the IM HTTP gateway100may read a configuration file, which may be stored on the computer or server housing the gateway100. The configuration file informs IM HTTP gateway100which IM infrastructure(s)200to log in to, and which bots110to use for that particular login. A single computer program may be used to start each IM bot110or a different program may be used to start an IM bot110. The configuration file may also inform IM HTTP gateway100to which HTTP server300to forward requests. Furthermore, the configuration file may identify which HTTP paths on the server are to be associated with (or “mapped to”) which bots110and the commands that may be received from such bots.

After a user210logs in to an IM infrastructure200, the user may enter a specifically formatted command, which is sent as an IM-specific data request through the IM infrastructure200to the IM bot110. The IM bot110may then relay the request to the IM HTTP gateway100, which translates the IM-specific data request into an HTTP request that may be sent to the HTTP server300. While depicted as two distinct entities inFIG. 1, alternatively, the IM HTTP gateway100and IM bot110may be combined as a single entity. In such a case, each instance, or bot, may handle conversion of an IM-specific data request into an HTTP request for the HTTP server300.

After receiving an HTTP request, the HTTP server300may then issue an HTTP response back to the IM HTTP gateway100. The HTTP gateway100strips the textual data from the response and reports this text back to the user210through IM infrastructure200. If desired, the HTTP server300may be configured such that HTTP server300performs extraction of the textual data before sending the HTTP response back through the IM HTTP gateway100.

Although IM bot110is shown inFIG. 1as linked to a single IM infrastructure200, an IM bot110may log simultaneously in to a plurality of IM infrastructures200. While each bot110has been described as a specific instance of a software application, bot110may be logged in to different infrastructures200under the same username and with the same associated commands. As previously stated, more than one instance of the same software application may be logged in to an infrastructure200, thereby providing a distinct bot110for each instance, each potentially having its own username and unique associated commands.

All users210logged in to a particular IM infrastructure200may have access to all bots110that are logged in to the IM infrastructure200. However, each bot110may be customized to restrict access to only certain users. Furthermore, each bot110may be customized as to which commands the bot will process. Configuration of each bot may be established in the configuration file included within the IM HTTP gateway100.

Optionally, an HTTP gateway100may store settings and other information about a specific user210. Settings relating to a user210may be maintained in a “cookie” file on the HTTP gateway100. As such, the settings may be maintained between logins and associated with user210the next time the user logs in. In an alternative embodiment, the settings may be stored in volatile memory, such as in the random access memory of the computer housing IM user210. However, such an approach may not allow settings to be maintained in memory between logins, but may require fewer permanent storage resources.

The IM bot110may operate in a synchronous fashion, such that data is provided to user210when requested (i.e., one command issued by a user210provides only one response). However, the IM HTTP gateway100also may be configured to provide asynchronous data to user210through IM infrastructure200. IM HTTP gateway100may be configured such that one data-request command issued may result in a plurality of responses at various intervals. For example, a user may issue a single command to the IM bot110asking the IM HTTP gateway100to provide stock prices, and the IM bot110may return an updated response once every user specified time period (e.g., 15 minutes). Alternatively, the IM HTTP gateway100may be pre-configured to provide asynchronous data replies at default intervals.

FIGS. 2A,2B and2C show a schematic representation of an exemplary embodiment of the procedure that IM HTTP gateway100and IM bot110perform in processing a data request from IM user210. Referring now toFIG. 2A, in block610IM HTTP gateway100may read a configuration file. Based, at least in part, on the information contained in the configuration file, in block620IM HTTP gateway100may determine the IM infrastructure in which IM bot110may be logged into. Also based, at least in part, on the information in the configuration file, IM HTTP gateway100, in block630, may determine the appropriate HTTP server300to which it may forward requests received by IM bot110from IM user210. In block640, IM HTTP gateway100may map each known user command to a specific path on the HTTP server300. In block650, IM HTTP gateway100may initiate an instance of IM bot110and may log into the selected IM infrastructure200.

Referring now toFIG. 2B, in block660IM bot110may poll the IM infrastructure200to determine whether it has any new message from any IM user210. If IM bot110receives a request from an IM user210to add IM bot110as a “friend,” then IM bot110replies “yes” to that request in block670. In block680, IM bot110may check to see whether there is any other message. If there is no other message, then IM bot110may return to polling IM infrastructure200for new messages as depicted in block660. If IM bot110locates a new message from IM user210, then in block690IM HTTP gateway110may begin translating the IM user210request into an HTTP request which may be sent to HTTP server300. In some embodiments, the first word of the user request is translated to be the command name. In such embodiments, as depicted in block700, the remaining text in the message is assumed to be in the form <variable>=<value>. For example, if IM user210sends the request “PHONE NAME=JOHN SMITH,” then the first word, “PHONE,” is recognized as a command that tells the IM HTTP gateway100to convert that command into an appropriate database query that will look up the telephone number based on a given name of a person. The remaining text, “NAME=JOHN SMITH,” may be translated to mean that the word “NAME” is the <variable> and the text “JOHN SMITH” is the <value> of the <variable> “NAME.”

Other formats, schemes or syntax may be used for creation of the IM user210requests. For example, instead of the above-described user request in the form of <variable>=<value>, user requests may be implemented using positional variables. With positional variables, the parameter in question may be assumed based on its position relative to other items in the user request message. Using the positional variable scheme, the above example request “PHONE NAME=JOHN SMITH” is replaced with simply “PHONE JOHN SMITH.” The position of the words “JOHN SMITH” in the message indicates that it is the <value> of the <variable> “NAME.”

Referring now toFIG. 2C, in block710the IM HTTP gateway100may create an HTTP request based on the request received from IM user210. In block720, IM HTTP gateway100may send the HTTP request to the target HTTP server300in the form of form variables. Other formats may also be used. HTTP server300may process the HTTP request and may make any necessary calls to back-end databases310or other data stores320to formulate an HTTP response. HTTP server300may send the HTTP response to the IM HTTP gateway100. In block730, IM HTTP gateway100may receives the HTTP response from HTTP server300. In some embodiments, in block740, IM HTTP gateway100may further process the HTTP response by extracting the text portion of the response which corresponds to the answer that is responsive to the request received from IM user210. In block750, IM HTTP gateway100may, through IM bot110, send the text response to the appropriate IM user210via IM infrastructure200. IM HTTP gateway100may continue processing of other requests from IM user210by looping back to block660inFIG. 2Band may continue to poll IM infrastructure200for new messages from any IM user210.

As previously stated, in the foregoing discussions any functionality performed by IM HTTP gateway100may be performed by IM bot110and vice versa. This is because in any given implementation, it is possible that IM HTTP gateway100and IM bot110may be implemented as one programmatic entity or two different entities. When implemented as two separate entities, the functions performed by each may be assigned based on programmer preference and/or based on application specific or other factors.

FIG. 3depicts a computer system300configured to be an embodiment of IM HTTP gateway100discussed above and as depicted inFIG. 1. Computer system300comprises a central processing unit (“CPU”)310coupled to memory storage320. Memory storage320comprises software330and configuration files340. Software330comprises computer program(s) for performing the functionality of IM HTTP gateway100discussed above and as depicted inFIG. 1. Alternatively, software330further comprises computer program(s) for performing the functionality of IM bot110discussed above and as depicted inFIG. 1. Configuration files340comprise data which informs IM HTTP gateway100, among other things, which IM infrastructure(s)200to log in to, and which IM bots110to use for that particular login. CPU310may be programmed with instructions from software330to perform the functionality of IM HTTP gateway100discussed above. Alternatively, CPU310also may be programmed with instructions from software330to perform the functionality of IM bot110discussed above.