I IIIII IIIIIIII II llllll lllll lllll lllll lllll lllll lllll lllll lllll lllll lllll 111111111111111111
`US 20030018726Al
`
`(19) United States
`(12) Patent Application Publication
`Low et al.
`
`(10) Pub. No.: US 2003/0018726 Al
`Jan. 23, 2003
`(43) Pub. Date:
`
`(54)
`
`INSTANT MESSAGING
`
`Publication Classification
`
`(76)
`
`Inventors: Sydney Gordon Low, Kew (AU);
`Geoffrey Michael Wilson, Wantirna
`(AU)
`
`Correspondence Address:
`KNOBBE MARTENS OLSON & BEAR LLP
`2040 MAIN STREET
`FOURTEENTH FLOOR
`IRVINE, CA 92614 (US)
`
`(21) Appl. No.:
`
`10/136,022
`
`(22) Filed:
`
`Apr. 29, 2002
`
`(30)
`
`Foreign Application Priority Data
`
`Apr. 27, 2001
`
`(AU) ........................................ PR4599/01
`
`Int. Cl.7 ..................................................... G06F 15/16
`(51)
`(52) U.S. Cl. ........................... 709/206; 709/224; 709/207
`
`(57)
`
`ABSTRACT
`
`An instant messaging process executed in a communications
`network, including: receiving message data according to an
`IM or wireless device messaging protocols; maintaining
`state data for a user on the basis of the message data;
`determining a destination one of the protocols on the basis
`of the state data; and sending the message data according to
`the destination protocol. The state data includes presence
`data and protocol data for buddys of the user. The process is
`executed by an IM gateway of an Internet Service Provider
`that provides a WAP and SMS portal for mobile telephones
`in addition to multiple IM protocol support.
`
`10
`
`32
`
`30
`
`---'---,
`1 @Q\J"000¢'000CCO~!,
`l~ i i l
`I
`I:;~~
`I=~ -=
`
`:E~~
`I 1::::::::::::::,1 I
`-:;r---
`I
`-· I
`4
`
`;-2
`r- _j_
`I
`t-C::=J
`I
`
`6
`
`8
`
`-0 I
`
`I 16
`L~ - -
`
`I
`I
`
`_.J
`
`34
`
`Page 1 of 16
`
`Samsung Exhibit 1010
`
`

`

`Patent Application Publication
`
`Jan. 23, 2003 Sheet 1 of 7
`
`US 2003/0018726 Al
`
`32
`
`34
`
`---'t.--,
`1 f:i0'1"<><>0¢'<><lOcco;:il
`l~ i .& I
`I @ornooomoooj
`I
`I •··········&M
`!~~~~
`I l"'""''""""""'I I
`I
`I
`-:;r---
`4
`
`:aiH1oooo><>eoo~:
`
`r __ j_-1 2
`
`I
`
`t-C:=J
`s
`
`I 1-0
`
`I 16
`L~ - - - . J
`
`.FIG. 1
`
`Page 2 of 16
`
`

`

`Patent Application Publication
`
`Jan. 23, 2003 Sheet 2 of 7
`
`US 2003/0018726 Al
`
`start
`
`wait for packet
`90
`
`forward packet
`94
`
`no---<
`
`yes
`
`redirect packet to
`server
`96
`
`FIG.2
`
`Page 3 of 16
`
`

`

`Patent Application Publication
`
`Jan. 23, 2003 Sheet 3 of 7
`
`US 2003/0018726 Al
`
`FIG. 3
`
`start
`
`wait for packet
`100
`
`return from
`command
`procedure
`
`forward packet
`to switch
`104
`
`no
`
`yes
`
`yes
`
`no
`
`decrypt IM packet
`108
`
`no
`
`determine client
`IM protocol
`110
`
`determine IM
`command
`112
`
`yes
`
`branch to
`command
`procedure
`
`Page 4 of 16
`
`

`

`Patent Application Publication
`
`Jan. 23, 2003 Sheet 4 of 7
`
`US 2003/0018726 Al
`
`FIG. 4
`
`state
`command
`
`packet
`114
`
`l forward original
`l 116
`
`!update state table :
`
`1ser with this user t - - - - - - - (cid:173)
`in their buddy list
`
`r for each online
`
`create state
`change packet in
`the buddy user's
`protocol
`118
`
`send state packet
`to buddy's client
`120
`
`l next protocol
`
`return to step
`100
`
`Page 5 of 16
`
`

`

`Patent Application Publication
`
`Jan. 23, 2003 Sheet 5 of 7
`
`US 2003/0018726 Al
`
`contact list
`command
`
`FIGS
`
`determine nan-native
`contacts in packet
`122
`
`for each non(cid:173)
`native contact
`
`add contact to table
`entry for sender
`124
`
`create status
`packet far this
`contact in the
`sender's protocol
`126
`
`send packet to
`sender
`128
`
`next contact
`
`yes
`
`remove nan-native
`contacts from
`original packet
`132
`
`forward packet
`134
`
`no
`
`Page 6 of 16
`
`

`

`Patent Application Publication
`
`Jan. 23, 2003 Sheet 6 of 7
`
`US 2003/0018726 Al
`
`FIG. b
`
`message
`packet
`
`determine
`addressee
`136
`
`no
`
`lookup addressee
`data
`140
`
`translate packet
`into addressees
`protocol
`142
`
`yes
`
`yes
`
`encrypt packet
`146
`
`no
`
`send packet to
`destination
`148
`
`Page 7 of 16
`
`

`

`Patent Application Publication
`
`Jan. 23, 2003 Sheet 7 of 7
`
`US 2003/0018726 Al
`
`FIG. 7
`
`FIG. 8
`
`Select IM function
`
`Online
`
`List Se:tup
`
`Chat
`
`Options
`
`Logo ff
`
`Cancel
`
`OK
`
`/
`IM user search by: ['f J(" /
`nickname
`
`800
`
`name
`
`email
`
`ICQ#
`
`Cancel
`
`OK-
`
`FIG. 9
`
`~900
`
`Online
`
`rah
`
`elmo
`nos
`
`syd
`
`miro
`Cancel
`
`(AIM)
`
`(Yahoo)
`
`(WML)
`
`(SMS)
`
`(WAP)
`
`OK
`
`,!.
`
`Page 8 of 16
`
`

`

`US 2003/0018726 Al
`
`Jan.23,2003
`
`1
`
`INSTANT MESSAGING
`
`BACKGROUND OF THE INVENTION
`
`[0001] 1. Field of the Invention
`
`[0002] The present invention relates to instant messaging
`on communications networks.
`
`[0003] 2. Description of the Related Technology
`
`[0004]
`Instant messaging (IM) allows individuals to moni(cid:173)
`tor the presence of their friends and colleagues on an IM
`system of the Internet, and to exchange messages and files
`with those friends and colleagues. To use IM, a user of the
`Internet executes an IM client on their computer system. The
`client allows the user to specify a personal identifier, often
`referred to as a screen name or nickname, by which the user
`is known to the IM system. The IM client also allows the
`user to specify a list of known identifiers for other users of
`the IM system, often known as a buddy list. When the IM
`client begins execution, it sends a message to an IM server
`on the Internet, informing it of the user's availability, or
`presence, for IM purposes, and querying the IM server as to
`whether the users in the buddy list are also present, that is,
`whether they are connected to the Internet, have a compat(cid:173)
`ible IM client executing on their computer, and have des(cid:173)
`ignated themselves as present to the IM client. The IM server
`maintains a list of registered identifiers for the users of the
`IM system. When it receives the login and buddy list
`messages from the user's client, the IM server flags the
`user's identifier as being in a present state, and looks up the
`buddy list nicknames to determine whether they are also in
`a present state. The server returns a response to the user's IM
`client, indicating which members of the buddy list are
`present. On the basis of this information, the user's IM client
`provides a visual indication of the presence of individual
`members of the user's buddy list. The user may exchange
`quasi real-time, 'instant' messages with other users who are
`present on the IM system.
`
`[0005] One of the problems with IM is that there are
`actually several independent IM systems, each using a
`different protocol and set of servers, and effectively defining
`a virtual IM network for that particular protocol. For
`example, AOL Instant Messenger (AIM), Yahoo! Messen(cid:173)
`ger, MSN Messenger, and ICQ are some of the better known
`IM systems. These systems are not compatible to the extent
`that, for example, an AIM client can only communicate with
`clients using an AIM protocol. Thus a user may need to use
`several different IM clients simultaneously in order to keep
`in touch with all of their friends. It is desired, therefore, to
`provide a method and system for alleviating the above, or at
`least provide a useful alternative.
`
`SUMMARY OF CERTAIN INVENTIVE
`ASPECTS
`
`[0006]
`In accordance with one aspect of the present inven(cid:173)
`tion there is provided an instant messaging (IM) process
`executed by a gateway in a communications network,
`including: sending first IM traffic from IM clients to respec(cid:173)
`tive IM servers of the clients; and sending second IM traffic
`from an IM client using one protocol to an IM client using
`a different protocol.
`
`[0007] Another aspect of the present invention also pro(cid:173)
`vides a process for instant messaging (IM) in a communi-
`
`cations network, including: rece1vmg IM traffic from IM
`clients using different IM protocols; and compiling data on
`the state of said IM clients.
`
`[0008] Yet another aspect of the present invention also
`provides an instant messaging process, including: receiving
`a message indicating whether a device is connected to a
`wireless network; and maintaining instant messaging state
`information for said device in response to said message.
`
`[0009] One other aspect of the present invention also
`provides instant messaging (IM) process including: receiv(cid:173)
`ing IM traffic from a first IM client using a first IM protocol;
`and sending said IM traffic to a second IM client using a
`second IM protocol.
`
`[0010] Another aspect of the present invention also pro(cid:173)
`vides a process for instant messaging, including: receiving
`instant messaging data in a first one of a plurality of instant
`messaging protocols; and translating said data in accordance
`with a second one of said plurality of instant messaging
`protocols.
`
`[0011] Yet another aspect of the present invention also
`provides an instant messaging process, including: receiving
`instant messaging data in a first instant messaging protocol,
`said data identifying at least one instant messaging user; for
`each of said at least one user, identifying an instant mes(cid:173)
`saging protocol, and removing data for said user if said
`protocol differs from said first instant messaging protocol;
`and forwarding the remaining instant messaging data.
`
`[0012] One other aspect of the present invention also
`provides an instant messaging process, including: receiving
`instant messaging data in a first instant messaging protocol,
`said data including an identifier of a destination instant
`messaging user; determining a destination instant messaging
`protocol based on said identifier; translating said instant
`messaging data in accordance with said destination instant
`messaging protocol; and sending said translated instant
`messaging data to said user.
`
`[0013] Another aspect of the present invention also pro(cid:173)
`vides an instant messaging process, including maintaining a
`list of instant messaging users and corresponding instant
`messaging protocols.
`
`[0014] Yet another aspect of the present invention also
`provides a process for instant messaging using a wireless
`device, including: receiving messaging data from a wireless
`device; translating said messaging data into a destination
`instant messaging protocol; and forwarding said instant
`messaging data to an instant messaging application corre(cid:173)
`sponding to said destination instant messaging protocol.
`
`[0015] One other aspect of the present invention also
`provides a process for instant messaging in a communica(cid:173)
`tions network, including: receiving a packet of data in said
`network, said packet having a destination address; translat(cid:173)
`ing instant messaging data in said packet from a first instant
`messaging protocol to a second instant messaging protocol;
`and forwarding said translated data to said destination
`address.
`
`[0016] Another aspect of the present invention also pro(cid:173)
`vides a process for instant messaging in a communications
`network, including: identifying data on said network as
`comprising instant messaging data; redirecting said data to
`an instant messaging translation server; translating said data
`
`Page 9 of 16
`
`

`

`US 2003/0018726 Al
`
`Jan.23,2003
`
`2
`
`from a first instant messaging protocol to a second instant
`messaging protocol; and forwarding said translated data to
`an instant messaging application corresponding to said sec(cid:173)
`ond instant messaging protocol.
`
`[0017] Yet another aspect of the present invention also
`provides an instant messaging process executed in a com(cid:173)
`munications network, receiving message data according to
`one of a plurality of IM or wireless device messaging
`protocols; maintaining state data for a user on the basis of
`said message data; determining a destination one of said
`protocols on the basis of said state data; sending said
`message data according to said destination protocol.
`
`[0018] One other aspect of the present invention also
`provides an instant messaging system or software code for
`executing any one of the above processes.
`
`BRIEF DESCRIPTION OF THE DRAWINGS
`
`[0019] A preferred embodiment of the present invention is
`hereinafter described, by way of example only, with refer(cid:173)
`ence to the accompanying drawings, wherein:
`[0020] FIG. 1 is a diagram of a preferred embodiment of
`an IM gateway within a network access system;
`[0021] FIG. 2 is a flow diagram showing a packet switch(cid:173)
`ing process executed by the gateway;
`[0022] FIG. 3 is a flow diagram showing an IM gateway
`process executed by the gateway;
`[0023] FIG. 4 is a flow diagram showing an IM state
`change process executed by the gateway;
`[0024] FIG. 5 is a flow diagram showing an IM contact
`list process executed by the gateway;
`[0025] FIG. 6 is a flow diagram showing an IM message
`translation process executed by the gateway; and
`
`[0026] FIGS. 7 to 9 are illustrations of an instant messag(cid:173)
`ing interface on the screen of a wireless device.
`
`DETAILED DESCRIPTION OF CERTAIN
`INVENTIVE EMBODIMENTS
`
`[0027] An instant messaging (IM) gateway 2, as shown in
`FIG. 1, includes a network packet switch 6, a server 16, and
`a database 18. The packet switch 6 may be an Ethernet
`packet switch such as the Alteon ACEdirector® Ethernet
`web switch from Norton Networks Limited, providing
`packet switching at network layers 2, 3 and 4-7. The server
`16 may be a standard computer such as an Intel®-based
`personal computer, but is preferably a high-performance
`network server such as a Sun Enterprise® 10000 from Sun
`Microsystems®). The database 18 is preferably a structured
`query language (SQL) database such as an Oracle® or
`MySQL database. The IM gateway 2 is connected to a
`communications network 14 such as the Internet, and is
`connected between IM clients and IM servers 20 to 26 on the
`network 14. Moreover, the IM gateway 2 may advanta(cid:173)
`geously be part of a network access system operated by an
`Internet Service Provider (ISP), as shown in FIG. 1. The
`network access system may also include a random access
`server (RAS) 4, and a router 8 for interfacing to a fiber
`optical connection to the network backbone. The access
`system may be as described in the specification of Interna(cid:173)
`tional Patent Application No. PCT/AU00/00418.
`
`[0028] Network packets flowing between users dialed into
`the ISP access system and the network 14 pass through the
`gateway 2. However, the switch 6 redirects network packets
`containing IM data in any of the IM protocols known to the
`server 16, which may be all known IM protocols. The server
`16 executes an IM gateway process that records the state or
`presence of IM users using any of the known IM protocols.
`The IM gateway process may further translate IM data in
`any one of the known IM protocols into any one of the other
`of the known IM protocols, allowing IM users using one IM
`system to communicate with IM users using another IM
`system, without requiring the users to use special clients that
`are able to handle all of the known protocols. Data translated
`by the server 16 is sent back to the switch 6, which then
`forwards it to the appropriate destination. For example, an
`IM message sent from the computer 10 of a user dialed in to
`the ISP's access system will be redirected by the switch 6 to
`the server 16. The server 16 processes the message, and
`sends it back to the switch 6, where it may be forwarded to
`the network 14, such as to another user's computer 34, or
`one of several IM servers 20 to 26.
`[0029] The IM gateway 2 processes the IM packets
`received from different IM clients in order to allow them to
`communicate with one another, notwithstanding the fact that
`they use a different IM protocol. For this to occur, the
`gateway 2 acts as an IM server between "non-native" IM
`clients, ie clients who use a different IM protocol. For
`example, when a user of the AIM client wishes to commu(cid:173)
`nicate with a user of the I CQ client, this IM traffic is handled
`by the gateway 2 without messages being sent back to the
`native AIM server or the native ICQ server of the respective
`clients. Messaging traffic between users of the AIM client is
`sent unaltered by the gateway 2 to a native AIM server, and
`this is the same for IM traffic between users of the same IM
`client in that the messaging traffic is passed back to the
`native servers or clients unaltered. Accordingly the gateway
`2 can operate such that the native IM servers, eg the AIM
`and Yahoo servers, are not aware of the presence of the
`gateway 2. The gateway 2 processes the IM packets it
`receives from the clients 10, 34 so as to maintain tables on
`the state of the clients and lists of IM users (ie contacts such
`as "buddys") for each client or user. Placing the gateway 2
`in the network path, between an IM client and an IM server
`or another client, allows it to maintain information of the
`presence of IM users with different IM clients.
`[0030] The IM gateway 2 thus allows a user connected to
`the gateway 2 to communicate with other users using known
`IM protocols, even though the users may be using incom(cid:173)
`patible IM clients with different IM protocols. Moreover, the
`gateway 2 supports its own IM system for users of wireless
`devices such as mobile telephones and personal data assis(cid:173)
`tants (PDAs). This allows IM users to become part of a
`virtual, protocol-independent IM network.
`It will be appreciated by the skilled addressee that
`[0031]
`the processes executed by the IN gateway 2 could be
`executed in a distributed manner by any number of devices,
`and that at least part of the processes could be executed by
`hardware circuits such as application-specific application
`circuits (ASICs). The description below, however, describes
`processes that are executed by software code stored on the
`gateway 2.
`[0032] The server 16 executes a mobile instant messaging
`process with hypertext markup language (HTML), wireless
`
`Page 10 of 16
`
`

`

`US 2003/0018726 Al
`
`Jan.23,2003
`
`3
`
`markup language (WML), and short message service (SMS)
`interfaces, thus providing access to instant messaging ser(cid:173)
`vices to users without requiring an IM client to be installed
`on the user's computing device. In particular, the WML and
`SMS
`interfaces support mobile wireless clients. For
`example, a WML deck may be served to a WAP client such
`as a WAP browser executing on a mobile device 32 such as
`a telephone by a web server process that may also execute
`on the server 16. This allows a user of the mobile telephone
`32 to join the protocol-independent virtual IM network, and
`to exchange messages with other IM users, irrespective of
`which particular IM client or IM protocol they are using. The
`gateway 2 therefore acts as a WAP gateway and a SMS
`portal.
`
`[0033] The gateway 2 receives state information from
`equipment 31 of a mobile communications network 30,
`indicating whether the device 32 is connected to the mobile
`network 30. This allows the gateway 2 to store IM state
`information indicating whether the device 32 is available for
`receiving IM messages, even if the user of the device has not
`logged into the IM system using the mobile instant messag(cid:173)
`ing process. For example, if the device 32 is turned on and
`connected to the network 30, an IM user may request a chat
`session with the user of the device 32. In response, the
`gateway 2 sends the request to the device 32. If the device
`32 is not logged into the IM system, the request is sent as an
`SMS message. Similarly, instant messages directed to the
`device 32 may be sent as SMS messages. If the user replies
`to the SMS message, the reply is sent back as an instant
`message to the user that sent the original instant message,
`via the gateway 2. However, in order to enter an interactive
`chat session, the user of the device 32 logs into the WAP
`gateway 2. When the device 32 is disconnected from the
`network 30, the wireless network equipment 31 informs the
`gateway 2. Presence messages may be sent to other IM users
`when the mobile device is connected and disconnected. This
`provides a transparent IM system for users of mobile
`devices, and does not require them to login to an IM system
`in order to receive IM alerts and messages and reply to
`instant messages.
`
`In practice the IM data held by the gateway 2 may
`[0034]
`be sent to a master IM gateway 2 of a number of IM
`gateways 2 of the network 14 that are arranged in a hierar(cid:173)
`chical structure so as maintain a complete list of the IM data,
`particularly the presence data, for all IM users. Another
`alternative is to pass the IM data between the gateways 2 on
`a peer to peer basis. The mobile IM process and the WAP
`and SMS functionality may be executed only on the master
`gateway that acts as a WAP and SMS gateway or portal that
`connects to one or more network equipment 31 and to the IM
`gateways 2
`
`[0035] A user may connect to the Internet 14 by dialing
`into the access system of FIG. 1 through the public switched
`telephone network (PSTN) 12 using a computer 10 with a
`built-in modem. An IM client may then be executed on the
`user's computer 10 in order to monitor the availability, or
`presence, of other users listed in the IM client's buddy list,
`and to exchange messages with those users, if present. The
`IM client may be any one of a number of known IM clients,
`including AOL Instant Messenger (AIM), Yahoo! Messen(cid:173)
`ger, MSN Messenger, ICQ, Bantu, Jabber, Everybuddy and
`Pow Wow. The protocols used by these clients are docu(cid:173)
`mented on the Internet at a number of locations, including
`
`http://www.cs.berkeley.edu/-mikechen/im/protocols, http://
`cvsweb.jabber.org, and http://www.zigamorph.net/faim/pro(cid:173)
`tocol.
`
`IM services provide centralised servers for main(cid:173)
`[0036]
`tammg a list of registered users and their states. For
`example, the network of FIG. 1 includes four IM servers 20
`to 26. When the user first starts an IM client executing on the
`computer 10, the client sends a login message directed to a
`corresponding IM server on the Internet 14 in order to signal
`the presence of the user on the corresponding IM network.
`For example, if the IM client is AIM, the AIM client sends
`a login command message in an AIM protocol, for example,
`the OSCAR protocol, directed to an AIM authentication
`server 20 to login to AIM and thereby record the user's
`presence on the virtual AIM network. The OSCAR protocol
`data is sent in a TCP packet from the user's computer 10
`directed to the AIM server 20. However, because network
`packets sent from the computer 10 to the server 20 pass
`through the gateway 2, these packets are first received at an
`input port of the switch 6. The switch 6 executes a packet
`switching process on this port, as shown in FIG. 2. The
`switch waits for a data packet on the port at step 90. When
`a packet is received, the switch 6 inspects the packet header
`at step 92 to determine whether it is directed to either (a) a
`known IM port number, or (b) an IP address known to the
`switch as being assigned to one of the IM servers 20 to 26.
`If no match is found, then the packet is simply forwarded
`through the switch 6 to the Internet at step 94. Otherwise, the
`switch 6 redirects the data packets to the IM server 16 at step
`96. For example, if the switch 6 determines that the desti(cid:173)
`nation address in the packet header matches the IP address
`of the AIM server 20, then the switch 6 redirects the packet
`to a port of the server 16. This port is monitored by an IM
`gateway process, as shown in FIG. 2.
`
`[0037] The IM gateway process shown in FIG. 2 is a
`simplified process. Unfortunately, there are significant dif(cid:173)
`ferences between the different IM protocols which necessi(cid:173)
`tate different handling procedures. For example, the AIM
`client maintains a TCP connection to the authentication
`server 20, whereas other protocols may send UDP packets,
`or a combination of UDP and TCP packets. The gateway 2
`terminates a TCP connection from an IM client and opens a
`corresponding TCP connection to the intended destination.
`The client and the server are unaware that their TCP con(cid:173)
`nection actually terminates at the server 16. Furthermore,
`AIM's OSCAR protocol may send multiple IM commands
`in a single TCP packet, or one IM command split over
`multiple TCP packets. Furthermore, AIM uses separate
`servers for IM services in addition to the authorisation
`server, including a BOS (basic OSCAR services) server, a
`chat server, an advertising server, and so on. The simplified
`flow diagrams also do not show low level details such as
`packet transmission loops, acknowledgement packets, and
`KEEP_ALIVE packets which may be sent to maintain IM
`sessions. For clarity, such details, known to the skilled
`addressee have been omitted.
`
`[0038] The IM gateway process listens on the IM gateway
`port of the server 16 at step 100. When a redirected packet
`arrives from the switch 6, it is checked at step 102 to ensure
`that it contains data in one of the known IM protocols. If not,
`then it is forwarded to a port of the switch at step 104.
`Otherwise, the packet is checked to determine whether the
`packet is encrypted at step 106. IM packets may or may not
`
`Page 11 of 16
`
`

`

`US 2003/0018726 Al
`
`Jan.23,2003
`
`4
`
`be encrypted, depending upon which IM protocol is used
`and also the source and destination of the packet. For
`example, on the ICQ network, packets sent from an ICQ
`client to an ICQ server are encrypted, but packets send from
`the server back to the client are not encrypted. Packets sent
`from an ICQ client to another ICQ client are also encrypted.
`If the received packet is encrypted, it is decrypted at step
`108. The packets are analysed at step 110 to determine the
`IM protocol of the packet. Once the IM protocol of the
`packet is known, the IM command can be determined at step
`112. For example, the first packet sent by the IM client will
`be a login packet. If the command is a command that is not
`handled by the gateway 2 (step 113), then the original packet
`is forwarded back to the switch 6 at step 104. Otherwise, the
`process branches to a subprocess for that command.
`
`IM clients send a number of commands that change
`[0039]
`the user's state or presence on the IM network. These
`include the commands which initiate the user's login to and
`logout from the IM network, and commands which are sent
`to indicate that the user is away, idle, or does not wish to be
`disturbed. These commands are handled by an IM state
`change process, as shown in FIG. 4. The gateway 2 main(cid:173)
`tains state tables on the database 18 which includes entries
`for each IM user connected to an IM network through the
`gateway 2. As shown in Table 1 below, the database 18
`includes a state table for each user of the gateway 2,
`including the user's screen name, IM protocol, presence
`state, IP address or mobile telephone number, and a permit/
`deny mode. The permit/deny mode is used for blocking or
`permitting messages from other IM users: a value of 1
`indicates that the user is permitting all contacts to send
`instant messages and "see" the user, a value of 2 indicates
`that the user is denying all contacts, a value of 3 indicates
`that only contacts in a permit list are permitted to send
`messages, and a value of 4 indicates that only contacts in a
`deny list are prohibited from sending messages. These
`entries are created by the gateway when the user sends state
`change commands to their native IM system; for example,
`when a user logs in to their IM system, or changes their state
`from available to unavailable, and so on. The state table that
`the gateway 2 maintains is particularly advantageous as it
`provides an indication of the presence of all of the IM users,
`e.g., whether an IM user is available or not.
`
`TABLE 1
`
`screen name protocol state
`
`IP address/mobile # mode
`
`urn
`
`0123456
`0123457
`0123458
`8745682
`1093278
`
`rab
`fink
`elmo
`nos
`syd
`
`online
`AIM
`away
`MSN
`online
`Yahoo
`HTML online
`con-
`GSM
`nected
`online
`offline
`
`128.256.32.2
`128.256.76.81
`128.256.43.22
`128.256.87.24
`+61 0408 967 522
`
`+61 0411 857 937
`
`GSM
`1099803 miro
`8942084
`smithamat MSN
`
`[0040] A contact table, as shown in Table 2, is used to store
`a list of an IM user's contacts, including buddies and
`members of the user's permit list and deny list. The contact
`table is populated when an IM client sends a buddy list, a
`permit list, or a deny list to their native IM server. These
`packets are intercepted by the gateway 2 which analyses
`them and generates table entries based on data in the lists.
`The contact table stores information on 'non-native' contacts
`
`who use an IM protocol different to the protocol used by the
`IM user, because the native IM server ( e.g., an AIM server)
`will maintain data for native IM contacts, i.e., contacts on
`the same IM network as the user. Each IM network identifies
`its users by assigning a unique identifier to each user. As
`described above, this identifier is generally a character string
`known as a screen name or nickname. In order for the
`gateway 2 to identify screen names as designating non(cid:173)
`native IM users, these screen names include an identifier of
`the user's IM network. Unfortunately, AIM screen names are
`restricted to alphabetic and numeric characters and the space
`character. For example, the gateway 2 recognises a screen
`name of "rab AIM" as belonging to an AIM user with the
`AIM screen name "rab". However, AIM clients send screen
`names in a normalised format, in lower case with spaces
`omitted. Hence an AIM command referring to a screen name
`"rabaim" is treated as though it was "rab AIM."
`
`urn
`
`0123456
`0123456
`0123456
`0123456
`0123456
`0123457
`0123458
`0123458
`1093278
`1093278
`
`TABLE 2
`
`buddy name
`
`flags
`
`smithamat MSN
`elmo Yahoo
`syd SMS
`david WAP
`james WEB
`fred Yahoo
`rabAIM
`smithamat MSN
`pete SMS
`rabAIM
`
`b
`bp
`b
`b
`b
`b
`b
`b
`b
`d
`
`[0041] The contact table also includes flags for each
`contact indicating whether the contact is a member of the
`user's buddy, permit, and/or deny lists, indicated by the
`presence or absence of the first letter of each list name, ie b,
`p and d. Members of the deny list may not be able to see or
`send messages to the user, even when the user is otherwise
`visible (as indicated by the user's state, e.g., online). Simi(cid:173)
`larly, members of the permit list may communicate with the
`user when the user is otherwise invisible (e.g., the user's
`state is "away" or DND (do not disturb)). For example,
`Table 1 indicates that the user with the screen name "elmo"
`is using Yahoo!. Messenger at a computer with IP address
`128.256.43.22, is permitting all users, and has a gateway
`user id (UID) of 123458. Table 2 indicates that user 0123458
`("elmo") has two non-native buddies, including "rab" on the
`AIM network, and "smithamat" on the MSN network. The
`user "elmo" is on "rab"'s buddy and permit lists, whereas
`"rab"'s other contacts are only on his buddy list. The user
`1093278 ("syd") has "rab on his deny list. The contact table
`can be maintained a separate tables for the buddy, permit and
`deny lists. The manner in which the permit and/or deny lists
`are used by the gateway 2 for non-native clients may be
`made consistent with the manner in which the lists are used
`by the native servers when communicating with the clients.
`[0042] When the gateway 2 receives a command that will
`change the user's state, the IM state change forwards a copy
`of the packet to the switch 6, which sends it to the appro(cid:173)
`priate IM server at step 114. For example, if the command
`is an AIM sign_ on command to login the user to the AIM
`network, the command is forwarded to the AIM server 20.
`If the login was successful, then the state table is updated at
`step 116 to reflect the user's state as "online" and the IM
`protocol used by the user. Similarly, if the IM command
`
`Page 12 of 16
`
`

`

`US 2003/0018726 Al
`
`Jan.23,2003
`
`5
`
`modifies the user's state to be (un)available, or if the user
`leaves the IM network, then the table is updated at step 116.
`This user may be a member of the buddy lists of other users
`using the gateway 2. The gateway 2 informs these users of
`their buddy's changed status by forming status packets in the
`users' protocols at step 118, and sending them to these users
`at step 120. For example, if the user "elmo" logs out from
`the Yahoo! IM network, an AIM UPDATE_ BUDDY packet
`will be created at step 118 and sent to the user "rab" at step
`120, indicating that buddy "elmo Yahoo" is now offline.
`
`[0043] A user's contact lists are updated by contact com(cid:173)
`mands, and are processed according to a contact list process,
`as shown in FIG. 5. A