US007016978B2
`
`(12) United States Patent
`Malik et al.
`
`(10) Patent N0.:
`(45) Date of Patent:
`
`US 7,016,978 B2
`Mar. 21, 2006
`
`(54) INSTANT MESSAGING ARCHITECTURE
`AND SYSTEM FOR INTEROPERABILITY
`AND PRESENCE MANAGEMENT
`
`(75) Inventors: Dale Malik, Atlanta, GA (US); Matt
`Peterson, Atlanta, GA (US)
`
`(73) Assignee: BellSouth Intellectual Property
`Corporation, Wilmington, DE (US)
`
`( * ) Notice:
`
`Subject to any disclaimer, the term of this
`patent is extended or adjusted under 35
`U.S.C. 154(b) by 720 days.
`
`(21) Appl. N0.: 10/135,929
`
`(22) Filed:
`
`Apr. 29, 2002
`
`(65)
`
`Prior Publication Data
`
`US 2005/0044144 A1
`
`Feb. 24, 2005
`
`(51) Int. Cl.
`(2006.01)
`G06F 15/16
`(52) US. Cl. ..................................... .. 709/246; 709/205
`(58) Field of Classi?cation Search .............. .. 709/204,
`709/206, 217, 230, 246, 205
`See application ?le for complete search history.
`
`(56)
`
`References Cited
`
`U.S. PATENT DOCUMENTS
`
`6,549,937 B1
`6,564,261 B1 *
`6,714,793 B1 *
`6,760,580 B1 *
`
`4/2003 Auerbach et al. ......... .. 709/206
`5/2003 Gudjonsson et al. ..... .. 709/227
`3/2004 Carey et al. .............. .. 455/466
`7/2004 Robinson et al. ...... .. 455/4122
`
`OTHER PUBLICATIONS
`
`M. Day, et al.; A Model for Presence and Instant Messaging;
`Feb. 2000; pp. 1-17.
`M. Day, et al.; Instant Messaging / Presence Protocol
`Requirements; Feb. 2000; pp. 1-26.
`
`* cited by examiner
`Primary Examiner—Rupal Dharia
`Assistant Examiner—Brian J. Gillis
`(74) Attorney, Agent, or Firm—Thomas, Kayden,
`Horstemeyer & Risley LLP
`
`(57)
`
`ABSTRACT
`
`A computer network system establishes an instant messag
`ing (IM) session betWeen a ?rst user registered With a ?rst
`ISP (ISP) and at least one user registered With a second ISP
`When the tWo ISPs operate using different IM protocols. The
`ISPs each contain a Local IM server connected to each
`registered user. Each ISP also contains a Universal IM server
`that is connected to the distributed network. The Universal
`IM server includes a database that stores routing information
`and Presence information for each user registered With the
`second ISPs and facilitates communications betWeen the
`?rst and second user using a universal format, such as XML.
`
`6,430,602 B1 *
`6,449,344 B1 *
`
`8/2002 Kay et al. ................. .. 709/206
`9/2002 Gold?nger et a1. .... .. 379/8817
`
`28 Claims, 6 Drawing Sheets
`
`407
`
`f 410
`
`IM
`CLIENT
`
`420
`
`LOCAL lM
`SERVER
`
`412
`
`USER
`
`CLIENT
`
`{ 400
`
`f 440
`
`442
`
`IM
`CLIENT
`
`A
`
`l
`
`l
`USER
`
`405
`
`/ 43°
`
`435
`\ I
`
`LOCAL lM
`SERVER
`
`f 450
`
`“
`
`UNIVERSAL IM ‘
`SERVER
`
`‘ UNIVERSAL IM
`SERVER
`Update 1
`
`mm Rae
`
`427
`
`|
`
`452
`
`455
`i /
`
`457
`
`lM
`CLIENT
`
`I.
`
`I
`
`I
`
`Facebook's Exhibit No. 1015/1115
`Page 1
`
`

`

`U.S. Patent
`
`Mar. 21, 2006
`
`Sheet 1 6f 6
`
`US 7,016,978 B2
`
`
`
`
`
`_. .QE .55‘ mozkl
`
`o:
`
`o O2 8?
`
`
`
`mm? mo?
`
`ow?
`
`Facebook's Exhibit No. 1015/1115
`Page 2
`
`

`

`U.S. Patent
`
`Mar. 21, 2006
`
`Sheet 2 6f 6
`
`US 7,016,978 B2
`
`
`
`mmN 0mm
`
`
`
`mww 0mm
`
`N .QE
`
`ovm
`
`mNN
`
`mmw
`
`llvmohjwzék
`
`oow
`
`mow
`
`mmm
`
`Z
`
`
`
`hm?‘ MOD?‘
`
`Facebook's Exhibit No. 1015/1115
`Page 3
`
`

`

`U.S. Patent
`
`Mar. 21, 2006
`
`Sheet 3 6f 6
`
`US 7,016,978 B2
`
`(-304
`
`System Memory
`
`(ROM)
`
`308
`310
`BIos
`_ _____________ ___<_/ 306
`(RAM)
`312
`
`302
`
`322
`
`vIDEo
`
`SYSTEM
`
`APPLICATION
`PROGRAMS 316
`
`OUTLINE 318
`FONTS
`
`PROGRAM 320
`DATA
`
`328
`
`330
`
`XX
`f
`
`.
`
`I
`
`Monitor
`
`342
`
`Local Area Network f
`
`334
`
`346
`
`HARD DISK
`DRIVE
`INTERFACE
`
`NETWORK
`INTERFACE
`
`MAGNETIC
`DISK DRIVE
`INTERFACE
`
`3
`'
`
`aqwwa?mé-mgsimm;33.530331 :ww
`
`SERIAL
`PORT
`INTERFACE
`
`wwwzwwew
`
`-I-.*-,'a.'
`
`.3
`
`a» ‘:
`
`,
`
`
`
`
`
`OPTICAL DISK INTERFACE
`
`356
`
`Facebook's Exhibit No. 1015/1115
`Page 4
`
`

`

`US. Patent
`
`Mar. 21, 2006
`
`Sheet 4 0f 6
`
`US 7,016,978 132
`
`oov
`
`~¢¢ovv
`
`mum:
`
`nm¢
`
`Emma
`
`kzmjo
`
`oF¢\\
`
`2_
`
`
`2_4<0042.4(004
`
`mm>mmmmm>mmw
`
`2_——2.
`2.pzmjo
`
`VGE
`
`s__._<wmm>_z:E4<mmm>_z:
`
`
`
`mm>mmmMm>mmm
`
`Nov
`
`mmmD
`
`va
`
`1mm:
`
`Facebook‘s Exhibit NO. 1015/1115
`
`Page 5
`
`Facebook's Exhibit No. 1015/1115
`Page 5
`
`

`

`U.S. Patent
`
`Mar. 21, 2006
`
`Sheet 5 0f 6
`
`US 7,016,978 B2
`
`500
`
`4/
`
`f- 505
`
`NEW USER MAKES REQUEST FOR
`NEW USER ID FROM FIRST LOCAL
`INSTANT MESSAGING SERVER
`
`l
`
`510 /
`
`LOCAL IM SERVER CHECKS NEW
`USER ID WITH UNIVERSAL IM
`SERVER AND MAKES ASSIGNMENT
`
`I
`
`FIRST LOCAL IM SERVER SENDS
`UPDATE TO FIRST UNIVERSAL IM
`SERVER
`
`i
`
`FIRST UNIVERSAL EM SERVER
`SENDS UPDATED INFORMATION
`TO EVERY OTHER UNIVERSAL IM
`SERVER LISTED ON USER'S
`ROSTER
`
`f 515
`
`520 /
`
`FIG. 5
`
`Facebook's Exhibit No. 1015/1115
`Page 6
`
`

`

`U.S. Patent
`
`Mar. 21, 2006
`
`Sheet 6 6f 6
`
`US 7,016,978 B2
`
`iJO @ f
`
`FIRST USER REQUEST IM SESSION
`WITH SECOND USER
`‘
`
`f 610
`
`LOCAL IM SERVER ROUTES REQUEST TO
`FIRST UNIVERSAL IM SERVER FOR
`PROCESSING
`
`NO
`
`615
`
`IS
`THE SECOND
`USER REGISTERED WITH
`THE SECOND
`ISP'?
`
`YES
`
`f 620
`
`LOCATE LOCAL IM SERVER
`ASSOCIATED wITH SECOND
`USER ON FIRST ISP'S NETWORK
`
`ROUTE THE REQUESTTO THE
`SECOuND UNIVERSAL IM SERVER
`FOR PROCESSING AND
`LOCATION OF LOCAL IM SERVER
`
`IS
`THE SECOND
`SER AVAILABLE?
`
`645
`
`NO
`
`ESTABLISH IM SESSION
`BETWEEN FIRST USER AND
`THE SECOND USER
`
`f 647
`
`SEND
`RETURN
`MESSAGE
`QR
`GOTO END
`
`FIG. 6
`
`Facebook's Exhibit No. 1015/1115
`Page 7
`
`

`

`US 7,0l6,978 B2
`
`1
`INSTANT MESSAGING ARCHITECTURE
`AND SYSTEM FOR INTEROPERABILITY
`AND PRESENCE MANAGEMENT
`
`TECHNICAL FIELD
`
`This invention relates generally to instant messaging, and
`more particularly relates to providing an open netWork to
`provide interoperability betWeen multiple platforms operat
`ing under a single instant messaging standard.
`
`10
`
`BACKGROUND
`
`The Internet has changed the Way people communicate.
`For many people, electronic mail, knoWn as “e-mail,” has
`practically replaced traditional letters and in some instances,
`telephone calls, as the primary means of communication.
`Users of the Internet send literally millions of e-mail mes
`sages across the Internet on a daily basis. The popularity of
`being able to send messages anyWhere in the World in a
`matter of minutes, or even seconds, has made e-mail the
`most rapidly accepted form of correspondence to date. The
`use of e-mail has risen from obscurity, used once only by
`academics and the military, to dominant mode of public
`communication in less than tWenty years.
`HoWever, in our fast-paced World Where the desire for
`access to more information at a faster rate increases on a
`daily basis, the once rapid response of e-mail communica
`tions is no longer fast enough to keep pace With society’s
`need. One Way to help people communicate faster Was the
`creation of instant messaging (“IM”) services. IM services
`alloW for nearly real time communications because the users
`sending and receiving messages are continually connected to
`an IM service. The speed at Which recipients get IM mes
`sages is determined by the speed the data can travel across
`the Internet. When a subscriber logs into an IM service, the
`service lets an IM server knoW that the user is available to
`receive messages. To send a message to a recipient, the
`subscriber simply selects the name of the recipient, usually
`from a contact list that contains the recipient’s IM address,
`and types the message.
`The core of IM is based on the concept of “presence
`management,” Which determines Where a user is connected
`to the Internet, the availability of the user, and on What
`system the user resides. Similar to email, a system level
`designation (domain) is the ?rst tier of recogniZing Where to
`reach a particular user. IM, hoWever, requires at least tWo
`additional elements (location and status) that make up the
`core of presence management. The immediate nature of this
`type of communication requires that the eXact IP address of
`the person and their Willingness to accept a message be
`knoWn in order to set up a connection.
`IM Was initially available to only dial up Internet users,
`Which made location speci?c information extremely impor
`tant. In the last couple of years the access of IM services has
`spread across mobile devices, such as cellular telephones,
`personal digital assistants (PDAs), and almost any system
`capable of Internet access. This proliferation has added the
`need to manage other elements of presence that did not eXist
`in the past. With the potential to have multiple devices
`active, such as PC, PDA, cellular telephone, pager, etc., the
`presence system must be able to identify and manage each
`Internet device connected to the Internet and determine to
`Which device messages should be forWarded.
`To accommodate the rapid groWth in IM, each Internet
`Service Provider (ISP) developed their oWn brand of tech
`nology to locate and connect users Within their community.
`
`15
`
`25
`
`35
`
`40
`
`45
`
`55
`
`65
`
`2
`In doing so, each ISP selected different methods for man
`aging presence and setting up communications paths
`betWeen tWo parties. Unfortunately, these methods do not
`alloW users of one system to easily contact and communicate
`With users of other systems. There is a need to enable
`effective intersystem communication and provide a path to
`groW future interoperability Without negatively affecting the
`current separate netWorks in operation.
`Currently, ISPs use one of three methods to transmit
`instant messages betWeen subscribers on their netWork. The
`?rst method uses a centraliZed netWork, in Which subscribers
`are connected to one another through a series of netWork
`servers. The individual servers are linked together to form a
`large, centraliZed netWork. In this architecture, each server
`keeps track of the presence information and connections for
`each user connected to the netWork. When a subscriber
`sends a message, the server determines the location of the
`recipient’s computer by contacting all of the other netWork
`servers and routes the message through the netWork servers
`until it reaches the recipient. This particular method is used
`by Microsoft NetWork (MSN) Messenger IM service.
`A second method of transmitting instant messages uses a
`peer-to-peer architecture favored by systems using ICQ
`protocol (pronounced “I seek you”), such as the Yahoo!®
`Messenger IM service. In the peer-to-peer approach, a
`central ICQ server keeps track of Which subscribers are
`currently online and records their Internet IM protocol
`addresses. Once a subscriber logs on to the ICQ server, the
`ICQ server scans the subscriber’s contact list and displays to
`the subscriber the Internet IM protocol address of every
`person on the contact list currently logged onto the IM
`server. When the subscriber Wants to send a message to a
`recipient on the ICQ server, the subscriber simply selects the
`name of the recipient, types a message, and transmits the
`message. Because the ICQ client on the subscriber’s com
`puter has the Internet Protocol IM address of the recipient,
`the message is sent directly to the ICQ client residing on the
`recipient’s computer Without involving the ICQ server. This
`method has an advantage over the centraliZed netWork
`system because the messages do no travel through the entire
`netWork, Which speeds the transfers of large ?les, such as
`documents and images because they are not sloWed by
`netWork traf?c.
`When the conversation is complete, the subscriber eXits
`the IM program, at Which point the ICQ client on the
`subscriber’s computer generates a message to the ICQ server
`to terminate the session. The ICQ client then sends a
`message to each ICQ client on the subscriber’s contact list,
`that are currently logged onto the ICQ server, indicating that
`the subscriber has terminated his session.
`The last method of transmitting instant messages is using
`a hybrid system that combines the centraliZed netWork
`approach With the peer-to-peer approach. America On
`Line’s (AOL®’s) Instant Messaging (“AIM”) service cur
`rently uses this method. The AOL® AIM service uses the
`centraliZed netWork approach for transmitting teXt messages
`and performing presence management. Because text mes
`sages are usually small, transmitting them over the netWork
`does not noticeably sloW their delivery. HoWever, for large
`?les, such as document and images, AOL® AIM service
`uses ICQ protocol to establish a peer-to-peer connection
`betWeen the subscriber and the recipient of the message.
`Unfortunately, each of the current IM services lacks a
`coherent standard. Each IM service uses a separate propri
`etary protocol to implement instant messaging on their
`netWork. As a result, a user can only receive presence
`information and send messages to individuals that are reg
`
`Facebook's Exhibit No. 1015/1115
`Page 8
`
`

`

`US 7,016,978 B2
`
`3
`istered With the same IM service as the sender. Thus, the lack
`of a standard protocol for IM severely limits the potential
`application of IM by restricting the number of potential
`recipients to those users registered on the same service as the
`sender of the IM message.
`An example of a traditional instant messaging architecture
`is shoWn in FIG. 1. The traditional IM architecture consists
`of a central IM server 105 connected to a number of
`individual IM clients (110, 115, 120, 125, 130, and 145) in
`a closed netWork. To send an IM, from client 110 to client
`145, IM client 110 ?rst connects With an IM server 105 using
`a proprietary protocol. For example, AOL® and Yahoo!®
`use ICQ. Once the IM client 110 is connected to the IM
`server 105, the user logs on by entering a user name and
`passWord. The IM client 110 then sends the IM server 105
`the connection information, such as the IP address and
`number of the port assigned to the IM client and the name
`and address of everyone in the IM contact list associated
`With the IM client 110.
`The IM server 105 then creates a temporary ?le that
`contains the connection information for the IM client 110
`and for each IM client. Once the temporary ?les have been
`created, the IM server 105 checks the netWork to determine
`Whether any IM client identi?ed by the contact list associ
`ated With IM client 110 is currently logged into the system.
`If the IM server 105 ?nds any of the contacts logged onto the
`netWork, the IM server 105 sends a message back to the IM
`client 110 With the connection information for each IM
`client currently logged onto the netWork. When the IM client
`110 receives the connection information, the status of that
`particular IM client is updated to “Online,” Which is dis
`played to the user. At this point the user may select any IM
`client that is registered “Online,” at Which point a dialog box
`Will appear in Which the user may enter text. Because the IM
`client 110 knoWs the address and port number of the IM
`client 145 the message is sent directly to the recipient IM
`client 145. The IM client 145 then receives the instant
`message and can respond. Once the IM session is complete
`the dialog box is closed and the IM client 110 goes offline
`and sends a message to the IM server 105 terminating the
`session. The IM server 105, in response to acknowledging
`that the IM client 110 has logged off, generates a message to
`each of the IM clients on the client list of IM client 110
`indicating that IM client 110 is logged off the netWork.
`A major draWback to this system is that each IM client
`that a user Wishes to communicate With must be connected
`to the IM server and must be part of the netWork due to the
`proprietary nature of the protocol. If the IM client happens
`to lie outside the IM netWork, he or she Will not be able
`communicate With anyone in the netWork.
`One solution to the interoperability problem is an attempt
`by the Internet Engineering Task Force (IETF) to develop a
`standard protocol for instant messaging knoWn as Instant
`Messaging Presence Protocol. Many of the IM service
`providers have been Working Within the IETF to develop a
`standard IM protocol. HoWever, because each IM service
`provider has spent considerable capital developing a format
`for instant messaging, the IETF has yet been unable to
`establish a standard protocol.
`Another solution to the interoperability problem is JAB
`BER, Which is an IM system focused on providing IM
`access to any user from anyWhere using any device and
`interoperability With IM services. JABBER is Extensible
`Markup Language (XML) open source server softWare that
`Was developed by a community of developers over the
`Internet. JABBER alloWs communication among applica
`tions and systems across all platforms. Developers write
`
`10
`
`15
`
`25
`
`35
`
`40
`
`45
`
`55
`
`65
`
`4
`additional modules to submit them back for possible incor
`poration into the JABBER softWare. Unfortunately, most of
`the IM services do not use XML as their IM format.
`Therefore, to achieve interoperability betWeen the IM ser
`vices, JABBER requires a translation module to translate the
`IM message in XML format into each of the formats used by
`the separate IM services. Therefore, the JABBER system
`adds additional cost and complexity to the IM infrastructure.
`A block diagram illustrating a prior art IM netWork that
`uses JABBER Interoperable XML-Based NetWork architec
`ture is shoWn in FIG. 2. JABBER is a real-time communi
`cations platform based on open protocols and Extensive
`Markup Language (XML), and Whose architecture is based
`on the Well-knoWn electronic mail system. Because JAB
`BER is based on the email system, the JABBER architecture
`contains distributed netWork servers, called JABBER serv
`ers 215, and clients, knoWn as JABBER clients 200, 205,
`210, that receive and send messages to JABBER clients
`connected to any JABBER server on the Internet. HoWever,
`unlike typical email systems, Which are store and forWard
`systems, JABBER delivers messages in real time because
`the JABBER server 215 knoWs When a particular JABBER
`client is online.
`TWo features of JABBER make it unique over common
`prior art IM systems. First, JABBER uses an open protocol
`that alloWs interoperability among various IM systems.
`Second, JABBER is based on XML, Which alloWs for easy
`and reliable structured messaging betWeen softWare appli
`cations.
`The JABBER architecture is based on client-server archi
`tecture and not on a client-to-client architecture, as are most
`IM systems. Messages from JABBER client 200 to JAB
`BER client 210 must pass through the JABBER server 215.
`Each JABBER client is attached to a local JABBER server
`215. Each local JABBER server 215 receives information
`from one JABBER client 200 and transfers the information
`to another JABBER client along With presence information.
`Each local JABBER server 215 functions independently
`from one another, and can communicate With any other
`JABBER server that is connected to the Internet as long as
`it has been identi?ed, and predisposed to do so ahead of
`time.
`Each local JABBER server 215 performs tWo functions:
`listening for and communicating directly With JABBER
`client applications, and communicating With other JABBER
`servers. Each local JABBER server 215 consists of multiple
`components that separately handle individual functions With
`the JABBER system. At the core of the local JABBER
`server 215 is a deliver component 220, Which performs the
`folloWing tasks: session management, client-to-server com
`munications, server-to-server communications, group chat,
`storing messages for JABBER clients currently offline, DNS
`resolution, user authenti?cation, user registration, database
`lookups ?ltering messages for offline users, and the like.
`Additionally, each JABBER server 215 contains “trans
`ports” 225, 230, and 235 that communicate With other
`servers operating under protocols that are foreign to JAB
`BER’s open XML format. The transports act as translators
`betWeen the deliver component 220 of the local JABBER
`server 215 and a third party instant messenger server. Each
`transport contains their oWn session manager that translates
`JABBER XML into and out the “foreign” protocol for
`presence, messaging, and information/query requests. In
`general, When a client logs onto the JABBER server 215, a
`thread is created in the transport to handle all communica
`tion from that client. Typically, the translation to and from
`JABBER XML is straightforWard When the foreign protocol
`
`Facebook's Exhibit No. 1015/1115
`Page 9
`
`

`

`US 7,016,978 B2
`
`10
`
`15
`
`5
`is Well documented, as in the case of IRC protocols, and the
`AIM protocol. However, for other foreign protocols that are
`poorly documented, such as Yahoo!® Instant Messenger, the
`translation to and from JABBER XML can either be dif?cult
`and sloW. Currently, transports are available to translate to
`and from the following protocols: AOL® AIM, ICQ, IRC,
`MSN Messenger, Rich Site Summary (RSS ver. 0.9), and
`Yahoo!® Instant Messenger.
`As an example, When the JABBER client 200 Wishes to
`communicate With a client 245 on a third party instant
`messenger server 240, such as AOL Instant Messenger, the
`JABBER client 200 ?rst generates a message Which is sent
`to the local JABBER server 215. The message contains
`JABBER ID that contains the name of the third party instant
`messaging server 240 (e.g., johndoe@aim.goabber.org). The
`local JABBER server 215 routes the message to the appro
`priate translator, Which in the illustration is Translator 225.
`If the Translator 225 is running locally on the local JABBER
`server 215, the JABBER server 215 communicates directly
`With the Translator 225. If, hoWever, the Transport 225 is
`running remotely, the JABBER server 215 passes the XML
`packet to the remote server, Which then forWards it onto the
`Translator 225. After the local JABBER server 215 has
`passed the message to the Translator 225, the Translator 225
`translates the XML packet into a native packet, Which is
`readable by the third party instant messenger server 240. The
`third party instant messenger server 240 in turn, passes the
`translated packet onto the appropriate client 245.
`The Jabber architecture relies heavily on translators and is
`constrained by its ability to keep up With each provider’s
`protocol, and method of handling presence. Thus, there is a
`need in the art for a simple, cost effective IM network
`architecture that uses a universal IM presence and intercon
`nection methodology that is compatible With the existing IM
`Service Provider netWorks.
`
`25
`
`35
`
`SUMMARY OF THE INVENTION
`
`The present invention addresses the above-described
`needs in a universal instant messaging system. Generally
`described, a computer netWork system according to an
`embodiment of the invention for establishing a communi
`cations link betWeen a ?rst user registered With a ?rst service
`provider netWork and at least one user registered With a
`second service provider netWork When the tWo netWorks
`operate using different protocols. The netWorks, Which are
`connected by a distributed netWork, such as the Internet,
`each contain a Local IM server connected to each user. The
`Local IM server controls the How of electronic information
`betWeen the users logged onto the particular netWork.
`The netWorks also contain a Universal IM server that is
`connected betWeen the Local IM server and the distributed
`netWork. The Universal IM server contains a database that
`stores routing information and Presence information for
`each user registered With the ?rst service provider netWork
`and some of the users of other provider netWorks. The
`Presence information contains user attributes and a set of
`logic rules that are used to control the communications link
`betWeen the ?rst and second users. The user attributes
`contained in the Presence information include a list of each
`Internet device each user has registered to receive electronic
`messages, a list of connection options for each registered
`Internet device, a list of available states for each Internet
`device, and an application identi?er associated With each
`Internet device.
`Additionally, the Presence information contains a set of
`logic rules that govern the communications link betWeen the
`
`40
`
`45
`
`55
`
`65
`
`6
`?rst and second user. The logic rules include a hierarchical
`listing of each user’s registered Internet devices that indi
`cates the order in Which each Internet device should be
`contacted to establish the communications link, a security
`level for each registered Internet device, and a listing of the
`applications that each Internet device is able to support.
`A method according to an embodiment of the invention,
`establishes an instant message session betWeen a ?rst user
`registered on a ?rst ISP (ISP) netWork and a second user
`registered on a second ISP over the Internet When the ?rst
`and second ISPs are operating under different instant mes
`saging protocols. The method begins by the ?rst user gen
`erating a connection request and transmitting it to a Local
`IM server associated With the ?rst ISP. The connection
`request contains a USERID associated With the second user.
`The Local IM server checks the routing information for the
`connection request to determine Whether the second user is
`registered With the ?rst ISP. If the second user is registered
`With the ?rst ISP, the Local IM server associated With the
`?rst ISP establishes the instant message session betWeen the
`tWo users. If hoWever, the second user is registered With
`another Local IM server, the connection request is routed to
`a Universal IM server to determine the appropriate Local IM
`server to receive the request. The Universal IM server
`contains a database that lists each user on its oWn netWork
`and selected users on other ISPs. The selected users are
`derived from the contact lists or rosters for each user on the
`?rst ISP netWork. A determination is made at the Universal
`IM server on the ?rst ISP Whether the second user is listed
`in the database. If the second user is listed in the database,
`the Universal IM server connected to the ?rst ISP forWards
`the connection request to a Universal IM server connected to
`the second ISP. The Universal IM server connected to the
`second ISP then transmits back to the Universal IM server
`on the ?rst ISP the routing information and the Presence
`information associated With the second user. The ?rst Uni
`versal IM server then establishes an instant message session
`based on the routing and Presence information returned from
`the Universal IM server using the extensive markup lan
`guage (XML) protocol.
`
`BRIEF DESCRIPTION OF DRAWINGS
`
`The accompanying draWings, Which are incorporated in
`and form a part of the speci?cation, illustrate preferred
`embodiments of the present invention and, together With the
`description, disclose the principles of the invention. In the
`draWings:
`FIG. 1 is an illustration of a prior art instant messaging
`system.
`FIG. 2 is an illustration of a prior art JABBER interop
`erable XML-based instant messaging netWork.
`FIG. 3 is block diagram of a personal computer that
`provides the operating environment for an embodiment of
`the invention.
`FIG. 4 is an illustration of a universal instant messaging
`architecture using an exemplary embodiment of the inven
`tion.
`FIG. 5 is a logic ?oW diagram illustrating a method for
`registering a neW user With a Service Provider NetWork
`using the universal instant messaging architecture.
`FIG. 6 is logic ?oW diagram illustrating a method of
`establishing a communications link betWeen at least tWo
`users using the universal instant messaging architecture.
`
`Facebook's Exhibit No. 1015/1115
`Page 10
`
`

`

`US 7,016,978 B2
`
`7
`DETAILED DESCRIPTION OF THE
`EMBODIMENTS
`
`The present invention is directed toward novel architec
`tures, systems, and methods for providing instant messages
`(IM) over a distributed netWork to multiple users connected
`to different Internet devices, such as personal computer,
`cellular telephones, Personal Digital Assistants, pagers, and
`the like on separate ISPs (ISP) operating different IM
`protocol standards.
`
`Exemplary Internet Device
`An exemplary Internet device for implementing the
`invention is shoWn in FIG. 3, Which includes a conventional
`personal computer 100 With a processing unit 326, a system
`memory 304, and a system bus 306, Which joins the system
`memory 304 to the processing unit 326. The system memory
`304 includes read only memory (ROM) 308 and random
`access memory (RAM) 312. The basic input/output system
`(BIOS) 310 is stored in ROM 308, and contains basic
`routines that aid in transferring information betWeen ele
`ments Within the personal computer 300, as found during
`start-up. Further, the personal computer 300 contains a hard
`disk drive 330, a magnetic disk drive 348, and an optical
`disk drive 356, e.g., to read from or Write to other optical
`media, or for reading a CD-ROM disk 360. Ahard disk drive
`interface 328, a magnetic disk drive interface 334, and an
`optical drive interface 338, connect the hard disk drive 330,
`magnetic disk drive 348, and optical disk drive 356 to the
`system bus 306. Non-volatile storage is provided for the
`personal computer 302 by the drives and their associated
`computer-readable media. Those skilled in the art should
`recogniZe that other types of media are readable by a
`computer, e.g., magnetic cassettes, digital video disks, ?ash
`memory cards, ZIP cartridges, JAZZ cartridges, etc. may be
`used in the exemplary operating environment as Well as the
`computer-readable media described above.
`Various program modules may be stored in the RAM 312.
`These include, but are not limited to, an operating system
`314, one or more application programs 316, and program
`data 320, and other program modules. The personal com
`puter 302 alloWs commands and information to be entered
`by devices such as a keyboard 354, a mouse 352, or other
`input device. Along With these conventional devices, pens,
`touch-operated devices, microphones, joysticks, game pads,
`satellite dishes, scanners, etc. may also be used to enter
`commands or information. The input devices are typically
`connected to the processing unit 326 through a serial port
`interface 336 coupled to the system bus 306. The devices
`may also be connected by other interfaces, such as a game
`port or a universal serial bus (USB). A display screen 324 or
`other type of display device is connected to the system bus
`306 via a video adapter interface 322. It is typical of personal
`computers to include other peripheral output devices, such
`as speakers or printers, as Well as the display screen 324.
`Logical connections to one or more remote computers
`342, alloW the personal computer 302 to operate in a
`netWorked environment. Although the remote computer 342
`has been shoWn as a personal computer, in FIG. 3, it should
`be apparent to those skilled in the art that the remote
`computer 342 may be a server, a router, a peer device or
`other common netWork node, and on average includes many
`or all of the elements described in relation to the personal
`computer 302. A local area netWork
`340 and a Wide
`area netWork
`362 are the typical logical connections
`that connect the personal computer 102 to the remote
`computer 342. These logical connections are commonly
`
`15
`
`25
`
`35
`
`40
`
`45
`
`55
`
`65
`
`8
`found in offices and enterprise-Wide computer netWorks,
`such as intranets and the Internet.
`The personal computer is connected to the LAN 340
`through a netWork interface 332, When used in a LAN
`netWorking environment. In a WAN netWorking environ
`ment, the personal computer 302 normally includes a
`modem 350 or other channels of establishing communica
`tions over the WAN 362, (e. g. the Internet). The modem 350
`is connected to the system bus 160 via the serial port
`interface 336, Which may be either internal or external to the
`personal computer 302. The application programs 316
`described above relative to the personal computer 302, or
`any part thereof, may be stored in the remote memory
`storage device 344 of the netWorked computer 342 in the
`netWorked environment. The netWork connections shoWn
`are exemplary and those skilled in the art Will appreciate that
`other Ways of establishing a communications link betWeen
`the personal computer and the remote computer exist With
`out departing from the scope of this invention.
`
`Universal Instant Messaging Architecture
`FIG. 4 is an illustration of a Universal IM architecture
`400. The Universal IM architecture 400 uses a universal
`protocol, such as the extensible markup language (XML)
`protocol to alloW users of different ISPs (ISPs) 405 and 430
`that use proprietary protocols to communicate With one
`another. AUniversal IM server 425 located at ISP 405 is the
`key feature of the Universal IM architecture 400. FIG. 4
`illustrates tWo separate ISP NetWorks, ISP 405 and ISP 430.
`