U.S. patent application number 14/052408 was filed with the patent office on 2014-02-06 for multi-user chat.
This patent application is currently assigned to Google Inc.. The applicant listed for this patent is Google Inc.. Invention is credited to Reza Behforooz, Qi Ke, Deepak Menon, Justin Uberti.
Application Number | 20140040784 14/052408 |
Document ID | / |
Family ID | 50026789 |
Filed Date | 2014-02-06 |
United States Patent
Application |
20140040784 |
Kind Code |
A1 |
Behforooz; Reza ; et
al. |
February 6, 2014 |
MULTI-USER CHAT
Abstract
A method for providing a multi-user chat includes: receiving a
request from a first participant to initiate a first live chat with
a second participant; receiving a request from the first or second
participants to invite a third participant to the first live chat;
establishing the first live chat having multiple participants
including at least the first, second, and third participants;
receiving from one of the multiple participants a selection of one
of the other participants in the first live chat from a participant
indicator field after establishing the first live chat among the
multiple participants; and displaying a live chat area separate
from a displayed area for the first live chat that allows the
participant who made the selection and the participant who was
identified by the selection to chat between themselves in a second
live chat that is not displayed to other participants of the first
live chat.
Inventors: |
Behforooz; Reza; (Seattle,
WA) ; Uberti; Justin; (Kirkland, WA) ; Menon;
Deepak; (Redmond, WA) ; Ke; Qi; (Kirkland,
WA) |
|
Applicant: |
Name |
City |
State |
Country |
Type |
Google Inc. |
Mountain View |
CA |
US |
|
|
Assignee: |
Google Inc.
Mountain View
CA
|
Family ID: |
50026789 |
Appl. No.: |
14/052408 |
Filed: |
October 11, 2013 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
11765908 |
Jun 20, 2007 |
|
|
|
14052408 |
|
|
|
|
Current U.S.
Class: |
715/758 |
Current CPC
Class: |
H04L 65/1093 20130101;
H04L 12/1822 20130101; H04L 65/403 20130101 |
Class at
Publication: |
715/758 |
International
Class: |
H04L 29/06 20060101
H04L029/06 |
Claims
1. A method for providing a multi-user chat, comprising: receiving,
by a computing device, a request from a first participant to
initiate a first live chat with a second participant; receiving, by
the computing device, a request from either the first participant
or the second participant to invite a third participant to the
first live chat; establishing, by the computing device, the first
live chat having multiple participants including at least the
first, second, and third participants; receiving, by the computing
device, from one of the multiple participants a selection of one of
the other participants in the first live chat from a participant
indicator field after establishment of the first live chat among
the multiple participants; and displaying, by the computing device,
a live chat area separate from a displayed area for the first live
chat that allows the participant who made the selection and the
participant who was identified by the selection to chat between
themselves in a second live chat that is not displayed to other
participants of the first live chat.
2. The method of claim 1, wherein the live chat area comprises a
separate window from the displayed area for the first live
chat.
3. The method of claim 1, wherein the computing device comprises a
multi-user instant messaging server.
4. The method of claim 1, wherein the participant indicator field
includes a listing of participants included in the live chat.
5. The method of claim 1, wherein receiving the selection of one of
the other participants from the participant indicator field
comprises receiving an indication that one of the participants has
clicked on a name displayed in the participant indicator field or
has hovered over a name displayed in the participant indicator
field.
6. The method of claim 1, wherein the live chat area includes
presence information corresponding to the participant who was
identified by the selection and/or an avatar corresponding to the
participant who was identified by the selection.
7. The method of claim 1, wherein the live chat area includes an
email link, and wherein the live chat area allows the participant
who made the selection to open a draft email to the participant who
was identified by the selection by selecting the email link.
8. The method of claim 1, wherein the sidebar window includes a
call link, and wherein the live chat area allows the participant
who made the selection to initiate a computer network-based
telephone call to the participant who was identified by the
selection by selecting the call link.
9. The method of claim 8, wherein the computer network-based
telephone call comprises a voice over IP (VoIP) telephone call.
10. A system for providing a multi-user chat, comprising: a
multi-user instant messaging (IM) server configured to: receive a
request from a first participant to initiate a first live chat with
a second participant, receive a request from either the first
participant or the second participant to invite a third participant
to the first live chat, establish the first live chat having
multiple participants including at least the first, second, and
third participants, receive from one of the multiple participants a
selection of one of the other participants in the first live chat
from a participant indicator field after establishment of the first
live chat among the multiple participants, and displaying a live
chat area separate from a displayed area for the first live chat
that allows the participant who made the selection and the
participant who was identified by the selection to chat between
themselves in a second live chat that is not displayed to other
participants of the first live chat.
11. The system of claim 10, further comprising a connection manager
that maintains connection information associated with the
participants included in the first and second live chats.
12. The system of claim 10, wherein the participant indicator field
includes a listing of participants included in the first live
chat.
13. The system of claim 10, wherein receiving the selection of one
of the other participants in the first live chat from the
participant indicator field comprises receiving an indication that
one of the participants has clicked on a name displayed in the
participant indicator field.
14. The system of claim 10, wherein receiving the selection of one
of the other participants in the first live chat from the
participant indicator field comprises receiving an indication that
one of the participants has hovered over a name displayed in the
participant indicator field.
15. The system of claim 10, wherein the live chat area includes
presence information corresponding to the other participant that
was selected, and/or wherein the live chat area includes an avatar
corresponding to the other participant that was selected.
16. The system of claim 10, wherein the live chat area includes an
email link, and wherein the live chat area allows the participant
who made the selection to open a draft email to the participant who
was identified by the selection by selecting the email link.
17. The system of claim 10, wherein the sidebar window includes a
call link, and wherein the sidebar window allows the participant
who made the selection to initiate a computer network-based
telephone call to the participant who was identified by the
selection by selecting the call link.
18. The system of claim 17, wherein the computer network-based
telephone call comprises a voice over IP (VoIP) telephone call.
19. The system of claim 10, further comprising a state manager
device configured to maintain: a number of participants included in
the first and second live chats; identities of the participants
included in the first and second live chats; and an order of
messages input by the participants included in the first and second
live chats.
20. A system, comprising: a first display device configured to
display a first chat area for displaying chat messages of a first
live chat between multiple participants that includes at least
first, second, and third participants, wherein the first
participant initiated the first live chat with the second
participant, and wherein either the first participant or the second
participant invited the third participant to the first live chat; a
second display device configured to display the first chat area;
and a third display device configured to display the first chat
area; wherein one of the multiple participants selects of one of
the other participants in the first live chat from a participant
indicator field included in the first chat area, and where a subset
of the first, second, and third display devices is configured to
display a second chat area separate from the first chat area that
allows the participant who made the selection and the participant
who was identified by the selection to chat between themselves in a
second chat that is not displayed to other participants of the
first live chat.
Description
CROSS-REFERENCE TO RELATED APPLICATIONS
[0001] The application is a continuation of U.S. patent application
Ser. No. 11/765,908, filed on Jun. 20, 2007, which is hereby
incorporated by reference herein in its entirety.
BACKGROUND
[0002] The present invention relates to web communication and
archiving, particularly to web communication between three or more
users.
[0003] The emergence and development of computer networks and
protocols, including the World Wide Web (or simply "the web"), now
allows many remote users to communicate with one another. Different
types of communication tools have been developed for the web, which
allow users to communicate in different ways through a browser. One
popular type of communication tool is instant messaging (also
called chat). Instant messaging (IM) allows users to communicate
over the web in real time. A user uses a client program (called an
IM client) that communicates with an instant messaging service over
the web. The IM client has a graphical user interface (GUI) that
allows a user to input text and view text.
[0004] IM communication generally involves typing text. For
example, two users chatting may type lines of text in each of their
IM client programs. The instant messaging service passes the typed
text between the IM clients. The lines of text may resemble a
conversation in that successive lines of text are displayed in a
temporal sequence along with an indication of the user who typed
the text. Often this indication of the user is a display of the
user's screen name (also called an IM address). A compilation of
these messages exchanged between the users is commonly referred to
as a chat. IM clients have historically had simple GUIs with
rectangular window displays in which the text of a chat is made to
scroll as the conversation proceeds.
[0005] Different IM services and IM client programs have different
features relating to the chat experience. For example, IM services
often provide presence information that indicates whether people on
a user's list of contacts are currently online and available to
chat. Some IM services also allow a user to set an "online status"
or "away message" so that other users are aware of the user's
availability to chat. Finally, users can often personalize their
profiles to change graphical features associated with their chat.
For instance, a user often has a screen name which is displayed to
another to identify himself or herself when he or she is chatting.
The screen name itself may be selected by the user (or assigned by
the IM service). A user may also choose different font colors, font
styles, symbols, or personalized images to be displayed along with
his or her screen name. An example IM service includes the Google
Talk service from Google, Inc. of Mountain View, Calif.
[0006] Many existing IM services are limited to communications
between only two participants. In these systems, if a first user
wishes to interact with more than one other user, the first user
must open separate chats with each other user. This requires a user
to switch between multiple windows and transfer text from one
window to another if the user wants to share information with a
user other than the user participating in the chat. Additionally,
existing IM services provide only limited archiving capability, if
any, and the archives are not easily accessible from multiple
locations.
[0007] Users need a capability for interacting with more than one
other participant in a chat. Such users also need a capability for
accessing and searching through their previous chats.
SUMMARY
[0008] Embodiments of the present invention relate to enabling
access to a multi-user chat archive. In one embodiment, a computer
network-based live chat having three or more participants is
hosted. A record of the live chat is archived in a central location
accessible by each of the participants. The archived record is
provided to a requesting participant after completion of and/or
during the live chat. The requesting participant may be, for
example, any one of the three or more participants. The requesting
participant may make the request from any remote location in
communication with the central location.
[0009] In another embodiment, a system for enabling access to a
multi-user chat archive includes a multi-user instant messaging
(IM) server, a state manager, an archive database, and an archive
manager. The IM server is configured to receive a chat message from
a first participant during a live chat and distribute the chat
message to at least a second participant and a third participant
during the live chat. The state manager is configured to identify
the first, second, and third live chat participants. The archive
database is configured to store an archived record of the live chat
in a central location. The archive manager is configured to send
the archived record to the archive database for storage and
retrieve the archived record from the archive database upon request
from a participant of the live chat. In this embodiment, the
central location is accessible by each of the chat participants
from any remote location in communication with the central
location.
[0010] Further embodiments, features, and advantages of the
invention, as well as the structure and operation of the various
embodiments of the invention are described in detail below with
reference to accompanying drawings.
BRIEF DESCRIPTION OF THE FIGURES
[0011] Embodiments of the invention are described with reference to
the accompanying drawings. In the drawings, like reference numbers
may indicate identical or functionally similar elements. The
drawing in which an element first appears is generally indicated by
the left-most digit in the corresponding reference number.
[0012] FIG. 1 is a diagram of an exemplary system for providing
instant messaging (IM) capabilities between three or more users
according to an embodiment of the present invention.
[0013] FIG. 2 is a diagram of an example two-user IM system.
[0014] FIG. 3 is a flowchart of an exemplary routine for archiving
messages according to an embodiment of the present invention.
[0015] FIG. 4 is a flowchart of an exemplary routine for hosting a
live chat according to an embodiment of the present invention.
[0016] FIG. 5 is a flowchart of another exemplary routine for
hosting a live chat according to an embodiment of the present
invention.
[0017] FIG. 6 is an illustration of an exemplary live chat window
according to an embodiment of the present invention.
[0018] FIG. 7 is an illustration of another exemplary live chat
window according to an embodiment of the present invention.
[0019] FIG. 8 is an illustration of yet another exemplary live chat
window according to an embodiment of the present invention.
[0020] FIG. 9 is an illustration of still another exemplary live
chat window according to an embodiment of the present
invention.
[0021] FIG. 10 is an illustration of an exemplary archived record
window according to an embodiment of the present invention.
[0022] FIG. 11 is an illustration of another exemplary archived
record window according to an embodiment of the present
invention.
[0023] FIG. 12 is an illustration of an exemplary archive search
result returned according to an embodiment of the present
invention.
[0024] FIG. 13 is an illustration of another exemplary archive
search result returned according to an embodiment of the present
invention.
[0025] FIG. 14 is a diagram of a web connection server supporting
IM with linked archiving, presence, and web connectivity according
to an embodiment of the present invention.
[0026] FIG. 15 is a diagram of an example IM client according to an
embodiment of the present invention.
DETAILED DESCRIPTION OF EMBODIMENTS
[0027] While the present invention is described herein with
reference to illustrative embodiments for particular applications,
it should be understood that the invention is not limited thereto.
Those skilled in the art with access to the teachings provided
herein will recognize additional modifications, applications, and
embodiments within the scope thereof and additional fields in which
the invention would be of significant utility.
[0028] The terms "instant messaging" (IM) and "chat" are used
interchangeably herein to refer broadly and inclusively to any
instant messaging application, protocol, framework or service as
would be apparent to a person skilled in the art given this
description. An example IM service (including an IM server and/or
IM client) which may be adapted to incorporate embodiments of the
present invention as described herein includes, but is not limited
to, the Google Talk service from Google, Inc. of Mountain View,
Calif.
[0029] FIG. 1 is a diagram of a system 100 for providing IM
capabilities between three users A, B, and C according to an
embodiment of the present invention. Although system 100 is
described herein with reference to three users, one of skill in the
art will recognize that system 100 may also be utilized in
providing IM capabilities between more than three users or less
than three users without departing from the spirit and scope of the
present invention. System 100 includes a browser 102A coupled to a
central IM server 104 over one or more networks 108. Browser 102A
includes an IM client 106A associated with user A. System 100 also
includes a browser 102B coupled to IM server 104. Browser 102B
includes an IM client 106B associated with user B. System 100
further includes a browser 102C coupled to IM server 104. Browser
102C includes an IM client 106C associated with user C.
[0030] Central IM server 104 may utilize various other networked
components to support communication between users A, B, and C. As
will be described in further detail below, IM server 104 may be
coupled to a state manager 110, a connection manager 112, and an
archive manager 114. State manager 110 may in turn be coupled to a
state backup storage 118. Archive manager 114 may be coupled to an
archive database 120. Connection manager 112 may be coupled to an
IM connection register 124. Each of these couplings may exist as a
direct connection or may exist as an indirect connection through
network 108.
[0031] Network 108 can be any network or combination of networks
that can carry data communication, and may be referred to herein as
a computer network. Such network 108 can include, but is not
limited to, a local area network, medium area network, and/or wide
area network such as the Internet. Network 108 can support
protocols and technology including, but not limited to, World Wide
Web protocols and/or services. Intermediate web servers, gateways,
or other servers may be provided between components of system 100
depending upon a particular application or environment.
[0032] Client browsers 102A, 102B, 102C and IM clients 106A, 106B,
106C can be implemented in software, firmware, hardware, or any
combination thereof. Client browsers 102A, 102B, 102C and IM
clients 106A, 106B, 106C can be implemented to run on any type of
processing device including, but not limited to, a computer,
workstation, distributed computing system, embedded system,
stand-alone electronic device, networked device, mobile device,
set-top box, television, or other type of processor or computer
system. Such a processing device implementing a client browser
and/or an IM client may be referred to herein as a remote client
device. Client browsers 102A, 102B, 102C and IM clients 106A, 106B,
106C can also be used in a variety of applications in combination
with instant messaging, or in instant messaging alone.
[0033] Similarly, IM server 104, state manager 110, connection
manager 112, and archive manager 114 can be implemented in
software, firmware, hardware, or any combination thereof. IM server
104, state manager 110, connection manager 112, and archive manager
114 can be implemented to run on any type of processing device
including, but not limited to, a computer, workstation, distributed
computing system, embedded system, stand-alone electronic device,
networked device, mobile device, set-top box, television, or other
type of processor or computer system. IM server 104, state manager
110, connection manager 112, and archive manager 114 can also be
used in a variety of applications in combination with instant
messaging, or in instant messaging alone.
[0034] System 100 can be used as a stand-alone system or in
connection with a search engine, web portal, or other web site to
allow three or more remote users to engage in instant messaging. IM
server 104, state manager 110, connection manager 112, and archive
manager 114 can operate alone or in tandem with other servers, web
servers, or devices and can be part of any search engine, portal,
or web site.
[0035] Functionality described herein is described with respect to
components or modules for clarity. However, this is not intended to
be limiting, as functionality can be implemented on one or more
modules on one device or distributed across multiple devices.
[0036] In operation, IM server 104 manages the overall
communication between IM clients 106A, 106B, 106C. When users A, B,
C begin chatting, IM clients 106A, 106B, 106C each provide a user
interface that includes a conversation window for users A, B, C to
input their respective chat message. Optional presence information
may also be made available so that users A, B, C know if they are
available to chat, or if others are available to chat.
[0037] In a three-person chat, for example, a first IM participant,
such as user A, inputs a chat message to IM client 106A. IM client
106A sends the chat message through browser 102A to IM server 104.
Upon receipt of the chat message and appropriate data from other
components of system 100, as will be described below, IM server 104
transmits the chat message through browsers 102B, 102C to IM
clients 106B, 106C for receipt by users B, C. Such communication
between users is significantly different for IM systems having
three or more users compared to IM systems that allow communication
between only two users.
[0038] FIG. 2 is a diagram of a typical two-user IM system 200.
System 200 includes a browser 202A coupled to an IM server 204A
over a network 206. Browser 202A further includes an IM client 208A
associated with a user A. A browser 202B is also coupled to an IM
server 202B over network 206. Browser 202B further includes an IM
client 208B associated with a user B. IM server 204A is further
coupled to IM server 204B over network 206.
[0039] In operation, IM server 204A manages instant messaging with
IM client 208A. IM server 204B manages instant messaging with IM
client 208B. As the users chat, IM clients 208A, 208B pass chat
messages to respective IM servers 204A, 204B. The chat messages are
forwarded between IM servers 204A, 204B, and from there, forwarded
to respective IM clients 208A, 208B. These type of two-user IM
systems tend to be stateless, in that two users are signed into an
IM network and send messages back and forth to each other using a
dynamic chat connection. IM clients 208A, 208B typically
incorporate an addressing scheme into a sent message to route the
message to the intended recipient. The connection between IM
servers 204A, 204B does not need to be persistent, as long as a
pathway exists between the two users. In the event that a server
between the two users fails (such as, for example, IM server 204A
or IM server 204B), the chat connection can be rerouted through a
different server using the addressing scheme.
[0040] IM systems allowing three or more users are not so simple.
When one user sends a chat message, the message is not
automatically addressed to a participant on the other end of the IM
connection. Instead, state information may be required to keep
track of which users are participating in the conversation, which
users are allowed to participate in the conversation, the order of
messages input by users, etc. Keeping this state information may
require a dedicated resource on the IM network. In an embodiment,
keeping the state information also may require that the state
information be backed up in the event that a server fails, so that
the chat can continue uninterrupted without losing chat participant
details.
[0041] Accordingly, in system 100 of FIG. 1, IM server 104 is
coupled to state manager 110. State manager 110 maintains, for
example and without limitation, a record of the number of chat
participants, the identities of chat participants, and the order of
messages input by chat participants. State manager 110 may transfer
state information to state backup storage 118 for later retrieval.
State backup storage 118 may be accessible by any number of systems
200, so that the chat between the participants may be rerouted
while state information is maintained, if a component of system 200
fails. Although state backup storage 118 is illustrated in FIG. 1
as being in direct communication with state manager 110, one of
skill in the art will recognize that state manager 110 may also
communicate with state backup storage 118 via network 108.
[0042] IM server 104 is also coupled to connection manager 112.
Connection manager 112 maintains connection information associated
with the chat participants and IM server 104. Connection
information may include, for example and without limitation, a
location and/or network address. Connection manager 112 may further
maintain connection information between client servers 106A, 106B,
106C associated with the chat participants and IM server 104.
Connection manager 112 may maintain connection information using,
for example, an IM connection register 124. Connection manager 112
has the capability to add users to or remove users from a live chat
upon instruction from IM server 104. In one embodiment, connection
manager 112 is part of IM server 104. In another embodiment,
connection manager 112 is a standalone module. Although IM
connection register 124 is illustrated in FIG. 1 as being in direct
communication with connection manager 112, one of skill in the art
will recognize that connection manager 112 may also communicate
with IM connection register 124 via network 108.
[0043] Some existing IM systems have an archiving capability that
records a transcript of a chat on the user's remote client device.
For example, the transcript may be recorded on a hard drive of the
user's personal computer. Such a transcript is accessible only to a
user having access to that remote device. If the user changes
devices, the user can no longer access the transcript.
Additionally, the transcript stored by these systems primarily
includes only the text components of the chat, but not multimedia
components of the chat.
[0044] In an embodiment of the present invention, to allow a user
to access a chat in which the user previously participated, chat
records are archived by archive manager 114 in archive database
120. Archive database 120 is centrally located, and is accessible
from any remote location through network 108. Although archive
database 120 is illustrated in FIG. 1 as being in direct
communication with archive manager 114, one of skill in the art
will recognize that archive manager 114 may also communicate with
archive database 120 via network 108.
[0045] In one embodiment, as messages are passed between users A,
B, C in a live chat, archive manager 114 associates the messages
with a live chat identifier and stores them as a record in archive
database 120 under the associated live chat identifier. In another
embodiment, archive manager 114 stores the entire chat as a record
in archive database 120 under a live chat identifier once the live
chat is complete. In addition to any text component of a live chat,
archive manager 114 stores one or more multimedia components of the
live chat. A multimedia component may include, for example and
without limitation, a video component of the live chat (e.g.,
wherein video from the participants is broadcast as part of the
live chat), an audio component of the live chat (e.g., wherein
audio from the participants is broadcast as part of the live chat),
a URL associated with the live chat, and/or a file transferred
through the live chat. Storage of both text components and
multimedia components of a chat at a central location ensure that
all components of the chat can be easily accessed by any chat
participant once the participant has exited the chat. In addition
to the live chat identifier, archive manager 114 may also associate
each archived record with one or more participant identifiers, so
that only those users who participated in the original chat are
able to access the archived record at a later date. The participant
identifier may include, for example, the username and/or identity
of each participant in the original chat. In one embodiment,
archive manager 114 indexes the archived record by, for example and
without limitation, a participant of the live chat, a date of the
live chat, a keyword, and/or a multimedia component of the
chat.
[0046] Archive manager 114 may include a filter 122 that allows a
user to search through chats stored in archive database 120. Filter
122 may receive a search term input by a user, identify one or more
archived records corresponding to the search term, and return the
one or more identified archived records to the user. If the
archived records are associated with a participant identifier,
filter 122 may identify only those archived records corresponding
to the search terms that also have a participant identifier
matching an identifier of the requesting user. This search
functionality will be further described below.
[0047] Embodiments and the operation of system 100 are further
described with respect to routines 300, 400 and 500 in FIGS. 3, 4
and 5. Routines 300, 400 and 500 will be described with reference
to system 100 but are not necessarily limited to the structure of
system 100.
[0048] FIG. 3 illustrates an exemplary routine 300 for archiving
messages in a central location for later access according to an
embodiment of the present invention. In step 302, a live chat is
hosted between three or more users. The live chat may be hosted by,
for example, IM server 104. Hosting of a live chat may occur in
various ways.
[0049] FIG. 4 illustrates a routine 400 for hosting a live chat
having three or more participants according to an embodiment of the
present invention. In step 402, a request is received from a first
participant, referred to herein as User A, to initiate a live chat
with a second participant, referred to herein as User B. The
request may be received by, for example, IM server 104.
[0050] In step 404, state information corresponding to the chat
between User A and User B is determined and stored. The state
information may be stored, for example, by state manager 110 in
state backup storage 118. As discussed above, state information may
include, for example and without limitation, the identity of users
invited to the chat, the identity of users participating in the
chat, the number of chat participants, and the order in which chat
messages are received.
[0051] In step 406, an IM connection register is established for
connections between User A and User B. In an embodiment, the IM
connection register is established to track respective network
addresses used by User A and User B. The network addresses may be,
for example, network addresses of IM clients 106A, 106B in system
100. The IM connection register may be established by, for example,
information from connection manager 112 as connection register
124.
[0052] In one example implementation of step 406, IM server 104
retrieves participant identifiers for User A and User B from state
manager 110. IM server 104 forwards the participant identifiers to
connection manager 112. Connection manager 112 determines a
location, such as a network address, for each of User A and User B
using, for example, IM connection register 124. Connection manager
112 provides the location for each of User A and User B to IM
server 104, which uses the location information to establish an IM
connection and pass messages between User A and User B.
[0053] Transmitting messages between users in this manner is
different from a typical chat room, in which a dedicated resource
is always available, even when there is no or only one participant
in the chat. Typical chat rooms provide the ability for a user to
enter an open chat room and wait for other users to join. Users of
a typical chat room also cannot send a request through the chat
room for other users to join the chat room. Dedicated chat rooms
also carry the danger of abuse, because there is no need for users
of a chat room to be acquainted prior interaction in the chat room.
In comparison, the IM connection discussed herein requires that
each additional participant be specifically invited to the chat by
the first participant. Typically, there will be some identity
awareness between the participants, since a first user often has to
request the permission of a second user to either include the
second user on their IM contact list or to send the second user a
chat message.
[0054] In step 408, a request is received to add a third
participant, referred to herein as User C, to the existing live
chat between User A and User B. In one embodiment, the request to
add User C may be made by either User A or User B. In an
alternative embodiment, the request to add User C may require
approval from all participants of the chat. The request may be
received by, for example, IM server 104.
[0055] In step 410, the state information corresponding to the live
chat is updated to include state information for User C. In the
example of FIG. 1, the state information may be updated by state
manager 110 and stored in state backup storage 118.
[0056] In step 412, connection information associated with User C
is added to existing IM connection register 124.
[0057] In step 414, a chat message input by one of the chat
participants is received. The chat message may be received by, for
example, IM server 104. For purposes of this example, the chat
message is received from User A.
[0058] In step 416, state information associated with the live chat
is consulted to determine the participants of the live chat. For
example, IM server 104 may request state information from state
manager 110 to identify User A, User B, and User C as participants
in the live chat. Since User A sent the original chat message, IM
server 104 can determine that all identified users other than User
A should receive the chat message.
[0059] In step 418, the chat message is distributed to the
remaining participants of the live chat. In the example above,
since User A is the sender of the original chat message, IM server
104 transmits the chat message to User Band User C.
[0060] FIG. 5 is a routine 500 for hosting a live chat having three
or more participants according to another embodiment of the present
invention. In routine 400, a chat is first established between two
users with a third user being added at a later time. In routine
500, however, the chat is initially established between all three
users.
[0061] In step 502, a request is received from a first participant,
referred to herein as User A, to initiate a live chat with a second
participant, referred to herein as User B, and a third participant,
referred to herein as User C. The request may be received by, for
example, IM server 104.
[0062] In step 504, state information corresponding to the chat
between User A, User B, and User C is determined and stored. The
state information may be stored, for example, by state manager 110
in state backup storage 118. As discussed above, state information
may include, for example and without limitation, the identity of
users invited to the chat, the identity of users participating in
the chat, the number of chat participants, and the order in which
chat messages are received.
[0063] In step 506, an IM connection register is established using
connection information associated with User A, User B, and User C.
In an embodiment, the IM connection register may be created using
respective network addresses for User A, User B, and User C. The
network addresses may be, for example the network addresses of IM
clients 106A, 106B, 106C in system 100. The IM connection register
may be established by, for example, connection manager 112, as
described with respect to step 406 in FIG. 4.
[0064] In step 508, a chat message input by one of the chat
participants is received. The chat message may be received by, for
example, IM server 104. For purposes of this example, the chat
message is received from User A.
[0065] In step 510, state information associated with the live chat
is consulted to determine the participants of the live chat. For
example, IM server 104 may request state information from state
manager 110 to identify User A, User B, and User C as participants
in the live chat. Since User A sent the original chat message, IM
server 104 can determine that all identified users other than User
A should receive the chat message.
[0066] In step 512, the chat message is distributed to the
remaining participants of the live chat. In the example above,
since User A is the sender of the original chat message, IM server
104 transmits the chat message to User B and User C.
[0067] FIGS. 4 and 5 thereby illustrate example routines for
hosting a live chat between three or more users in accordance with
step 302 of FIG. 3. Returning to FIG. 3, routine 300 proceeds to
step 304.
[0068] In step 304, a record of the live chat is archived in a
central location that is accessible by any of the participants of
the chat. In system 100 of FIG. 1, archive manager 114 stores the
chat in archive database 120. Archive manager 114 may assign the
archived record a live chat identifier. The archiving may occur on
a per-message basis (that is, every time a chat message is received
and/or transmitted within the chat). Alternatively, the archiving
may occur after the live chat is complete. The record of the live
chat stored in step 304 includes not only a text component of the
live chat, but may also include one or more multimedia components.
A multimedia component may include, for example and without
limitation, a video component of the live chat, an audio component
of the live chat, a URL associated with the live chat, and/or a
file transferred through the live chat.
[0069] In step 306, a request for an archived record is received
from a user. As will be described in further detail below, the
request may be received when the user selects a link within a
separate live chat window. Alternatively, the request may be
received when the user selects a link within a network-based
electronic mail user interface. As will be recognized by one of
skill in the art, other modes of requesting an archived record by a
user can be exercised without departing from the spirit and scope
of the present invention. Such a request may be received by, for
example, IM server 104 which then passes the information to archive
manager 114.
[0070] Step 308 is an optional step. In step 308, archived records
are filtered according to a search term input by the user. The
search term may be one or more of, for example and without
limitation, a name of a participant of the live chat, a date of the
live chat, or a keyword. The search capability allows a user, among
other things, to revisit chats with one or more specific
participants, chats held on a specific date provided by the user,
and/or chats related to a specific subject matter (as determined by
the keyword input by the user). In the example of system 100, one
or more search terms may be received by IM server 104. IM server
104 transmits the received search term(s) to filter 122 in archive
manager 114. Filter 122 accesses archive database 120 and
identifies one or more archived records in archive database 120
that correspond to the search term(s). The identified archived
record(s) are then returned to IM server 104 by archive manager 114
and transmitted to the requesting user by IM server 104. The search
term may be sent by the user, for example and without limitation,
through a textbox in a live chat window or through a textbox in a
network-based electronic mail user interface.
[0071] In step 310, the archived records are filtered so that only
chats in which the requesting user was a participant are returned
to the requesting user. One of skill in the art will recognize that
step 310 may occur before or after step 308. In an exemplary
embodiment, an identifier of the requesting user (e.g., a username)
is compared to an identifier associated with a corresponding
archived record (e.g., a participant identifier). If the
identifiers match, then the archived record may be returned to the
requesting user. If the identifiers do not match, then the archived
record may not be returned to the requesting user. In system 100,
step 310 may be performed by, for example, filter 122 in archive
manager 114.
[0072] In step 312, one or more filtered archived records are
returned to the requesting user. The archived records may be
returned in a list format, allowing the requesting user to select a
specific archived record for full display with all associated text
and multimedia components. Alternatively, the archived records may
be returned in full format with all associated text and multimedia
components.
[0073] If a user is discussing information in a chat that is, for
example, private, sensitive, and/or confidential, the user may not
want a record of the live chat stored in a centrally accessible
location. In this instance, the user may request that the live chat
not be archived. The request may be implemented only for a single
chat session, or it may be implemented for multiple chat sessions
of the requesting user. Once the user has requested not to archive
the live chat, archive manager 114 ceases recordation of the live
chat.
Conversation Window Example
[0074] FIG. 6 is an illustration of an example live chat window
600. This window, as well as other windows illustrated herein, is
illustrative and not intended to limit the present invention to
this specific example or its features. Live chat window 600 may
include a participant indicator field 602, an invite participants
link 604, a message window 606, an input message field 608, and a
search link 610. Participant indicator field 602 may display the
display name and current presence for one or more participants of
the chat. Invite participants link 604 may be used to open a list
of contacts from which participants can be selected to invite to
join the chat. Message window 606 is an area in which chat content
from three or more participants can be displayed. Input message
field 608 is an area in which a chat message can be entered by a
user. Search link 610 allows a user to open a search window for
searching archives of previous live chats. As used herein, the term
"link" refers to any kind of link, button, selector, or other type
of user interface control element for connecting to an application
and/or executing an action from a given location.
[0075] Message windows (such as window 606) may also support
different modes such as in-page, in-line, or popout. In-page may
have the message window as part of the web page flow with fixed
width and height. An in-line mode may have a chat window inline
within a browser window, but separate from a chat contact list,
appear when a cursor is near an area. A pop-out message window may
be a message window that lives in its own browser chrome.
[0076] Other instant messaging functionality such as inputting
emoticons and playing sounds may be provided in message windows. A
message window in conjunction with a window manager may decide
whether or not to play sounds on receipt of new messages.
[0077] FIG. 7 is an illustration of an example live chat window
700. Live chat window 700 includes a participant indicator field
702, a message window 704, an input message field 706, and a search
link 708. Live chat window 700 also includes the capability of
opening a sidebar conversation between two participants in the live
chat. In an embodiment, when a first chat participant clicks on
and/or hovers over the display name for a second chat participant
in participant indicator field 702, a sidebar window 710 opens. The
sidebar window allows the first chat participant to interact
directly with the second chat participant outside of the live chat,
which has other participants. Sidebar 710 includes functions
typically available to users of two-user chat systems. For example,
sidebar 710 allows the first user to see presence information 712
and/or avatar 713 corresponding to the second user. Additionally,
sidebar 710 allows the first user to open a draft email to the
second participant via email link 714, open a new two-user chat
between the first and second users via chat link 716, initiate a
computer network-based telephone call (e.g., using VoIP protocol)
via call link 718, and various other capabilities as would be
evident to one of skill in the art.
[0078] FIG. 8 is an illustration of an example live chat window
800. In addition to a participant indicator field 802, a message
window 804, and an input message field 806, live chat window 800
includes an archives link 808. When a user wants to view an
archived record of a previous chat, the user can select archives
link 808. Selection of archives link 808 may result in a display
by, for example, archive manager 114 of archived records stored in,
for example, archive database 120.
[0079] FIG. 9 is an illustration of an example live chat window
900. In addition to a participant indicator field 902, a message
window 904, an input message field 906, and an archives link 908,
live chat window 900 includes an archives calendar 910. Archives
calendar 910 allows a user to search and/or filter archived records
by date. In an embodiment, dates on which a live chat occurred
involving the user are highlighted in archives calendar 910. This
highlighting feature allows a user to quickly identify dates on
which a live chat occurred, which simplifies the search process.
When a user selects one of the dates indicated on archives calendar
910, one or more archived records corresponding to the selected
date are displayed to the user, as illustrated in FIG. 10. In
example system 100, selection of the selected date may be
transmitted to filter 122 in archive manager 114 by IM server 104.
Filter 122 may then access archive database 120, and pull one or
more archived records from archive database 120 that correspond to
one or more chats occurring on the selected date involving the
requesting user. The one or more archived records may then be
transmitted to the requesting user through IM server 104.
[0080] FIG. 10 is an illustration of an example archived record
window 1000. Archived record window 1000 includes an archives
calendar 1002 and an archived message window 1004. Archives
calendar 1002 is similar to archives calendar 910. Instead of
displaying messages associated with a live chat, archived message
window 1004 displays messages associated with a previous chat
occurring on the date selected in archives calendar 1002. Once the
user is finished reviewing the archived record, the user can select
a return to chat link 1006, which closes archived record window
1000 and returns the user to a live chat window. Alternatively, the
user can review an archived record that occurred on a different
date by selecting that date in archives calendar 1002.
[0081] FIG. 11 is an illustration of an example archived record
window 1100. In addition to archives calendar 1102, archived
message window 1104, and return to chat link 1106, archived record
window 1100 also includes a search field 1108. In this embodiment,
once a date of interest has been selected by a user in archives
calendar 1102, the user can enter one or more search terms in
search field 1108 to further narrow the results returned in
archived message window 1104. The search may be one or more of, for
example and without limitation, a name of a participant involved in
an archived chat or a keyword included in the text of an archived
chat.
[0082] In example system 100, once a user enters a search term into
search field 1108, the search term may be transmitted to filter 122
in archive manager 114 by IM server 104. Filter 122 may then access
archive database 120, and pull one or more archived records from
archive database 120 that correspond to one or more chats occurring
on the selected date, involving the requesting user, which include
the entered search term. The one or more archived records may then
be transmitted to the requesting user through IM server 104.
[0083] FIG. 12 is an illustration of an example search result
returned in archived record window 1100. The search term entered by
user "me" is the name of another participant in a previous chat,
"Deepak", and archives calendar 1102 indicates that the date of
interest is Aug. 8, 2006. As indicated in message window 1104,
three instances of the term "Deepak" occurred on the date selected
by user "me" on the date of interest. For ease of use by the user,
instances of the search term may be highlighted in archived message
window 1104. Archived record window 1100 may also include a search
summary 1202. As illustrated in FIG. 12, search summary 1202 may
indicate the total number of instances of the search term over a
number of archived records.
[0084] FIG. 13 is an illustration of an example search result
returned using an archives calendar, such as archives calendar 1102
in archived record window 1100. In an embodiment, when a user
hovers over a date on archives calendar 1102, a search result
window 1302 opens. Search result window 1302 may include search
results corresponding to the hovered-over date. Search result
window 1302 may also include a search summary 1304. Since search
result window 1302 corresponds to a particular date, search summary
1304 may summarize the results of the search for that particular
date. Additionally, instances of the search term may be highlighted
in search result window 1302. In the example of FIG. 13, the user
has entered the term "Deepak" in search field 1108 and is hovering
over the date Jul. 31, 2006, in archives calendar 1102. Search
summary 1304 indicates that four instances of the search term
occurred in chats on the date of interest. Search result window
1302 displays the search results with the search term instances
highlighted.
Web Connection Services
[0085] According to a further embodiment, the present invention can
also include web connectivity along with presence and instant
messaging. FIG. 14 is a diagram of an example web connection server
1400 supporting IM with archiving, presence, and web connectivity
according to another embodiment of the present invention. Web
connection server 1400 can be used in place of IM server 104. Web
connection server 1400 includes a presence server 1402 and an IM
server 1404. Presence server 1402 manages presence to support
instant messaging applications. IM server 1404 manages instant
messaging between clients as described above with respect to IM
server 104.
Example IM Client Implementation
[0086] FIG. 15 is a diagram of an example IM client 1500 and its
architecture according to another embodiment of the present
invention. This example is illustrative and not intended to limit
the present invention. IM client 1500 can support multiple
platforms. IM client 1500 includes an operating system layer 1510
and a higher components layer 1520. Operating system layer 1510 can
include any operating system, including but not limited to, Linux
available from Red Hat, OS X available from Apple Corporation, or
Microsoft Windows operating system. Higher components layer 1520
can include components for carrying out various IM client
operations. In one example, web connectivity components 1522 can
manage log-in, web connectivity, and parsing. Other components 1523
can support networking, peer-to-peer, threads, and voice
operations. An IM client management layer 1524 supports FLASH
hosting, component management, window management, and process
management. A user interface layer 1526 supports a contact list,
chat window, and profile card display. In one example, the user
interface layer 1526 is implemented in Macromedia FLASH. IM client
1500 can run on any type of hardware including any type of
processing device including, but not limited to, a computer,
workstation, distributed computing system, embedded system,
stand-alone electronic device, networked device, mobile device
(such as a mobile phone), set-top box, television, game console, or
other type of processor or computer system.
[0087] A cell renderer may be used in IM client 1500 to render each
incoming message in a message window. This can support rendering of
and interaction with messages. The cell renderer can include
elements that are customizable. A motivation for using a cell
renderer for each message is that some messages can be set apart.
For example, offline messages could have a different background
color to visually set them apart from new conversation messages.
Another example of a cell renderer would be a file transfer
progress indicator. In the file transfer case, the cell renderer
may show progress of the file transfer in progress. Cell renderers
may be especially helpful when showing shared content such as a
photo or application specific messages that could trigger an action
on the current page.
[0088] Different cell renderers can be used to support regular
instant messaging. A special cell renderer may be used for messages
containing emoticons. An emoticon is a string of punctuation in the
form of a human face expressing an emotion. When an emoticon string
is recognized, a graphical icon (such as of a smiling, frowning, or
surprised face, for example) or other image can replace the
emoticon in the message. Since FLASH text fields may have very
limited support for in-lining images, however, the emoticons may
have to be overlaid on top of the text.
[0089] Using cell renderers can create an implementation hurdle in
a FLASH environment. Since each message is in a separate cell
renderer element, selection across messages is not necessarily
native to FLASH. In one implementation, since cell renderers may be
FLASH objects implementing a specific application programming
interface (API), cell renderers can be loaded externally. The
advantage of doing so is that other properties can build cell
renderers to be used for specific message types. For example, a
photosharing application, such as, PicasaWeb available from Google,
Inc., could provide a cell renderer for photos. If a PicasaWeb
picture is sent via the client to a contact, the message window
would download the cell renderer to display the PicasaWeb message
for the contact. Similarly, a photo album viewer could be created
for shared PicasaWeb photo albums, and a video viewer could be
created for videos from a video sharing service, such as, Google
Video available from Google, Inc., and/or other services.
CONCLUSION
[0090] Exemplary embodiments of the present invention have been
presented. The invention is not limited to these examples. These
examples are presented herein for purposes of illustration, and not
limitation. Alternatives (including equivalents, extensions,
variations, deviations, etc., of those described herein) will be
apparent to persons skilled in the relevant art(s) based on the
teachings contained herein. Such alternatives fall within the scope
and spirit of the invention.
* * * * *