WO2010022392A1 - Techniques for associating chats with execution instances of programs - Google Patents

Abstract

Techniques for associating chats with instances of program executions. In the techniques, an observer that is separate from the instance of the program execution makes an observation of the instance, and using a pre-determined method, maps the observation to a chat. Disclosed are implementations of the techniques in which the observer is a plug-in for a web browser. The observer uses the browser's interface for notifying a plug-in of events in the browser to make observations about Web pages being interpreted by an execution instance of the browser. The observations are then mapped to the chat. The mapping may manipulate the observation and may be implemented using any information available to the plug-in. In some embodiments, the chat may have a persistence that is greater than that of the instances associated with it.

Description

PATENT APPLICATION FOR

Techniques for associating chats with execution instances of programs

Inventors: Siddhartha Gupta

Dmitry Orlovsky

James Toga

Assignee: Vi vox. Inc.

TITLE OF THE APPLICATION

Techniques for associating chats with execution instances of programs

CROSS-REFERENCE TO RELATED APPLICATIONS

The subject matter of this patent application claims priority from U.S. Provisional Patent Application 61/090960, Inventors Boni et al. Techniques for real time voice effects and broM'ser based virtual communication, filed 22 Aug 2008, which is hereby incorporated by reference in its entirety for all purposes.

STATEMENT REGARDING FEDERALLY SPONSORED RESEARCH OR DEVELOPMENT

Not applicable.

REFERENCE TO A SEQUENCE LISTING

Not applicable.

BACKGROUND OF THE INVENTION

Field of the invention

This invention relates to management of chat communications, and in particular to techniques for associating chats with execution instances of programs.

Description of related art

Chats are increasingly important in interactive computer applications. In the present context, a chat is a communication medium in which all participants in the chat may receive a communication from any other participant in the chat. Communications are received by participants in the order in which they are made. In the following, participants in a chat may be termed members of the chat. Examples of communications media that are chats are telephone party lines, conference calls, on-line voice chats, and on-line text chats.

FIG. 1 illustrates how on-line voice chats are set up in the prior art. FIG. 1 shows a number of program execution instances 103(1..n). A program execution instance is a particular execution of a program. For example, if a user of a personal computer (PC) starts up the PC's Web browser program, uses it for a while, and then shuts the web browser program down, the execution of the browser program during that period is an execution instance of the program; if the user again starts up the browser program, uses it, and shuts it down, the second execution of the browser program is a second execution instance of the browser program. As would be expected from the foregoing, executions of the browser program on different PC's or by different people on the same PC are also separate execution instances of the browser program.

In the prior art, if users for whom execution instances of a program are being executed are to be members of the same chat, the chat must be specified in code that is executed by the execution instance. For example, in FIG. 1, the program being executed by instances 103(l ..n) contains code which displays User Interface 1 15(1), which asks the user whether he or she wishes to connect to a chat channel for Red Sox fans. If the user selects "Yes, please", the program being executed by the instance provides a channel ID 105 identifying the Red Sox chat channel to communications system 127. The execution instance of the program then gives the user access to the Red Sox chat channel and by so doing to the Red Sox chat. As is apparent from the foregoing, instances 103(1..n) are all of the simultaneously executing execution instances of the program in which the user of the instance has selected the Red Sox chat channel, and all of these users are simultaneously connected to the chat channel. In common examples of the prior at, the program of which instances are being executed is a Web browser and the code that specifies User Interface 1 15 and responds to the user's choice is part of a Web page that is being interpreted by the execution instance of the browser.

User 101(1) is shown in FIG. 1 with representative headphones and microphone that are interfaced to software of entity 117(1) (readily understood). Entity 117(1) permits user 101(1) to communicate using a channel that entity 1 17(1) has access to.

An important limitation of prior-art systems like the one shown in FIG. 1 is that an identifier for the chat must be specified in the code that is executed by the execution instance. In the case where the program being executed by the execution instance is a Web browser, the code that specifies the identifier is generally part of a Web page that is interpreted by the execution instance. Because the identifier must be specified in the code that is executed by the execution instance, specifying a different chat or specifying the chat in a different way requires that the code be rewritten. The rewritten code must then be made available to users of the program, or in the case of the Web pages, the modified Web pages must be made available to browser users.

FIG. 2 shows what is involved here:

The figure shows how the YackPack ® system and components enable chats to be used in web browser pages, (www . yackpack . com: reference fetched 4 August 2009). In order for the chat to be available to users of a Web browser page, the pages must include an embedded Flash® code object for the chat. An example of the embedded object is shown at 260. A corresponding UI, such as the example of 270, then becomes part of what the user sees when the browser interprets the Web page.

An object of the inventive techniques disclosed herein is to make it possible to associate an execution instance of a program with a chat without changing the code that is executed by the execution instance. The techniques that attain that object may also be used generally to associate execution instances of programs with communications channels.

Upon perusal of the Detailed Description and drawings below, other objects and advantages will be apparent to those skilled in the arts to which the invention pertains.

BRIEF SUMMARY OF THE INVENTION

In one aspect, an object of the invention is achieved by a method of associating a chat with a plurality of execution instances of a program, in which an observation is made of observable information in each of the execution instances, and for each of the execution instances a mapping is made of the observation to the chat by a predetermined method; the chat is usable for communication by the instances and/or by entities associated with the instances

In other aspects, the chat is mapped to a communication channel available to the chat, the mapping may not occur until the predetermined mapping is made for the observation from at least a first one of the execution instances; the mapping persists at long as at least one of instances and/or entities is using the channel.

In further aspects, the entities have persistences that are independent of the persistences of the execution instances and the chat's persistence is thereby independent of the persistences of the execution instances. In additional aspects, the entities include communications managers associated with users of the instances, the communications managers manage the communication channel, and the users use the chat to communicate with one another.

In still further aspects, the information from the observation is manipulated to do the mapping. The manipulation includes selecting information from the observation.

In yet other aspects, the mapping by the predetermined method includes obtaining additional information for use in mapping the observation to the chat; the additional information is obtained from the execution instance; the additional information is obtained via a user interface for specifying the additional information to the execution instance; the additional information is obtained from a source other than the execution instance. Additionally, the observation is made in an observer that is associated with the execution instance; the observer observes and the mapping is performed in the observer.

In an additional aspect, observations are mapped to the chat according to the predetermined method in a mapper that maps observations from the observers associated with the execution instances to the chat; further, making an observation and making a mapping may be performed in an observer/mapper that makes observations of the plurality of execution instances and maps the observations to the chat.

In further aspects, the execution instances are browsers, the entity is a user of the browser, and the observer is a plug-in for the browser. The plug-in employs an interface provided by the browser that notifies the plug-in of an event in the browser. The plug-in further maps the observation to the chat The mapping may further be done in a mapper that maps observations from the plug-ins associated with the browsers.

An additional aspect is a method of associating a communication channel with an execution instance of a program. In the method, an observation is made of observable information in the execution instance, and the observation is mapped to the communications channel according to a predetermined method

BRIEF DESCRIPTION OF THE SEVERAL VIEWS OF THE DRAWINGS

FIG. 1 illustrates how on-line voice chats are set up in the prior art. FIG. 2 shows examples of integration of voice chat in the prior art, a screenshot of an online game, and an example URl.

FIG. 3 is a block diagram showing the inventive techniques in overview. FIG. 4 is a block diagram of a first preferred embodiment.

FIG. 5 is a flowchart of initial code of the plug-in of the first preferred embodiment. FIG. 6 is a flowchart of processing code of the plug-in, and processing for the "home" page of the game.

FlG. 7 is a flowchart of processing for the "load" and "join" pages of the game. FIG. 8 is a flowchart of the "checkBattleLoded" method of the plug-in. FIG. 9 is a flowchart of the "battlesClicked" method of the plug-in. FlG. 10 is a block diagram of a second preferred embodiment.

FlG. 11 is an example of the Global Chat List relational table of the second preferred embodiment

Reference numbers in the drawings have three or more digits: the two right-hand digits are reference numbers in the drawing indicated by the remaining digits. Thus, an item with the reference number 203 first appears as item 203 in FIG. 2.

DETAILED DESCRIPTION OF THE INVENTION

The following Detailed Description describes Applicants' inventive techniques for associating execution instances of programs with chats and providing the chats to users of the programs. The approach taken by the techniques is to employ an observer which is independent of an execution instance of the program to observe the execution instance, make an observation out of what it observes, and then use the observation to associate the execution instance with the chat: in this context, independence refers to the code of the observer being independent of the code of the execution instance that is being observed; for example, the code of the observer may be changed without changing the code of the instance. The process of using the observation to associate the execution instance with the chat is termed mapping the execution instance to the chat. If observers observing different execution instances make the same observation and map the observation to the same chat, the execution instances are all associated with the chat By changing what the observer observes and/or how the observer maps its observation to a chat, it is possible to change the associations between application instances and chats without modifying the code executed by the application instances. As would be expected from the general meanings of the words "observe", "observer" and "observation", an observation made by an observer does not substantially alter the behavior of the execution instance that it is observing. The information from the execution instance from which the observer makes the observation is termed in the following "observable information".

Overview of the techniques

FIG. 3 is a block diagram showing the inventive techniques in overview.

Instance 303(1) in FIG. 3 is one of a number of instances of execution of a program 303(1) through 303(n). Instance 301(1) has observable information 305(1), and may be interacting with user 301(1), as indicated by the double-ended arrow at 306(1). User 301(1) has representative headphones and microphone interfaced to software of entity 317(1): such interface and software are readily understood. Entity 3 17(1) permits user 301(1) to communicate using a channel that entity 317(1) has access to.

Observer 307 obtains, as indicated at 319(1), observable information 305(1) of instance 303(1) and makes observation 31 1(1). Observer 307 subsequently maps observation 31 1( 1) to chat 313, as shown at mapping 309. Observer 307 provides chat 313, to which observation 31 1(1) has been mapped, to communications system 327, as shown at 320(1) Communications system 327 subsequently provides access to a chat channel corresponding to chat 3 13 to entity 317(1 ), as shown at 321 ( I ).

Similarly, representative other instance 303(n) has representative other user 301(n) interacting at 306(n), other observable information 3O5(n) that is also obtained by observer 307 at 319(n), which observer 307 makes into observation 31 l(n); observer 307 maps observation 31 l(n) to chat 313, and provides chat 313 to communications system 327, which in turn provides access to a chat channel corresponding to chat 313 to entity 317(n), as shown at 321(n), all as described for 303(1).

Subsequently, entities 317( 1 ) and 317(n) have access to the same chat 313 as determined by mapping 309; 325 indicates that access to same chat 313 is provided to the representative entities. User 301( 1) and representative other user 301 (n) can consequently communicate with each other via the chat mapped to at 309.

As may be clearly seen from FIG. 3, the use of observer 307 to associate execution instances 301(1..n) with chat 313 makes it possible to change associations between execution instances and chats without altering the code that is executed by the execution instances. Moreover, any observable information may be used to make an observation and mapping 309 may do its mapping by performing any available kind of manipulation of the observation, including using selected parts of the observation. The mapping may further involve the use of any other information from any source whatever that is available to the observer. For example, if instances 303(1. n) are instances of Web browsers, mapping 309 may involve obtaining additional observations from the browser, may involve providing the browser with a UI such as UI 1 15 for receiving information from the user that can be employed in making the mapping, or consulting a relational database system to determine whether the user has whatever additional privileges are needed to be a chat user. Mapping 309 may involve any kind of additional information, including historical information regarding past observations, events, or other information: for example, historical information may be maintained by a mapper, or may be obtained from another source.

It should also be noted here that because it is an observation that is mapped to a chat, a given execution instance may be associated with any number of chats.

It should further be pointed out here that the technique of using an observer to make an observation and then mapping the observation to a chat can be used generally to associate an instance of a program execution with a communication channel, regardless of whether the channel is used for a chat.

Overview of a first presently-preferred embodiment

A first presently preferred embodiment is described starting with FIG. 4. This first embodiment provides chats for users playing a popular commercial on-line game that is implemented using web pages available from a particular web site. The execution instances are execution instances of the browsers the players use to play the game. The game gives users a choice of matches or competitions. Users playing in the same match of the game are given access by this first embodiment to an on-line voice chat for players playing in that particular match, so that those players can talk to each other while playing in the match. As is apparent from the foregoing, the observable information needed to associate the browser execution instances the players are using to play the game with the channel is information which indicates (a) that the user of the browser is in fact playing the game and (b) that the player is playing in the match associated with the channel. As will be explained in detail below, this information is available on the web pages for the game.

In the first embodiment, the observer is implemented as a plug-in for the Firefox web browser: information on the Firefox web browser and plug-ins can be found at www . mozi 1 1 a . com (reference fetched 4 August 2009). To do its observing, the plug- in employs a standard interface that the Firefox browser provides for receiving notifications of events which occur during browser execution. The observer indicates to the browser what events it wants to be notified of and when the event occurs, the browser executes a call back to the observer to inform the observer of the event and return data concerning the event. This data is of course the observation. Among the events that the observer may select for notification are loading a web page, which returns the URL of the Web page being loaded, and the occurrence of user interface events in a loaded Web page. The observer uses the data returned by the events to determine first whether the user of the browser is playing the game at all and second, if the user is a player, what match the player is playing in. The latter information is used to associate the browser instance with the chat for the match. To illustrate, the observer obtains observable information identifying a match, such as a formatted string value "Demon Keep" or an encoded parameter of a special URL for a page of the game, and makes it into an observation with the observable information value "DemonKeep". When the user joins a match, the observation is mapped by the observer to a standard SlP URI channel identifier value of

"si p : conf ctl -g-DemonKeep@bnw.1 i bretel . com". SlP refers to the standard known as Session Initiation Protocol: information on SIP may be found at tool s . i etf . org/html / rf c3261 (referenced fetched 4 August 2009)

Block Diagram of FIG. 4

FIG. 4 shows an overview of the first embodiment in the form of a block diagram.

In FIG. 4, user 401(1) has personal computer 405(1). Executing on personal computer 405 is web browser 403(1), processing web pages 406(1) of the game QuakeLive.com®, an on-line virtual reality combat game: a sample screen shot of QuakeLive com is shown at 200 in FlG 2. Also shown in FlG. 4 is observable information 407(1) of web browser 403(1 X for example information about features of the current web page.

User 401(1 ) has a microphone and headphones as shown, and is interacting with content of web pages 406(1) to play the game, as indicated by dashed line 409. The headphones and microphone are connected to hardware and software (not shown, readily understood) of personal computer 405(1).

Plug-in 408 has been installed in web browser 403. Plug-in 408 contains code of observer

410 that obtains observable information 407 of web page 406 when certain browser events occur for web page 406: for example, when a new web page is loaded, or when a particular element on the current web page is modified by programming of web page 406. Observer 410 obtains observable information 407, makes observation 41 1 from observable information 407, and at 412 maps observation 41 1 to a chat in the form of a SlP URl channel identifier for a chat channel of communications system 433.

Observer 410 provides channel identifier 413 to communications system 433 via communications manager 436, as shown at 420(1): in an alternative version of the embodiment, the channel identifier may be provided over an Internet socket connection or by other means.

Communications system 433 is a communications system that creates channels on demand when provided a well-formed identifier for a channel, thus a channel need not be created prior to first use.

Also shown is representative other user 401 (n) with further personal computer 405(n), and web browser processing the web pages of QuakeLive.com with plug-in and other components as those of user 401(1 ) (not shown). These and other details are omitted from FIG. 4 for clarity, as they are readily understood from the description regarding user 401(1), personal computer 405(1), and so forth.

Because observation 41 1(1) has been mapped to the same chat as the observation 41 l(n) (not shown, understood) of the browser of user 401 (n), as indicated by 425, users 401 (1) and 401 (n) may communicate with each other over this same chat 413. The communications between the two users over chat 413 are indicated by dashed line 461.

Communications manager and communications system:

In a presently preferred embodiment, communications manager 436 is an embodiment of an entity 317. Here, the entity is an instance of a program that executes on personal computer 405 separately from web browser 403. Communications manager 436 executes code (readily understood, not shown) for establishing and maintaining connections to chat channels, and allowing user 401 to communicate using a chat channel to which communications manager 436 has access. The Vivox Voice Manager component (VVM) of the Vivox Managed Service is particularly desirable as the communications manager 436 of a presently preferred embodiment. The Vivox Managed Service managed communications service network (www . vivox . com/raanagedservice . html : reference fetched 4 August 2009) is particularly desirable for communications system 433 of a presently preferred embodiment.

The Vivox Managed Service technology allows channels to be created - and discarded when no longer needed - "just in time" with very low overhead. Further it supports multiple kinds of media, is particularly scalable with respect to very large and/or rapidly dynamic communications load requirements, is especially robust with respect to failures of service or connectivity, and further supports point-of-perception rendering of media with minimal load on the client instances, permits anonymous/unauthenticated logins, and does not require channels to be pre-allocated or pre-defined to provide good performance - they can be created automatically the first time there is any login identifying a particular channel - and other desirable aspects.

That other communications systems and other forms of a communications manager may be used is readily apparent.

Communications manager 436 may be implemented in a program such as web browser 403. An advantage of implementing communications manager 436 separately, and of it providing communications for other instances of execution as clients of communications manager 436, is that it can continue execution after one or more of the execution instances associated with channel 413 has ceased to exist. Because this is so, chat channel 413 may persist longer than the execution instances with which it was originally associated. Such a communications manager can disconnect from a channel after the last client instance has ceased, and a timeout period has expired. Further, a single channel may be managed by the communications manager on behalf of more than one client instance, and client instances can obtain consistent information about the channel from the communications manager, for example for use in the instances own Ul.

Details of observer plug-in 408

Initialization:

When web browser 403 starts execution, it calls the initialization code of plug-in 408. This initialization code is described in flowchart form at 500 of FIG. 5: The initialization code of the plug-in instantiates an observerService object for a standard interface of the browser at 504. The observerService object lets the plug-in register a listener object that has listener methods with the browser: informally, registering is the process of specifying to the browser that when a particular browser event occurs, the browser should call back to a particular method of the object that is being registered.

At 506, the initialization code calls the addObserver method of the observer service object of 504 to register a listener object httpRequestObserver. The call to the addObserver method includes a parameter "http-on-examine-response", indicating that the listener method of the httpRequestObserver object is to be called for browser events in which an HTTP response is received by browser 403 - e.g. a web page has been loaded - and to pass the response data to the standard listener method "obse rve" of the listener object when the browser calls back to the listener method.

Listener method "observe " of observer object of step 506:

In summary, the "obse rve" method of the observer object checks for loads of web pages of "quakelive.com", and registers a tracing listener object with methods the browser should call back to for observing pages of the "quakelive com" game when such a page is found. For pages from all other web sites, the "obse rve" method returns. Information on the standard interfaces and technology of observer and tracing listener objects can be found at developer .mozilla . org/en/NsIObserverService (reference fetched 4 August 2009).

The listener method "obse rve" is described in flowchart form at 520:

The listener method checks at 524 whether the event it has been called for is an event to examine an HTTP response that has been received by the browser. If not, the method returns.

At 526, the method obtains a handle to the HTTP channel on which the HTTP response was received, at 528 uses the HTTP channel handle of 526 to get the host name part of the HTTP request header for the response. ,

At 530 and 532, the method checks whether the host name obtained at 528 has a value, and if so whether the host name is for the web site "quakelive.com". If not, the method returns.

At 534, the method instantiates a listener object "traci ngLi stener", and at 536 obtains a handle to the tracing listener interface for the web browser and uses the interface handle to register the listener object of 534.

Tracing listener object method "onStopRequest" of step 534:

In summary, the tracing listener object described at 534 contains a listener method "onStopRequest", which the browser calls back to when a response to an HTTP request has been fully received: e.g. when a web page has been fully loaded. There are three parts of the listener method "onStopRequest" for three specific pages of the

"quakelive.com" game: a page for for selecting a match to play; a page for joining a match; and a page for joining a match directly (e.g. joining a match in the middle of play, from an Emailed web link to the match from another player). The "OnStopRequest" method is described in flowchart form starting in FIG. 6 at 600: "home" page: The method checks at 624 whether the URL of the page whose loading resulted in the browser calling back contains the string "www . quakelive . com/user/home?". If so, the method continues from 626 in 600 to 626 in 650 to handle the current "home" page.

"1 oad" page": At 628, the method checks whether the URL of the current page contains the string "www . quakelive . com/user/load?". If so, the method continues from 630 in 600 to 630 in FIG. 7 to handle the current "load" page.

"joi n" page: At 634, the method checks whether the URL of the current page contains the string "www . quakel i ve . com/user/ j oin/". If so, the method continues from 636 in 600 to 636 in FIG. 7 to handle the current "join" page.

Otherwise, the "onStopRequest" method returns.

Processing of 626 for "home " page:

In summary, for the "home" page the method registers two event listeners that the browser subsequently calls back to for two specific UI events in the pages of the QuakeLive.com game: a "cl i Ck" on an element to select a match for the user to play in, and a change to a "di v" element that indicates that match play has started or ended for the user. A flag is used to remember whether the event listeners have already been registered. The processing for the "home" page is described in flowchart form in FIG. 6 at 650:

The method checks at 652 whether a user name field in the "home" page has been set to identify the user playing the game. If not, the method returns.

At 654, the method checks the value of the flag "thi S . 1 i steni ng", indicating that the listener methods of the next steps have already been registered with the browser. If true, the method returns. At 656 and 668, the method registers a listener method "battl esCl i cked" for "cl i ck" events of the browser, and further registers a> listener method "checkBattl eLoded" for "DOMAttrModi fi ed" events of the browser - these respond to browser events that indicate that an attribute of a web page element has been changed.

At 660, the method sets the value of the flag "thi s . I i stem^" ng" to true, to indicate that the listener methods have been registered. The method then returns.

Processing of 630 in FlG. 7 for the "load" page:

In summary, for the "load", the method extracts the user name from the http response text of the current page, and logs the user in as an anonymous/unauthenticated user with that name to the communications service via the communications manager. The processing for the "load" page is described in flowchart form in FIG. 7 at 700:

The method checks at 702 whether the variable quakellse r is already set to the name of the user playing the game. If so, the method returns.

At 704 and 706, the method gets the text response body of the HTTP page, and reformats the response text to JavaScript Object Notation format, a standard string format.

At 712, the method sets the quakeUser variable to the response text: the response text contains the user's display name for the game.

At 714 and 716, the method gets a handle to the API interface for the communications manager 436 of FIG. 4, and makes an anonymous/unauthenticated login to the communications system 433, providing the value of the quakeUse r variable as the roster name for the communications system. The method then returns.

Processing υ/636 in FIG. 7 at 750 for the '[join "page:

In summary, a user can join a match "in the middle of play" by entering a special URL for a "join" page. For a "join" page, the method parses the string of the page's URL to get a match identifier value, then fetches the special "matchdetail" page of the game for that match. The method then parses the contents of that page to get the name of the match.

At 752 and 754, the method gets the full URl string used to fetch the current web page, and parses the URl string to get the matchNUtD code value identifying the match the user isjoining.

At 756, the method checks whether there is a matchNum value. If not, the method returns.

At 758 and 760, the method constructs a URL string for the "matchdetails" page of the game, with the matchNum value encoded as an embedded parameter, and uses a standard AJAX utility method to fetch the data of the page independently of the browser.

At 764, the method gets the response to the fetch of the "matchdetails" page, and extracts the name of the match.

At 766 and 768, the method registers a listener method "battl esCl i cked" for "cl i ck" events of the browser, and registers a listener method "checkBattl eLoded" for "DOMAtt rModi f i ed" events of the browser - these are browser events indicate that an attribute of a web page element has been changed.

At 770, the method sets the value of the flag "thi s . 1 i Steni ng" to true, to indicate that the listener methods have been registered. The method then returns.

"checkBaltlel.oded" method of 658 and 768:

The browser calls back to the "checkBattleLoded" listener method for browser events that change an element in a web page. The method checks for certain changes in "quakelive.com" pages that indicated that a user is joining a match, or leaving a match. When the user is joining a match, it maps observation information (name of the match, that the user has started the match) to a chat by constructing a channel identifier value for the communications system 433, and logs the user into that chat channel.

For example, the name of a match "Demon Keep" is first converted to "DemonKeep" as information of an observation, and the observation is mapped to a standard SlP LJRl channel identifier value of

"si p : conf cti -g-Demonκeep@bnw.1 i bretel . com".

The method checks at 804 in FlG. 8 whether it has been called for a change to the element 'qz_handshake". If not, the method returns.

At 806, the method checks whether the height of qz_handshake is one pixel. This indicates that a user is leaving a match: if so, the method continues at 808. Otherwise the method continues at 826.

At 808, the user is leaving a match: at 808 and 810, the method gets a handle to the interface for the communications manager, and uses the handle to check whether there is currently an active channel connection for the chat. If so, at 812 the method uses the handle to log out the current channel connection. The method then returns.

At 826, the method checks whether the height of qz_handshake is 100% height. This indicates that the user is starting a match: if not, the method returns. At 828 and 830, the method gets a handle to the interface for the communications manager, and uses the handle to check whether there is currently an active channel connection for the chat. If so, the method returns.

At 832 and 834, the method maps to a chat by creating a value focusName from the name of the current match by removing whitespace, and creating a chat specifier in the form of a SIP URI string that includes the f OCUSName value.

At 836, the method provides the SIP URI string of 834, to in a login call to the communications service using the handle to the interface of the communications manager. Subsequently the method returns.

"battlesClicked" method of 656 and 766:

In summary, the "battlesClicked" listener method checks whether the user has clicked on a special element on the page to join a match, and for an element on the page that has the name of the match. If they are present, the method gets the name of the match.

At 904 and 906 in FIG. 9, the method checks whether there is an element "l gi_ti p"- an element for a particular tool-tip UI of the game - is on the current page. If not, the method returns.

At 908 and 910, the method checks whether there is an element "1 gi_map_name" on the current page. If not, the method returns.

Next at 912, the method gets the text value of the "l gi_map_name" element: this observable information is the game's name for the user's current match: the observation will be mapped to the chat channel when the user joins the match.

The method then returns. Description of a second presently-preferred embodiment

A second presently preferred embodiment is described starting with FlG. 10. This embodiment provides users who are viewing the same web page with a chat. The mappings from observations to chats are done centrally, and consequently, the associations between web pages and chats can be changed simply by changing the way in which the central mapping is done.

The observable information includes the domain and subdomain of the web server the page was fetched from, the path and file part of the web page, and any first GET/POST parameter used to fetch the page. To illustrate, for the URL value shown at 250 in FIG.

2, the domain part is "vivox . com" at 252 and the subdomain part is "www . voon" at

254, and there is one GET parameter "uname=james" . An observation of the observable information is made when web page is loaded. The observation is mapped by a central observer mapper to a chat for users using the same web page or who are on the same web site, depending on programming and which parts of the observable information are used - to illustrate, all users viewing a page of the "www. 3rd! i fe . com" web site may share one chat, and user viewing a page of "www. defau1 t . com" may share another.

In this second embodiment, the observer is again a plug-in for the Firefox Web browser. The mapping of the observation to the chat is implemented in a separate central service component that does the mapping for observations from multiple observers.

The observer observes all web pages loaded by the web browser. The observable information includes URL information identifying the domain and sub-domain of the web server of a web page, the contents of page the user is viewing, and the first GET/PUT argument of the URL used to fetch the web page. Observations are made of the observable information when a web page has been loaded. Block Diagram of FIG. JO

FlG. 10 describes this second embodiment in the form of a block diagram. Details of FIG. 10 that are well known in the art and/or readily understood from the description of the first embodiment of FlG. 4 are omitted for clarity, as they need not be explained.

User 1001(1) has personal computer 1005(1). Executing on personal computer 1005 is web browser 1003(1): web page 1006(I )(I) is one current web page loaded into web browser 1003(1),: other web pages may also be loaded, as indicated by 1006(I)(I) and 1006( 1 )(n). Also shown is observable information 1007(1) of web browser 1003(1) for web page 1006(I)(I).

User 1001 has a microphone and headphones as shown, and may interact with web page 1006(I)(I ): this is indicated by dashed line 1009. Plug-in 1008 has been installed in web browser 1003. Observer part 1010 is implemented in plug-in 1008(1), and as previously described, uses standard interfaces of the web browser to observe observable information 1007.

Observer part 1010 obtains observable information 1007, makes observation 101 1 from observable information 1007, and provides observation 1011 to observer mapper part 1035 via communications manager 1036. Observer mapper part 1035 performs mapping as shown at 1037, and is implemented on a server separate from personal computer 1005(1). Observer mapper part 1035 has a relational data base management component (known in the art) containing global chat list 1065, a relational table containing relations of observations to chats. An observation is mapped to a chat by a determining the relation in global chat list 1065 corresponding to the observation. The channels for the chats in global chat list 1065 are identified by SIP URI values that are accepted by communication services 1033.

Observer mapper part 1035 determines whether observation 101 1 is already related to a chat by consulting global chat list 1065. If a relation for observation 101 1 is not currently present in global chat list 1065, observer mapper part 1035 creates a new chat and a relation for observation 101 1 and the new chat added to global chat list 1065.

In this presently preferred embodiment, a new chat is created by obtaining an identifier of an unused or new chat channel from communication system 1033. Alternatively, the identifiers may be created algorithmically, such as using a large pseudo-random number as part of the value.

Subsequent to this determination, observer mapper part 1035 maps observation 101 1(1) to chat 1013 by consulting global chat list 1065 and determining the relation corresponding to observation 101 1(1). Mapper part 1035 then provides chat 1013 to observer 1010 via communications manager 1036(1) as shown. Observer 1010 then provides chat 1013 (as represented by the SIP URl value) to communications system

1033, whereupon communications system 1033 provides access to the channel for chat 1013, as determined by the relation, to communications manager entity 1036, as shown at

1036(1)

Communications manager 1036 is readily understood from the description of FIG. 4.

Also shown is representative other user 1001(n). with personal computer 1005(n), and web browser with plug-in and other components (not shown) as those of user 1001(1), and observations indicated by observation 101 l(n). These and other details are omitted from FIG. 10 for clarity, as they are readily understood from the description regarding user 1001(1), personal computer 1005(1), and so forth.

Because observation 1011(1 ) has been mapped to the same chat as the observation 101 l(n) of the web browser of user 1001(n), then as indicated by 1019, users 1001( 1) and 1001(n) may communicate with each other over this same chat 1025. The communications between the two users via chat 1025 are indicated by dashed line 1061. Observable information:

Observer 1010 of plug-in 1008 obtains a number of items of observable information using standard interfaces of web browser 1003, including: • URL value of the current page of the web browser observed.

• First GET/POST parameter, if any, of the current web page URL.

In a presently preferred embodiment, observer 1010 also obtain further items of observable information, such as the IP address of personal computer 1005, and meta-tags or semantic information of the current web page. Central mapper 1035 may also use this information to make its mappings.

FIG 1 1 shows a representation of the definition of an exemplary relational table silk_spaces of global chat list 1065. In this second presently preferred embodiment, a chat may be referred to as a mediaspace or mediascape, indicating that the chat may employ multiple kinds of media communication. 1150 shows representative values of global chat list 1065 as a relational table silk_spaces with four exemplary rows 1160, 1170, 1 180 and 1190. Table 1 150 also has four exemplary columns, silk_domain 1 151, silk_subdomain 1 153, silk_arg 1 155, and silk_chan_uri 1 157. FlG. 11 is described further below.

Observer mapper 1035:

Observer mapper part 1035 extracts the URL value and GET/POST parameter information from observation 101 1. Observer mapper part 1035 subsequently parses the URL value of observation 101 1 into a domain part and subdomain part.

To map an observation, observer mapper part 1035 determines the row of global chat list

1065 with the same subdomain, domain, and first GET/POST argument (referred to for convenience in this discussion as arg) values as the silk_domain 1 151, sil k_subdomain 1 153, and sil k_arg 1 155 columns respectively of the row. If no such row exists, a new chat is obtained from communications system 1033, and a new row is added to global chat list 1065 for the domain, subdomain, and arg values and the SIP URI string identifier for the chat that is related to the row's values in columns 1 151 , 1 153, 1 155, and 1 157 respectively.

1187 shows a numeric part of a SIP URI string identifier value of the embodiment: in this embodiment, communications system 1033 from which mapper 1035 obtains new channels creates a unique SlP URI identifier for a new channel by creating the identifier with a unique number.

Subsequently, the value for the si l k_chan_uri column 1 157 for the row matching the domain, subdomain, and arg values of observation 101 1 in global chat list 1065 is returned as the chat channel that is associated with the execution instance and observation with which the channel is associated.

Global chat list 1065, represented by the table silk_spaces of FIG. 1 1 , may be extended with additional columns and joined with additional tables, for example to accommodate additional observation information, include other information including information from other sources in the relations used for mapping, and so forth. A column value for a particular row may also be NULL if it has no value: for example, a URL of an observation's information may have only a domain such as '3rdlife.com' and no subdomain, and thus the subdomain value may be NULL. The global chat list 1065 may also be extended to manage the lifetime of chats and/or relations, for example to record the time of first mapping to a chat or the time of its most recent use to communicate or the current number of users of the chat, and to discard a chat by discarding all rows mapping to it when there are no users active, after a timeout period since the most recent use, or a combination.

Comparison of aspects of the two embodiments One advantage of the first embodiment is that the mapping does not depend on a central server, and thus may have fewer points of possible failure: in the first embodiment, the mapping is determined algorithmically from the information of the observation A further illustrative advantage is that the observations and pre-determined mapping are tailored to the specific on-line game.

One advantage of the second embodiment is that it is logistically easier to change the pre-determined mapping, because a change may involve only changing the programming of the mapper, not the programming of each copy of the observer plug-in. Further, in the second embodiment it may be simpler to take into account further information in determining a mapping. A further advantage is that the embodiment provides chats for all web pages, not just for those of QuakeLive.com.

The two preferred embodiments described above are exemplary of how the inventive techniques may be applied. It is readily apparent that the techniques may be applied in different ways depending upon the requirements of a particular design. For example, an observer that need observe only instances of execution of one program may be simpler in design, but more limited in capability. An observer that observes a variety of execution instances may be more complex.

It may be desirable to make the mapping to chats more readily alterable by performing mapping in a central server component, as only the programming of the central server need be changed. However in a given design this may have worse performance overall, for in such an embodiment, the observer must provide its observations to a mapper on a remote server.

Extensions of observing

Further aspects of observing include the following: An instance of an observer may observe a single instance of execution of a program, or may observe a number of instances of execution of a program. For example, an observer may be implemented as a separate program, and using debugging, Registry, instrumentation, and other standard interfaces of an operating system, observe observable information of multiple program execution instances. An observe may observe different execution instances by different means.

An observation may of course include any information that can be observed from the execution instance. Information used in mapping may include anything in the observation and anything that can be inferred from the observation. For example, an observation may include the IP address of a PC and from the PC address may be inferred the approximate geographic location of the user of the PC, or a subnet may be inferred from which may in turn be inferred a common social association of two users by them being on a same local subnet. The mapper may obtain login identities or information provided directly by a user, and from these may be inferred gender, sex, age, membership in an organization, likely topics of interest, or a socioeconomic status. Demographic information such as membership in a group on a social networking site, or past behaviors such as activity relating to a particular web site, for example purchases at an on-line store, or browsing history, may be obtained or inferred and used together with information from the observation to do the mapping The mapping may further be algorithmic, i.e., the information used to do the mapping is applied to a function that produces an identifier for the channel, or it may be done using a table that relates the information used to do the mapping to an identifier for the channel.

Observers need not be programmed identically nor observe similar entities nor make observations of the same observable information, yet may still map to a same chat depending on the observation made by the observer and how the mappings are done.

Extensions of mapping Mapping may of course be performed in one or more stages, employing one or more components, and in different fashions. To illustrate, a browser plug-in observer may map to a chat directly without any part of mapping being performed by or in coordination with any other component, for example by employing an algorithm common to one or more observers.

Mapping may be pre-determined and static, or pre-determined and change dynamically: two mappings of the observations containing the same information need not be mapped to the same chat For example, mapping may be static by using known techniques such as hashing to determine a chat directly from the information of an observation; mapping may be dynamic by employing other infoπnation in the mapping, including information that changes over time such as context information regarding new sporting events; mapping may also be changed dynamically by changing the programming that predetermines the mapping.

Mapping may also employ an interaction with a user such as a pop-up Ul, or with an instance that has been observed, after an observation has been made. For example, a predetermined mapping may, under some circumstances, involve prompting a user for additional information to map a particular observation, but not necessarily all observations.

Further extensions

Chats and communications employed in an embodiment employing any of the inventive techniques are not restricted to use only with the inventive techniques. A chat used in one system according to the inventive techniques may simply be provided to another system for use in that system. To illustrate, in the example of chats for on-line games, a system employing the techniques may also permit another party not playing the game to join the chat by providing an identifier for the chat that can be used directly - for example, a user playing the game calls a friend who is an "expert" player, and asks the friend to join the chat (without playing the game) by a telephone application to give the user and other players (perhaps on the same team) advice on playing, for socializing, or other reasons.

Embodiments may integrate use of the inventive techniques with other features, such as for security, privacy, or authentication of users. For example, an entity permitting a user to use a chat provided according to the inventive techniques may interact with the user prior to letting the user use the chat: for example, by asking the user to confirm that the user would like to use the chat.

Entities observed or using a chat according to the inventive techniques disclosed need not be associated with users, they may be" any kind of entity. For example, they may be the execution instances with which the chat is associated. They may also be simulated participants of a electronic game or virtual environment, user agents acting on behalf of a user (such as an automatic message handler when the user is absent), simulated Delphi oracles, artificially intelligent systems, virtual identities employed by a number of users or entities, or interactive information systems

The techniques may be employed for any kind of system or application. Chats established by the techniques disclosed herein provide new capabilities for communications among users As one example, either the observation or the information obtained for use in the mapping may identify a user as belonging to a member of a group with a likely interest in a particular sports competition event, and the user may subsequently be offered the opportunity to share a chat and view the event on-line in a virtual stadium or virtual sports bar. Where the chat is a mediascape, the observation or the information obtained for use in mapping may group users to be likely fans of a particular competitor, and the chat may in effect give members of the chat virtual seating near other fans of the competitor as well as the ability to communicate with each other The virtual seating may further be enhanced by using point-of-perception rendering of communications: individual users who have virtual seating with another user to the left would hear that user to the "left", and fans of other competitors who may have virtual seating in another virtual location of a virtual stadium, would be heard to be "across the stadium".

Conclusion

The foregoing Detailed Description has disclosed to those skilled in the technologies to which Applicants' techniques pertain how to make and use a system for associating chats and communication channels with execution instances of programs. Applicants have further disclosed the best mode presently known to them of making and using their system. As will be immediately apparent to those skilled in the relevant technologies, countless other embodiments may be made according to the principles disclosed herein.

For example, functions and processing may be carried out by more or fewer processors; operations may be performed on a client/server basis; entities may be implemented in combination or separately, or as part of the same code object or separate code objects;. Further, communications need not be real-time; communications may be transmitted by wired, wireless, mechanical, sonic, or other means; a communications system may be packet-based, circuit-based, or of another type. In addition, future kinds of components and/or technologies may be employed. The inventive techniques may be applied singly or in combination.

As will be readily appreciated, the inventive techniques are not limited to chats and chat channels, but may be employed for any kind of channels or communications; further, the mapping may be performed in multiple stages, the observable information observed by an observer may be determined statically or dynamically, and an entity to whom a chat is provided may be the same as an entity that is observed. Chats, channels, and other entities may also be embodied using indirect references: for example, a chat may be represented by an identifier such as a hash value, GUI string, chat channel identifier, or unique name. Further, more than one reference may be used for a same entity: for example, differing spellings of a name value differing in case or otherwise, or differing GUID string values. Communications employed with any of the inventive techniques may be any form of media singly or in combination without limitation, for example: text, audio, voice, video, haptic, tactile, olfactory, sensory, virtual, or synthetic communication.

For all of the foregoing reasons, the Detailed Description is to be regarded as being in all respects exemplary and not restrictive, and the breadth of the invention disclosed herein is to be determined not from the Detailed Description, but rather from the claims as interpreted with the full breadth permitted by the patent laws.

Claims

1. A method of associating a chat with a plurality of execution instances of a program, the method comprising the steps of: making an observation of observable information in each of the execution instances of the plurality; and for each of the execution instances, making a mapping of the observation to the chat according to a predetermined method, whereby the chat is usable for communication by entities associated with the execution instances and/or the execution instances.

2. The method set forth in claim 1 wherein a communication channel is available for the chat and the method further comprising the step of: mapping the chat to the communication channel.

3. The method set forth in claim 2 wherein: in the step of mapping the chat to the communication channel, the chat is not mapped to the communication channel until the predetermined mapping is made for the observation from a first one of the execution instances.

4. The method set forth in claim 3 wherein- the mapping between the chat and the communication channel persists as long as at least one of the entities and/or execution instances is using the channel.

5. The method set forth in claim 4 wherein: the entities have persistences which are independent of the persistences of the execution instances, whereby the chat's persistence is independent of the persistences of the execution instances.

6. The method set forth in any one of claims I through 5 wherein- the entities include communications managers associated with users of the execution instances, the communications managers manage the communication channel, and the users use the chat to communicate with one another.

7. The method set forth in claim I wherein the step of making a mapping according to a predetermined method further comprises the step of: manipulating information from the observation, the mapping being made using the manipulated information.

8. The method set forth in claim 7 wherein the step of manipulating the information from the observation includes the step of: selecting information from the observation.

9. The method set forth in claim 1 wherein: the step of mapping the observation to the chat according to the predetermined method includes the step of: obtaining additional information for use in mapping the observation to the chat.

10. The method set forth in claim 9 wherein: in the step of obtaining additional information, the additional information is obtained from the execution instance.

t t. The method set forth in claim 10 wherein: the additional information is obtained from the execution instance by providing a GUI for specifying the additional information to the execution instance.

12. The method set forth in claim I O wherein: the additional information is obtained from a source other than the execution instance

13. The method set forth in any one of claims 1 and 9 through 12 wherein: the step of making an observation is performed in an observer which is associated with the execution instance.

14. The method set forth in claim 13 wherein: the step of making a mapping of the observation to the chat according to the predetermined method is performed in the observer.

15. The method set forth in claim 14 wherein: the step of making a mapping of the observation to the chat according to the predetermined method is performed in a mapper that maps observations from the observers associated with the execution instances to the chat.

16. The method set forth in any one of claims I and 9 through 12 wherein: the steps of making an observation and making a mapping are performed in an observer/mapper thai makes observations on the plurality of execution instances and maps the observations to the chat.

17. The method set forth in claim 1 wherein- each of the plurality of execution instances is a browser; the entity is a user of the browser; and the observation is made by a plug-in for the browser which employs an interface provided by the browser, the interface notifying the plug-in of an event in the browser.

18. The method set forth in claim 17 wherein: the plug-in further maps the observation to the chat.

19. The method set forth in claim 17 wherein: the step of making a mapping of the observation to the chat according to the predetermined method is performed in a mapper that maps observations from the plug-ins associated with the browsers to the chat

20. A storage device for storing a program, the storage device being characterized in that: the program, when executed in a processor which has access to the execution instance of claim 1 , results in performance of at least the step of making the observation as set forth in any one of claim 1 and the claims dependent therefrom, the observation then being available for use in the step of making a mapping as set forth in any one of claim 1 and the claims dependent therefrom.

21. Apparatus that associates a chat with a plurality of execution instances of a program, the apparatus comprising: an observer that makes an observation from observable information in each of the execution instances of the plurality; and a mapper that makes a mapping of the observation from each of the execution instances of the plurality to the chat according to a predetermined method, whereby the chat is usable for communication by entities associated with the execution instances and/or the execution instances.

22. A method of associating a communications channel with an execution instance of a program, the method comprising the steps of: making an observation of observable information in the execution instance; and making a mapping of the observation to the communications channel according to a predetermined method.

23. A storage device for storing a program, the storage device being characterized in that: the program, when executed in a processor which has access to the execution instance of claim 22, results in performance of at least claim 22's step of making the observation, the observation then being available for use in claim 22's step of making the mapping.