Patent Application
20140040784
The present invention relates to web communication and archiving, particularly to web communication between three or more users.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
Accordingly, in system 100 of
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
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.
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
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.
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.
Embodiments and the operation of system 100 are further described with respect to routines 300, 400 and 500 in
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.
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.
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.
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.
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.
In step 410, the state information corresponding to the live chat is updated to include state information for User C. In the example of
In step 412, connection information associated with User C is added to existing IM connection register 124.
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.
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.
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.
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.
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.
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
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.
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.
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.
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
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.
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.
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.
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.
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.
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.
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.
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.
According to a further embodiment, the present invention can also include web connectivity along with presence and instant messaging.
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.
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.
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.
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.
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.
| Number | Date | Country | |
|---|---|---|---|
| Parent | 11765908 | Jun 2007 | US |
| Child | 14052408 | US |
