Method and system for facilitating instant messaging transactions between disparate service providers

Method and system for facilitating instant messaging transactions between disparate service providers

Broadly speaking, the present invention relates to instant messaging over an electronic network such as the Internet or an intranet (eg, a private network) between two or more user addresses in different domains. In particular, the present invention relates to instant messaging between two or more user addresses, wherein at least the two user addresses have different domain names, such as domain names from different instant messaging service providers.

Instant Messaging (IM) is a method and system for live or near live communication over the Internet or other electronic network between two users who are simultaneously logged on to an IM Service Provider (IMSP). An IMSP facilitates IM between its users by providing access to the software as well as the network. It should be noted that there are generally two types of software: "client-software" that is downloaded by the end user (usually it is freely distributed) and "server-software" that is not downloaded by the end user. Software is the core and engine of an IMSP It is the behavior of server-software to distinguish IMSPs from one another by providing different enforceable features Typically, users will be able to access other users of the same IMSP who have downloaded the same or compatible software. and IM client-software that allows them to communicate via IM. IMSPs are diverse, for example Foreignerless Village (WV), AOL, Yahoo!, MSN and ICQ (AOL is a registered trademark of America Online, Inc.; Yahoo! is a registered trademark of Yahoo! Inc.) trademarks; MSN is a registered trademark of Microsoft Corporation; and ICQ is a registered trademark of ICQ, Inc.). Since most IMSPs use proprietary solutions, IM software from one IMSP generally disables IM communication with users of other IMSPs.

A typical IM software today includes an IM client - a first user (eg User 1) who downloads the software to his computer. The IM software downloaded to the user's computer is referred to as client-software (or, more simply, client), and this Agreement is hereby maintained. The client connects to the IMSP server when user 1 logs on. The client is preconfigured to know the server's IP address, so when a user logs in (by entering a username and password) using the pre-downloaded proprietary client, the client requires the user to connect to the server and authenticate. Once the user is authenticated, the server updates the client with a list of friends and their prescence information. The server sends back a message to user 1's client from the buddy list created by user 1 about which friends are logged on and their presence information (eg mood, availability, etc.). The client changes the status displayed on User 1's computer to indicate which friends are logged on. User 1's access information is also sent by the server to the logged-on friends' clients. When User 1 wants to send an IM message to User 2, a friend who is logged on, User 1 clicks or selects User 2's name (IM address), types or attaches the message in the provided computer window to send the message. do. Since the client of user 1 has already been provided with the existence information of the client of user 2, the message from user 1 is sent directly to user 2.

It can be noted here that the transmission of the message is not guaranteed in the IM, so if the IM is sent from the source to the destination it is not guaranteed (although in rare cases) that it will reach the destination. Note that although it is possible to send a message to an end user who is not logged into the IMSP server, the behavior of this feature is server dependent (eg, Yahoo! will store the user's messages until the next user login, while some other IMSPs will not). Also note that the message from user 1 is not sent directly to user 2, but instead it is routed through the IMSP server software.

That is, the current IM architecture sends all IM messages through a message routing server. A reply from user 2 is sent to user 1 in a similar manner. The IM session remains open until one of the users logs off, for example by logging off of his client. The client then signals the offline status to the IMSP server, and the server then notifies the clients of all online friends of the modified status. It should be noted that logging off a client is distinct from closing a client, and this logoff only changes presence information (eg, from activity to idle).

One major limitation is that users of one IMSP identified by one domain name cannot IM with users of another IMSP identified by another domain name. This is because each IMSP does not have proprietary standards on how to pack and unpack messages, and these standards do not necessarily allow for the proprietary standards of other IMSPs. Some users are overcoming this limitation by maintaining accounts at each IMSP where one of the users' possible friends has an account. However, this allows users to maintain multiple accounts with multiple login identifiers and passwords, keep clients open for each IMSP the user chooses to monitor for any given session on the computer, and Disable IM 'conversation' with two friends who each use it. For example,<u>user1@yahoo.com</u>silver <u>user2@yahoo.com</u>You can chat with IM but <u>user2@msn.com</u>and not so

Some IMSPs advertise the ability to facilitate IM communication between users in only designated different domains. For example, Odigo (Odigo is a registered trademark of Odigo, Inc.) claims on its website (www.Odigo.org) that IM users can access two different IMSPs, AIM and ICQ. do. A specific protocol to facilitate this is believed to be proprietary. However, since IM is only enabled between designated domains, it is presumed that this service will be facilitated by servers associated with each domain acting in cooperation under a contractual relationship between IMSPs.

For agreements relating to this disclosure, IM Address"<u>username@domainname</u>"This is parsed as follows. The characters to the left of the '@' sign are called usernames. The characters to the right of the '@' sign constitute the domain name or domain, and the domain name is the top-level domain name for simplicity in this convention. IM addresses and their parts are underlined for clarity.

According to presently preferred embodiments of the present invention, the above and other problems are overcome and other advantages are realized.

A method for facilitating instant messaging (IM) between two domains over an telecommunications network is shown. The first address includes a first domain and the second address includes a second domain different from the first domain. The steps of the method include first receiving a first message directed from a first address to a second address. The next step is to map the first address to a substitute address including the second domain. Next, the first message is sent from the alternate address to the second address.

Various additional and additional steps to facilitate IM communication back from the second address to the first address are disclosed and discussed below. The present invention also includes a system for facilitating instant messaging over an electronic network between a first address comprising a first domain and a second address comprising a second domain different from the first domain. The first domain relates to a first instant messaging service provider and the second domain relates to a second instant messaging service provider. The system includes an alternate address and a map that correlates the alternate address to either a first address or a second address. Preferably, the alternate address comprises the second domain, and the map correlates the alternate address to the first address.

The present invention provides a method and system for facilitating instant messaging (IM) between a first user having an address comprising a first domain name and a second user having an address comprising a second domain name different from the first domain name. provides The alternate address is selected to include the second domain name, and the alternate address is mapped to the first address. The IM sent from the first user to the second user is copied and re-addressed to be sent from the alternate address. This maintains domain name consistency between sender (sender) and receiver, allowing messages to be delivered by existing IM systems that prevent IM between incompatible IMSPs.

BRIEF DESCRIPTION OF THE DRAWINGS The foregoing and other aspects of the invention will become more apparent from the following detailed description of preferred embodiments when read in conjunction with the accompanying drawings.

1 is a conceptual schematic diagram of prior art IM systems in which each IMSP (Wireless Village, AOL, etc.) is isolated from other IMSPs.

Figure 2 is a conceptual schematic diagram of an IM system according to the present invention, wherein an IMSP that does not block IM between users in different domains can facilitate IM through other IMSPs.

3 is a block diagram in which a first user of a first IMSP communicates with a second user of a second IMSP by IM.

4 is a flowchart schematically illustrating steps for two-way instant messaging according to an embodiment of the present invention.

BRIEF DESCRIPTION OF THE DRAWINGS The present invention will be best understood with reference to the related drawings. 1 is a simplified block diagram illustrating the limitations of prior art instant messaging (IM) systems. Figure 1 depicts four widely used instant messaging service providers (IMSPs): Wireless Village (WV), America Online (AOL), Microsoft Networks (MSN) and ICQ. Each of these IMSPs facilitates IM between their customers or users, but prevents those same users from IM talking with users of other IMSPs. In fact, each IMSP only provides IM between the users it belongs to.

Figure 2 depicts a simplified block diagram in which the constraints of Figure 1 are overcome for users of Wireless Village. Employing a preferred embodiment of the present invention, WV will enable its users to chat IM with users of any other IMSP, of which only 3 companies are shown. 2 is an example, the present invention is not necessarily limited to directly contacting servers of heterogeneous IMSPs for each IM communication situation. Throughout this disclosure and the appended claims, servers and clients related to a particular IMSP are considered to be covered by that particular IMSP. For example, WV includes not only WV servers, but also every WV client residing on WV users' computers.

3 is a block diagram showing how IM communication is facilitated between two users of heterogeneous IMSPs. A sender (12, depicted as a mobile terminal) inputs a message directed to a receiver (14, depicted as another mobile terminal). The sender and/or receiver may alternatively use a computer terminal or any other device on which the IMSP client resides. For example, the sender is an IM address<u>mitri@wv.com</u>will be designated as Mitri using <u>srini@icq.com</u>will be designated as Srini using . According to their IM domains, Mitri's IMSP (16) is Wireless Village and Srini's IMSP (18) is ICQ. In accordance with one aspect of the present invention, Mitri's IMSP 16 creates a pool of IM addresses. Note that in this case, if accounts are maintained by ICQ, the IMSP that does not maintain accounts is WV. That is, accounts are maintained by ICQ and stored on the ICQ server (in this case) and the WV server behaves like any ICQ user.

The pool of IM addresses (ie, the IM address pool) need not be fixed and may change over time. Preferably, the creation of the IM address pool is done prior to the time Mitri sends the message to Srini, so that the IMSP implementing the present invention is a pool of IM addresses in several domains, each domain matching one of a number of other IMSPs. keep them Alternatively, when Mitri attempts to initiate an IM with a user of an external IMSP, such as Srini, Mitri's IMSP may generate an address that matches Srini's IMSP's IM system.

Mitri's IMSP sends a message to an external IMSP, for example, <u>mitri@wv.com</u>; reception<u>srini@icq.com</u>When detecting a message from ", Mitri's IMSP accesses the pool of addresses in Srini's IMSP's domain (or creates a new address within that domain) and assigns one of them (address) to an ongoing IM session initiated by Mitri. For example, an address from the pool reserved for this IM session is <u>substitute@icq.com</u>will be designated as In addition, Mitri's IMSP is Mitri's address<u>mitri@wv.com</u>map to a reserved address from the pool and store this mapping data. Since the recipient IMSP will only send IM messages when the addresses of both the sender and the recipient come from their own domain, Mitri's IMSP will forward the message from Mitri to Srini to an account belonging to the domain to be processed by Srini's IMSP. copy to Note that whether the IM (from Mitri to Srini) is copied to the IM (from the substitute to Srini) is an implementation detail. IMs can be copied and the sender address can be changed without explicitly copying the message. However, from Mitri&gt;Srini, the message needs to be copied because of the packaging and unpackaging of the entire IM message.

Specifically, Mitri's IMSP accesses the mapped data and verifies that mitri@wv.com is mapped to substitute@icq.com. Mitri's IMSP copies the text of the message into the IM message at the reserved address. Copied messages are now "Sent"<u>substitute@icq.com</u>; reception<u>Srini@icq.com</u>A copied message with an address within the recipient's domain is sent over the Internet, the World Wide Web, or other electronic network. The recipient's IMSP recognizes this network traffic as IM between its own users and that message <u>srini@icq.com</u>It is assumed that Mitri is writing to , and sends it.

address <u>substitute@icq.com</u>It is important to note that sending Mitri's copied message from the recipient's IMSP makes it difficult to discern the message from the point of view of the recipient's IMSP, due to IM traffic between any regular users of the recipient's IMSP. The message is difficult to discern because the packaging of the message is performed by the same client-software as the recipient IMSP.

The actual graphical screen interface Srini sees may or may not indicate that Mitri is the sender. Preferably the interface indicates the sender to further facilitate communication between the end users, Mitri and Srini in this example. However, copying a message allows the server to append/append a string indicating the origin of the message (eg username/friend name). These are the features that an originating (sending) IMSP can provide. In order to preserve the privacy of Mitri, the true sender, from all but Srini, once the IM session between Mitri and Srini is complete,<u>substitute@icq.com</u>class <u>mitri@wv.com</u>The mapping of is preferably deleted and the replacement address is returned to the pool or deleted (i.e., deleted). <u>mitri@wv.com</u> or <u>srini@icq.com</u>no longer related to). Completion is usually signaled by at least one of the end users logging off the client.

There are a number of ways in which return communicatons from Srini to Mitri can be achieved. In the example below, User 1 is the sender of the original message that initiates an IM between the parties using IMSP1. IMSP1 is the domain "<u>abc.com</u>identified as " and does not prevent transmission between domains. User 2 is the intended recipient of the original message and uses IMSP2. IMSP2 is the domain "<u>xyz.com</u>"Identified by domain"<u>abc.com</u>"class "<u>xyz.com</u>" in the above example using Mitri and Srini <u>wv.com</u> and <u>icq</u><u>.com</u>It represents heterogeneous domains similar to

Figure 4 shows in block diagram an architecture enabling the present invention. As described above, IMSP1 creates and maintains a pool of addresses in the domain recognizable by IMSP2 at block 22 . For example, IMSP2<u>@xyz.com</u>To facilitate IM between users with domain names of <u>@xyz.com</u>It will create a pool of identifiers ending in . In block 24, IMSP1 for example "Send<u>user1@abc.com</u>; reception<u>user2@xyz.com</u>Receive the original message destined for ". <u>xyz.com</u>Recognizing that this is an external domain, in block 26, IMSP1 <u>xyz.com</u> Select and reserve an address from the domain's address pool. IMSP1 then sets the reserved address and the addresses of the initial message in block 28,<u>user1@abc.com</u>this <u>substitute@xyz.com</u>mapped to <u>substitute@xyz.com</u>this <u>user2@xyz.com</u>Map and save to be mapped to . This mapped data may be bi-directional. in other words,<u>user1@abc.com</u>silver <u>substitute@xyz.com</u>mapped to <u>substitute@xyz.com</u>silver <u>user1@abc.com</u>can be mapped to Once the mapping data is stored, at block 30 it is accessed by IMSP1. Then, in block 32, IMSP1 copies the text of the original message sent in block 24, and now<u>substitute@xyz.com</u>; reception<u>user2@xyz.com</u>Sends the copied message over the network addressed to ". IMSP1 can reformat the original message to copy the text of the original message. By IMSP1 but sent over IMSP2 in the network In block 34 IMSP2 receives this message and <u>user2@xyz.com</u>, and this will cause any other IM traffic between the two of those users.

When the message is received, User 2 says "Send <u>user2@xyz.com</u>; reception<u>substitute@xyz.com</u>Sends an original reply addressed to ". This message is received by IMSP2 at block 36, and at block 38 IMSP2 sends this reply to <u>substitute@xyz.com</u>send to Continuing from the time of the mapping done in block 38, IMSP1<u>substitute@xyz.com</u>It monitors the network traffic addressed to this sender or receiver, and at block 40 determines if the original reply was sent to that address. IMSP1 intercepts the message and accesses the stored mapping data. In block 42, the IMSP1 replaces the address of the reply with the recipient using the mapping data. After that, IMSP1 returns the text of the original reply as "Send<u>user2@xyz.com</u>; reception<u>user1@abc.com</u>Copies to the message addressed to ", and the copied reply at block 44 <u>user1@abc.com</u>send to It should be noted that this copied reply does not maintain matching domain names between sender and receiver. As mentioned above, an IMSP implementing the present invention will not prevent the forwarding of IM messages with heterogeneous domains. It is believed that most popular IMSPs prevent IM between heterogeneous domains for business reasons rather than technical reasons.

IMSP1 then sends an additional message "Send" in block 46. <u>user1@abc.com</u>; reception<u>user2@xyz.com</u>IMSP1 will then access the map again as in block 30 and continue copying the message text and substituting addresses as before, enabling IM between user 1 and user 2 as long as these two users are logged on. Once the communication between User 1 and User 2 is terminated, the reserved address <u>substitute@xyz.com</u>is returned to the address pool for future use, or <u>user1@abc.com</u>or <u>user2@xyz.com</u>Deleted if not necessarily related to (implementation-dependent). This minimizes the required size of the address pool.

It is typically not the domain names themselves, but rather between each IM provider that does not allow communication between the two different IMSPs, that IMSP1 constrains the transmission of messages or forwards messages between the two other IMSPs. Note that packaging and unpackaging of other IM messages is proprietary information. That is, they are not domain names, but incompatibilities between IMSPs that affect the ability to send and receive IMs.

Although described with respect to presently preferred embodiments, it will be understood by those skilled in the art that various modifications and substitutions of the above-described embodiments can be made and that all such modifications and substitutions are within the scope of this invention. . It should be noted that the examples herein are illustrative and not exhaustive.