(12)
`
`United States Patent
`DeSimone et al.
`
`(10) Patent N0.:
`(45) Date of Patent:
`
`US 6,212,548 B1
`*Apr. 3, 2001
`
`US006212548B1
`
`(54) SYSTEM AND METHOD FOR MULTIPLE
`ASYNCHRONOUS TEXT CHAT
`CONVERSATIONS
`
`(75) Inventors: Antonio DeSimone, Lebanon;
`Elizabeth A. Hohne, Long Branch;
`Rf‘ngamam sundi‘r’ Fref’hold;
`VlShWaIlathaIl ThlagaraJall; Kumar
`K- Vishwanathan, both of Holrndel, all
`Of NJ (US)
`
`_
`
`(73) Assignee: AT & T Corp, New York, NY (US)
`
`(*) Notice:
`
`This patent issued on a continued pros-
`ecution application ?led under 37 CFR
`1.53(d), and is subject to the tWenty year
`patent term provisions of 35 U.S.C.
`154(a)(2).
`
`Subject I0 any disclaimer, the term Of this
`Pawnt is eXteIlded or adjusted under 35
`U.S.C. 154(b) by 0 days.
`
`(21) Appl, N()_j 09/126,162
`
`5,528,671
`5,633,916
`5,659,692
`5,694,163
`5’721’763
`
`6/1996 Ryu et al. .
`5/1997 Goldhagen et al. .
`8/1997 Poggio et al. .
`12/1997 Harrison.
`2/1998 Joseph et a1‘ '
`gusey 6‘ a1"
`6/1998 Choquier et 8.1..
`5,774,668
`5,793,365 * 8/1998 Tang et al. ......................... .. 345/329
`5,828,839 * 10/1998 Moncreiff
`.. 709/204
`5,926,179 * 7/1999 Matsuda et al.
`. 345/355
`5,999,208 * 12/1999 McNerney et al. .................. .. 348/15
`OTHER PUBLICATIONS
`
`,
`
`,
`
`uthyar et al. .
`
`Honeycutt and Pike, “Using mIRC, Netscape Chat, and
`Comic Chat,” Chap. 36 in Using the Internet, Third Edition,
`1996, pp. 905—925.
`“The Undernet Documens Project,” from http://WWW.
`user—com.undernet.org/documents, 3 pages, updated Mar.
`30, 1998.
`Oikarinen and Reed, “Internet Relay Chat Protocol,” Net
`Work Working Group, Request for Comments 1459, May,
`1993.
`“Activerse Documentation” from http://WWW.activerse.com/
`product/ding/v20/docs/toolbar.htm, last modi?ed Jul. 28,
`
`Jul. 30, 1998
`
`(22) Filed:
`_
`199?‘
`(51) Int Cl 7
`G06F 13/00
`* cued by exammer
`(52) US. Cl. ........................ .. 709/204; 709/206; 709/219; 23% obizgmferjvlet 1],): W Wu. R
`709/313; 709/329
`y, gen, 0r zrm— 1 1am yan
`
`(58) Field of Search ................................... .. 709/204, 205,
`709/206, 217, 219, 232, 313, 317, 329;
`345/339, 340, 347, 330, 331, 332
`
`(56)
`
`References Cited
`
`US. PATENT DOCUMENTS
`_
`11/1985 Plke '.
`4’555’775
`8/1988 HuntZlnger .
`4,761,642
`4/1989 Pope _
`478237108
`6/1991 Gur1ey_
`5’036’315
`12/1991 Henderson’ ]L et a1_ _
`5,072,412
`4/1992 Simth et al. _
`5,107,443
`7/1994 Page et al. .
`5,329,619
`4/1995 Goikas et al. .
`5,408,602
`5,491,743 * 2/1996 Shiio et al. ........................ .. 709/204
`
`ABSTRACT
`(57)
`H.
`1 n f
`.
`t
`.
`f
`A luraht
`p
`y 0 users commumca e m a pg’ur'a 1 y o. rea lme
`text conversations (e.g., chat sessions ) in a client-server
`message processing environment using messages including
`a conversation index, a conversation-initiator ID and a list of
`message recipients. Each conversation is maintained at
`client terminals in an individual Window. Dropping and
`controlled adding of conversation participants is attended by
`.
`.
`.
`message updates to other participants. Alternative peer-to
`peer message handlmg reduces the processmg burden on
`servers While alloWing clients to perform control and display
`functions. Voice or other non-text messages are also com
`municated using described techniques.
`
`15 Claims, 6 Drawing Sheets
`
`,700
`
`f
`
`00105115111011 - 1
`1N ROOM: DAWN, MIKE, DAVE
`DAWN > 6111 YOU BELIEVE ll?
`MIKE > com so - BYE
`" MIKE DROPPED '1
`01v: > lo BAD MIKE HAD 10 DROP
`om
`
`DAWN
`
`17211
`[710
`SEE
`CONVERSATION 4 2
`SEE] l
`[15E]
`\El 1N ROOM: DAWN, TOM, DlCK
`DAWN > | WAS 11151 11mm: 10 WE
`MIKE > WHAT n10 MIKE HAVE TO 5m
`01w" > 101/ mu NEVER BELlEVE 1111s
`TOM > 1 THINK HE 10111 ME THE SAME
`STORV BEFORE
`
`Facebook and WhatsApp Exhibit No. 1006
`Page 1
`
`

`
`U.S. Patent
`
`Apr. 3, 2001
`
`Sheet 1 0f 6
`
`US 6,212,548 B1
`
`Facebook and WhatsApp Exhibit No. 1006
`Page 2
`
`

`
`U.S. Patent
`
`Apr. 3, 2001
`
`Sheet 2 0f 6
`
`US 6,212,548 B1
`
`FIG. 2A
`
`f 210
`
`CLIENT
`
`CLIENT
`
`CLIENT
`
`CLIENT
`
`FIG. 3
`
`DAWN — INITIATE CHAT
`
`BENZ]
`
`PUT IN CHAT
`AVAILABLE FOR CHAT
`MIKE
`\:>
`DAVE
`<):
`
`NAME CHAT ROOM:
`HELP] ICREATE CHAT ROOM
`
`CLOSE
`
`Facebook and WhatsApp Exhibit No. 1006
`Page 3
`
`

`
`U.S. Patent
`
`Apr. 3, 2001
`
`Sheet 3 0f 6
`
`US 6,212,548 B1
`
`FIG. 4A
`
`DAWN
`CHATS FOR ALL
`m ROOM: DAWN, MIKE
`DAWN > HELLO!
`MIKE > HI THERE
`DAWN > HAvE YOU HEARD THE LATEST?
`
`TZIIEIET
`ADD
`
`FIG. 48
`
`MIKE
`CHATS FOR ALL
`IN ROOM: DAWN, MIKE
`DAWN > HELLO!
`MIKE > Hl THERE
`DAWN > HAVE YOU HEARD THE LATEST?
`
`EHEHZI
`ADD
`
`HOLD 0N - WAIT UNTIL | ADD DAVE
`
`FIG. 4C
`
`DAVE
`
`Facebook and WhatsApp Exhibit No. 1006
`Page 4
`
`

`
`U.S. Patent
`
`Apr. 3, 2001
`
`Sheet 4 0f 6
`
`US 6,212,548 B1
`
`FIG. 5A
`
`DAWN
`CHATS FOR ALL
`IN ROOM: DAWN, MIKE, DAVE
`DAWN > HELLO!
`MIKE > HI THERE
`DAWN > HAVE YOU HEARD THE LATEST?
`MIKE > HOLD ON — WAIT UNTIL I ADD DAVE
`** DAvE ADDED "
`
`QEIIZI
`ADD
`
`ME > HH
`
`@
`
`@
`
`FIG 58
`
`MIKE
`CHATS FOR ALL
`IN ROOM: DAWN, MIKE, DAvE
`DAWN > HELLO!
`MIKE > HI THERE
`DAWN > HAVE YOU HEARD THE LATEST?
`MIKE > HOLD ON — WAIT UNTIL I ADD DAVE
`" DAVE ADDED **
`
`IZIIEIIE
`DE
`
`DAVE > HI!
`
`FIC 5C
`
`DAVE
`CHATS FOR ALL
`IN ROOM: DAWN, MIKE, DAVE
`"* WELCOME "
`
`DAVE > HI!
`
`IZIIEIIZI
`ADD
`
`Facebook and WhatsApp Exhibit No. 1006
`Page 5
`
`

`
`U.S. Patent
`
`Apr. 3, 2001
`
`Sheet 5 0f 6
`
`US 6,212,548 B1
`
`FIG. 6A
`
`DAWN
`
`CHATS FOR ALL
`IN ROOM: DAwN, MIKE, DAvE
`MN > CAN YOU BELIEVE IT?
`MIKE > com 00 - BYE
`** MIKE DROPPED “
`ME > T0 BAD MIKE HAD TO DROP
`OFF!
`
`KNEE
`ADD
`
`FIG. 6B
`
`MIKE
`
`EHEHZI
`IE]
`
`CHATS FOR ALL
`IN ROOM: DAwN, MIKE, DAVE
`DAWN > CAN YOU BELIEVE IT?
`MIKE > GOTTA G0 — BYE
`" MIKE DROPPED *"‘
`DAVE > T0 BAD MIKE HAD TO DROP
`OFF!
`
`@
`
`Facebook and WhatsApp Exhibit No. 1006
`Page 6
`
`

`
`Facebook and WhatsApp Exhibit No. 1006
`Page 7
`
`

`
`US 6,212,548 B1
`
`1
`SYSTEM AND METHOD FOR MULTIPLE
`ASYNCHRONOUS TEXT CHAT
`CONVERSATIONS
`
`FIELD OF THE INVENTION
`
`The present invention relates generally to the ?eld of
`messaging systems and methods. More particularly, the
`present invention relates, in one aspect, to methods and
`systems for maintaining multiple simultaneous asynchro
`nous text (or other) conversations. Still more particularly,
`aspects of the present invention relate to systems and
`methods for establishing and maintaining multiple simulta
`neous asynchronous message sessions betWeen overlapping
`or non-overlapping sets of users in data communications
`contexts, such as Internet chat sessions.
`
`10
`
`15
`
`BACKGROUND OF THE INVENTION
`
`The Internet and many on-line information services pro
`vide electronic mail (e-mail), conferencing and chat
`services, and the ability to access remote computers for
`sending and retrieving ?les. E-mail, perhaps the most Widely
`used of Internet and on-line service applications, has an
`(often desirable) inherent “off-line” time delay characteris
`tic.
`Internet Relay Chat (IRC) or, simply “chat” provides
`informal communications among users of data netWork
`facilities. Chat alloWs tWo or more users to converse by
`exchanging text messages, typically through a “channel” or
`virtual “chat room” maintained on one or more chat servers
`and accessed via an on-line service or using general purpose
`chat “client” softWare executing at a user terminal, Work
`station or personal computer. Only chat “participants” con
`nected (typically through a telephone line modem) to the
`on-line service or other chat environment provided by one or
`more chat servers, can take part in the chat. Chat room
`“conversations” are displayed as text in a chat room WindoW
`on a participant’s display screen, usually accompanied by a
`list of chat participants. The text displayed at a participant’s
`terminal usually includes a history of the conversation from
`the time that the vieWing participant joined the chat room.
`Entering particular chat rooms is typically effected using a
`list or menu of currently available chat rooms. Exiting a chat
`room is usually as simple as closing the chat WindoW.
`Extensions of the basic chat model of communications
`permit use of voice (or other audio), video and other
`message content.
`Chat Rooms (including private chat rooms, described
`beloW) are established on chat servers in advance of text
`conversations, and alloW many users to communicate via
`messages. Any user may elect to join a chat room (become
`a participant), subject to prior subscription or registration
`procedures imposed by the on-line service provider or
`operator of the chat server(s). Many versions of chat client
`softWare, With varying functionality and communications
`protocols, are Widely available on the Internet for doWnload.
`Participants in a chat room receive all messages sent to the
`chat room and can decide to contribute input messages
`according to personal preference.
`Private chat rooms are set up by a participant seeking to
`have private text communications With a selected one or
`more other participants in an existing chat. ToWard this end,
`the initiating participant typically sends a “query” or similar
`message to another participant With Whom the initiating
`participant Wishes to privately communicate. A recipient of
`this query agrees to take part in a private chat With the
`initiating user by responding to the message. Others may be
`
`2
`added in similar fashion. The server provides a separate chat
`room or channel not accessible by anyone not invited by
`those in the established private chat room.
`Instant Messaging (IM) alloWs a user to launch a message
`to another user. Variants of IM permit a notice to be sent to
`others (e.g., those on a “buddy list” ) When a particular user
`logs on to a server, even Without joining a chat or other
`tWo-or-more-person conversation. Users announce their
`availability to receive messages by electing options or
`submitting system parameters in advance. The sender of an
`instant message determines Who Will receive the message.
`While the foregoing and other features of e-mail, chat and
`instant messaging have proven very useful in a number of
`contexts, these systems suffer from a number of real time
`limitations. For example, current chat environments limit
`users to participation in only one multiple-party (three or
`more participant) real-time chat room at a time. Users may
`participate in more than one conversation in real time, if
`these are tWo-Way conversations. Likewise, a user may
`pursue multiple conversations (strings of messages) With
`multiple users, but only over an elapsed time period using
`multiple WindoWs for conversation events, participation, and
`display.
`
`25
`
`SUMMARY OF THE INVENTION
`
`Limitations of the prior art are overcome and a technical
`advance is made in accordance With the present invention
`described in illustrative embodiments herein.
`In accordance With one aspect of the present invention, a
`user maintains multiple simultaneous real-time chat sessions
`With a plurality of other participants using a single client
`residing on a personal computer, Workstation or terminal
`(collectively, “terminal”). Advantageously, each of the con
`versations is presented in a separate WindoW on the terminal,
`and the user can select a WindoW for text input in the usual
`Way.
`In accordance With an illustrative embodiment, a tech
`nique for labeling and addressing messages is introduced
`and applied in a data netWork With a technique for presenting
`conversation events, messages, and history. These and other
`features of illustrative embodiments permit dynamic cre
`ation of multiple simultaneous asynchronous conversations,
`each among multiple users, in a distributed manner—all in
`real time. Participants in component conversations may
`change over the life of the conversation and the conversa
`tions Will include overlapping sets of users.
`Participants send messages in the context of a particular
`conversation. In accordance With an illustrative system
`embodiment, these conversations and communications
`events (e.g., adding a participant, removing a participant)
`among multiple users are tracked in a completely distributed
`manner and in real time. The conversation data, including
`events, messages, and history, is presented to the user in an
`organiZational structure that uniquely identi?es the conver
`sation.
`While participants in several simultaneous real-time con
`versations may be overlapping to various extents, in one
`class of embodiments the set of messages sent to participants
`in one or more of the conversations is mutually exclusive of
`the set of messages sent to participants in one or more other
`conversations. A useful illustrative example is a session
`including a negotiation betWeen tWo (or more) principal
`negotiators, each of Whom has background advisors. The
`respective advisors take part in “Whisper conversations”
`With their principal(s) that cannot be observed (“heard”) by
`the opposing negotiator or opposing advisors, or even others
`
`35
`
`45
`
`55
`
`65
`
`Facebook and WhatsApp Exhibit No. 1006
`Page 8
`
`

`
`US 6,212,548 B1
`
`3
`on the same side of the negotiation. Side conversations, e.g.,
`betWeen opposing advisors seeking to resolve underlying
`technical or procedural points, can be pursued under the
`observation of other advisors and/or principals in separate
`chat WindoWs. Advantageously, advisors on the same side
`can selectively pursue such side conversations as Well.
`
`BRIEF DESCRIPTION OF THE DRAWING
`
`The above-summariZed description of illustrative
`embodiments of the present invention Will be more fully
`understood upon a consideration of the folloWing detailed
`description and the attached draWing, Wherein:
`FIG. 1 is an overall vieW of a data netWork in Which
`embodiments of the present invention are used and prac
`ticed.
`FIG. 2A shoWs an illustrative client-server message han
`dling architecture for use With embodiments of the present
`invention.
`FIG. 2B shoWs an illustrative peer-to-peer message han
`dling architecture for use With embodiments of the present
`invention
`FIG. 3 shoWs an illustrative chat initiation WindoW for use
`by a message-initiating user at a client terminal.
`FIGS. 4A—C, 5A—C and 6A—C shoW illustrative vieWs of
`WindoWs at typical client terminals during various phases of
`establishing, maintaining and removing from conversations.
`FIG. 7 shoWs a terminal display With a plurality of
`simultaneous real-time multiple party message conversa
`tions in respective WindoWs.
`
`DETAILED DESCRIPTION
`
`Terminology
`It proves useful to introduce a set of terms as a basis for
`the detailed description given beloW. For this purpose the
`folloWing terms and respective meanings Will be applied:
`Session: all potential participants in on-line conversations.
`Thus, in the negotiation example mentioned above, all users
`on both sides are part of the session. In other cases the
`session may include a group of users such as those logged
`onto an on-line service or similar chat room, or included in
`a “buddy list” maintained by a user.
`Conversation: a string of messages among participants in a
`session, presented Within a WindoW at each participant’s
`display. Non-participants in a conversation do not receive
`messages in a conversation, nor can non-participants send
`messages to participants in the context of the conversation.
`A conversation has a history that may be different for
`different participants.
`Message: information generated by a participant that is
`added to a conversation history. Also includes control infor
`mation including conversation id and a list of participants in
`a conversation.
`Initiating Message: the ?rst message in a conversation.
`Augmenting Message: a message that indicates a participant
`has been added to a conversation.
`Pruning Message: a message that indicates a participant has
`been removed from a conversation
`Illustrative System OvervieW
`FIG. 1 shoWs an illustrative data communications system
`150, such as the Internet With attendant access facilities, in
`Which the present invention may be applied. Of course
`netWork 150 may be an on-line service netWork, or any other
`real-time message-handling netWork. In netWork 150 a rep
`resentative plurality of personal computers, Workstations, or
`terminals (collectively “terminals”), 105-i, i=1, 2, .
`.
`. , N are
`shoWn connected by Way of telephone lines or other access
`
`10
`
`15
`
`25
`
`35
`
`45
`
`55
`
`65
`
`4
`paths through a data netWork (illustratively, the Internet) 100
`to a server 110. N can be any positive integer, subject to
`transmission and processor capacity limitations.
`Server 110 is shoWn With dashed lines on its right to
`indicate that the server functions may be distributed over an
`arbitrary number of netWorked cooperating servers. Each
`terminal 105-i is connected (through standard access
`facilities) to an associated server. In some cases all terminals
`Will be associated With the same server, but more generally
`one or more terminals Will be connected to each of a group
`of servers. In typical operation, the terminals 105-i execute
`client softWare for cooperating With server softWare running
`on a respective server 110 to enable chat functionalities. In
`one illustrative case, client and server softWare Will be based
`on Well-known chat components such as mIRC client and
`server softWare by mIRC Co. Ltd. Which is available on the
`Internet, e.g., at http://WWW.mirc.co.uk, and from other
`distributors.
`Further information about Well-known chat softWare and
`procedures is available from the Undernet User Committee
`Web site at WWW.user-com.undernet.org/documents/. Of par
`ticular note is NetWork Working Group Request for Com
`ments: 1459, by J. Oikarinen and D. Reed, May, 1993,
`available at the Undernet Web site. This latter document
`presents a version of the Internet Relay Chat (IRC) Protocol
`that has provided important bases for current chat imple
`mentations. Other particular client/server implementations
`of various chat functionalities include several quIRC chat
`softWare modules.
`Standard chat methodologies, including those recited
`above, or used in other chat systems Well knoWn to the art,
`or described in documents Well knoWn in the art, are
`modi?ed and extended in accordance With aspects of the
`present invention to realiZe desirable inventive functional
`ities. Features and operations of illustrative systems, meth
`ods and protocols for achieving advantages of the present
`invention Will be described beloW.
`Message Handling Architectures and Protocols
`Aprincipal mechanism for communicating messages and
`managing WindoWs for vieWing chat conversations in accor
`dance With illustrative embodiments of the present invention
`is the Well-known client-server architecture, as modi?ed in
`the manner described beloW. FIG. 2A illustrates a simple
`client-server architecture for message handling in accor
`dance With one class of embodiments of the present inven
`tion. In FIG. 2A, a snapshot of activity among a sampling of
`netWork elements, messages are seen to be sent from one
`client (illustratively client 220) to a server 210. At server 210
`processing of the message is performed to effect control and
`distribution of messages in a conversation (to clients 230
`and 250, for example). At other times, clients such as 230,
`240 or 250 originate messages that are processed by server
`210 and forWarded, as appropriate, to other clients. In
`accordance With aspects of embodiments of the present
`inventive contributions, a client maintains a plurality of
`simultaneous plural-participant conversations.
`Alternatively, many of the message handling and WindoW
`control operations used in embodiments of the present
`invention are advantageously accomplished using a peer-to
`peer interconnection among clients. Such a system arrange
`ment is shoWn in a simpli?ed example in FIG. 2B, Where
`clients 260, 270, 280 and 290 are shoWn selectively com
`municating messages. Because a message format is used, in
`accordance With one aspect of the present invention, that
`alWays alloWs a receiving client to identify the chat conver
`sation With Which a message is associated, much of the
`routing and WindoW control functionality can be left to the
`
`Facebook and WhatsApp Exhibit No. 1006
`Page 9
`
`

`
`US 6,212,548 B1
`
`5
`client software at user terminals. Aspects and advantages of
`such peer-to-peer interconnection Will be discussed below.
`As With the presently modi?ed client-server architecture, a
`client can maintain plural simultaneous conversations, each
`With a plurality of other participants.
`Initially, hoWever, it Will be assumed for illustration that
`a client-server architecture is used to permit clients to
`exchange messages through one or more respective servers.
`Each client is associated With a particular server, Which
`server may be shared among clients or co-located With a
`designated client. Such a client-server arrangement can be
`considered to be essentially a star con?guration if intercon
`nected servers, if any, are considered as one server. This
`latter condition Will be assumed in discussions of client
`server system organiZations in the sequel. That is, it Will be
`assumed that all servers in a multi-server netWork Will
`maintain, or have ready access to, lists of participants and
`other message handling information maintained at servers to
`control the processes described beloW. Such exchange of
`information betWeen servers is commonplace in multi
`server environments.
`In beginning a discussion of typical message handling
`operations in accordance With the present invention, it Will
`be recogniZed that any message conversation has an initiator
`and a set of participants. Further, any message has a sender
`and a set of recipients that is a superset of the set of
`participants. In accordance With one aspect of some illus
`trative embodiments of the present invention, a message that
`includes a set of recipients that is a proper superset of the set
`of participants advantageously changes the set of partici
`pants in the conversation to include all the recipients of the
`message. A message therefore includes an identi?cation of
`the existing participants in the conversation, and perhaps
`others being added by the message.
`In accordance With illustrative embodiments of the
`present invention, characteristics desirably included in any
`message from a message-originating user are message ele
`ments identifying
`the originating user, (ii) all recipients of
`the message, and (iii) a conversation index.
`Thus, each user in a conversation has a unique identi?er
`(unique across the session, at least) associated With the user.
`This user identi?er may be assigned speci?cally for the
`session or may be persistently associated With the user.
`Examples include an e-mail address or an Internet Protocol
`(IP) address, but nicknames are common in chat contexts.
`Also, as noted, it proves advantageous to cause all conver
`sations initiated by a sender have a unique conversation
`index. The combination of sender’s ID and conversation
`index are advantageously used by all recipients of a message
`to determine the conversation With Which the message is
`associated. The system Will have unique names for each
`conversations generated by the initiators and, as is usual for
`chat rooms, unique names for each participant visible to
`each participant.
`In one illustrative embodiment, any participant can add a
`neW participant at any point in the conversation. This
`conversation event advantageously triggers a message to all
`other participants, causing their vieW to be updated. Any
`participant may choose to remove himself or herself from a
`conversation. As in the case of adding a participant, this
`event conveniently triggers a vieW-updating message to all
`participants. These and other typical message characteristics
`and operations Will noW be illustrated in an illustrative
`example involving the initiation of a chat room, the subse
`quent use of the chat room to broadcast to participants, and
`the removal of participants from the chat room.
`Message Formats
`
`15
`
`25
`
`35
`
`45
`
`55
`
`65
`
`6
`The ASCII message protocol conveniently used to
`describe the messages exchanged betWeen the client and the
`server in many chat environments is adopted for the present
`illustrative embodiments. Because many aspects of existing
`chat message protocols Will prove useful in employing the
`present invention, elements useful in introducing the above
`recited and other inventive features Will be used in augment
`ing existing formats and protocols. In any event, it Will be
`understood that many particular message formats may be
`adopted for use With the present inventive contributions, as
`circumstances may alloW or dictate. To provide a common
`illustrative format, it proves useful to employ the folloWing
`message elements:
`
`[Headl NL]+NL NL [Name:Value]* NL NL NL *
`
`Where NL (neWline) is also represented as \n. A message is
`therefore taken as complete When it has at least
`
`[HEADl NL]+NL NL and an optional set of (name, value) pairs.
`
`Some Example Messages
`Asequence of messages Will noW be shoWn and discussed
`to illustrate aspects of chat methodology used in illustrative
`embodiments of the present invention. In these example
`messages, a tWo-line command sequence appears as, for
`example,
`2
`11.
`The syntax and semantics for all instances of this useful,
`but arbitrary, command sequence Will not be presented, but
`the command function and results appear in the messages
`and associated discussion. Other particular commands and
`command sequences Will prove useful in particular contexts,
`as Will be apparent to those skilled in the art.
`For purposes of the illustrative example messages, it is
`assumed that the session involves users DaWn, Mike and
`Dave. Initially, DaWn is preparing to initiate a conversation
`With Mike. The folloWing illustrative initiate chat message
`re?ects DaWn’s use of her client softWare from her terminal
`to indicate that she Would like to initiate a chat. The message
`is sent from her client to a communications server.
`Message-Begin
`<Session Id>
`2
`11
`ChatRoomNamez<User Speci?ed Room Name>
`UID:<User’s unique Id for the Session>
`UIDNameListz<comma separated list of participants’
`UID for this
`Chat Session excluding the Chat room Creator>
`Message-End
`Information for this message is conveniently entered in a
`WindoW created by the client softWare at DaWn’s terminal,
`e.g., in response to selecting an “Initiate Chat” button from
`a menu or the like presented by an opening (or other) screen
`on DaWn’s client. An example WindoW of this type is shoWn
`in FIG. 3. Because the client softWare is aWare of the
`initiator’s (DaWn’s) User ID, it is not necessary for her to
`explicitly enter this UID.
`When the initiate chat message given above is received at
`the server, it is parsed and processed in accordance With the
`folloWing illustrative pseudo code:
`
`Facebook and WhatsApp Exhibit No. 1006
`Page 10
`
`

`
`US 6,212,548 B1
`
`Code-Begin
`If (ChatRoomName+Creator-Id already present in the list of Chat Rooms)
`
`send the following error response for the Chat Room
`Creation Request:
`Message-Begin
`<Session Id>
`2
`12
`errorCode:6 errorstring:Duplicate Chat Room
`ChatRoomName: <ChatRoomName+Creator-Id> UID:<User’s unique Id
`for the Session> UIDList:<comma separated list of participants’ UID for
`this Chat Session excluding the Chat room Creator)
`Message-End
`}
`else
`
`Add the Chat Room to the list of active Chat Rooms; pair; Extract the
`List of participants from the NickNameList N/V pair;
`Send the following Response Message to the Chat Room Creator and all
`the participants of the chat room:
`Message-Begin <Session Id>
`2
`12
`
`ChatRoomName:<ChatRoomName+Creator-Id> UID:<User’s unique Id for the
`Session> UIDList:<comma separated list of participants’ UID for this Chat
`Session excluding the Chat room Creator)
`Message-End
`
`When the message is received by the client software residing on conversation
`participants’ terminals, the following processing illustratively transpires:
`// processing by the Creator
`if (creation of chat room is successful)
`
`if (there is no other chat room with the same name exist)
`
`display a chat room with just the room name
`
`else
`
`display a chat room with the room + creator’s id
`modify the name of the other chat room with the same name to
`room name + creator’s id (this is creator of this room)
`
`else
`
`display an error message informing the error
`
`// processing by rest of the participants
`if (there is no other chat room with the same name exist)
`
`display a chat room with just the room name
`
`else
`
`display a chat room with the room + creator’s id
`modify the name of the other chat room which has the same
`name to room name + creator’s id (this is creator of this room)
`Note that the participants do not ordinarily receive an error message for creation
`of a chat room.
`
`invention, any participant in a chat room can add a new
`FIGS. 4A—C illustrate a continuation of the foregoing
`eXZIIIIPIQ There, Dawn and Mike View their COIlVerSaIiOIl in 55 participant to that chat room. To effect the desired addition
`reSPeCFiV§WiI1d0WS~ Mike is Preparing to Send a message to
`the following message is sent by a client, such as the client
`Dawn indicating that he is about to add Dave to the chat. In
`at Mike’s terminal to the Server:
`accordance with one illustrative embodiment of the present
`
`Message-Begin
`<Session Id>
`2
`13
`ChatRoomName:<ChatRoomName+Creator-Id>
`
`Facebook and WhatsApp Exhibit No. 1006
`Page 11
`
`

`
`US 6,212,548 B1
`
`10
`
`9
`
`-continued
`
`UID:<user issuing the request>
`UIDList:<comma separated list of participants’ UID to be added to this chat
`room>
`
`Message-End
`Upon receiving the above message, the server performs the following processing:
`Code-Begin
`If (ChatRoomName+Creator-Id does not exist)
`{
`
`send the following error response for the Chat Room Creation Request:
`Message-Begin
`<Session Id>
`2
`14
`errorCode:7
`errorString:Invalid chatroomname
`ChatRoomName:<ChatRoomName+Creator-Id>
`Message-End
`
`}
`else if (user issuing the request is not a participant of this chat room)
`{
`
`send the following error response for the Chat Room Creation Request:
`Message-Begin <Session Id>
`2
`14
`errorCode: 8
`errorString:Participant does not eXist in the room
`ChatRoomName:<ChatRoomName+Creator-Id>
`Message-End
`
`else
`
`eXtract the list of participants from the message, add them to the
`list of participants in the room. Broadcast the following message
`to all the participants in the room.
`Message-Begin
`<Session Id>
`2
`14
`ChatRoomName:<ChatRoomName+Creator-Id>
`UID:<user who issued the add request>
`UIDList:<comma separated list of UIDs for participants who have been
`added to this chat room>
`Message-End
`
`}
`Upon receiving the above message the client software residing on conversation
`participants’ terminals performs the following:
`// Processing by the user who issued the add if adding the participant
`was successful
`
`add this participant to list of active users in the corresponding
`chat room
`
`//processing by the client for the participant who was added
`if (there is no other chat room with the same name exist)
`
`display a chat room with just the room name
`
`else
`
`display a chat room with the room + creator’s id
`modify the name of the other chat room which has the same
`name to room name + creator’s id (this is creator of this room)
`
`//processing by rest of the participants add this participant to list of
`active users in that corresponding chat room.
`
`55
`
`FIGS. 5A—C show screens at the terminals of Dawn,
`Mike, and Dave for viewing of their conversation after Dave
`has been added.
`Broadcasting a Message in a Chat Room
`Any Participant in a chat room can broadcast a message 60
`to all participants in that chat room. The following illustrates
`a typical process in which a message is sent by a client to the
`server:
`
`Facebook and WhatsApp Exhibit No. 1006
`Page 12
`
`

`
`US 6,212,548 B1
`
`11
`
`12
`
`Message-Begin
`<Session Id>
`2
`19
`ChatRoomName:<ChatRoomName+Creator-Id>
`UID:<user broadcasting the message>
`Message:<message to be broadcast>
`Message-End
`Upon receipt of the above message the receiving server performs the following:
`Code-Begin
`If (ChatRoomName+Creator-Id does not eXist)
`
`send the following error response for the Chat Room Creation Request:
`Message-Begin
`<Session Id>
`2
`2O
`errorCode:7
`errorString:Invalid chatroomname
`ChatRoomName:<ChatRoomName+Creator-Id>
`Message-End
`
`}
`else if (user issuing the request is not a participant of this chat room)
`
`send the following error response for the Chat Room Creation Request:
`Message-Begin
`<Session Id>
`2
`
`errorCode:8 errorString:Participant do