Multi-session user launching and invitation system and method

CROSS-REFERENCES TO RELATED APPLICATIONS

0001This application claims the benefit of U.S. Provisional Application No. 60/487,773 filed on Jul. 15, 2003, and entitled WILDTANGENT IM GAME LAUNCHING AND INVITATION.

FIELD OF THE INVENTION

0002The present invention relates to the field of electronic data/information processing. More specifically, the present invention relates to methods and apparatuses for initiating multi-user sessions, such as multi-player computer gaming.

BACKGROUND

0003Advances in microprocessor related technology have lead to widespread development and the adoption of computing devices. Computing powers that used to be available only in expensive mainframe computers requiring special operating environments are now available in many personal-computing devices. The form factors vary from desktop, laptop, palm sized and so forth. A number of these computing devices are packaged as “special purpose” devices, such as set top boxes, entertainment personal digital assistants (“PDA”), pagers, text messengers, smart appliances and wireless mobile phones.

0004Concurrently, advances in networking, telecommunications and related technologies, in particular, in the area of wireless networking/communications, have lead to increased connectivity between computing devices, over local, private, wide area, and/or public networks. Of particular notoriety is the Internet.

0005Together, these and other related factors contributed to the availability of rich content and functionality available from a variety of devices. Recently, this availability of connected devices has made significant advances in the electronic gaming environment.

0006To facilitate communications between a wide range of devices, instant messaging (“IM”) protocols and services have been implemented by a variety of service providers, such as America On-Line's AIM protocol and Microsoft's MSN Instant Messenger protocol.

0007However, these IM protocols and services do not indicate how IM protocols or services could initiate multi-player gaming sessions.

BRIEF DECRIPTION OF THE DRAWINGS

0008The present invention will be described by way of exemplary embodiments but not limitations, illustrated in the accompanying drawings in which like references to note similar elements, and in which:

0009<figref idref="DRAWINGS">FIG. 1</figref> illustrates a system view of an example operating environment suitable for use to practice the present invention, in accordance with one embodiment.

0010<figref idref="DRAWINGS">FIG. 2</figref> illustrates an architectural view of a device suitable for use as an inviter device, in accordance with one embodiment.

0011<figref idref="DRAWINGS">FIG. 3</figref> illustrates an overview of the protocol and methods for the various devices to interact with the inviter device, in accordance with one embodiment.

0012<figref idref="DRAWINGS">FIG. 4</figref> illustrates the operational flow of relevant aspects of a process at the inviter device for having a gaming session with a recipient device.

0013<figref idref="DRAWINGS">FIG. 5</figref> illustrates an overview of an alternate protocol and methods for the various devices to interact with the inviter device, in accordance with one embodiment.

0014<figref idref="DRAWINGS">FIG. 6</figref> illustrates the operational flow of relevant aspects of a process at the relay server for forwarding between inviter and recipient devices during a gaming session.

0015<figref idref="DRAWINGS">FIG. 7</figref> illustrates an overview of an alternate protocol and methods for the various devices to interact with the inviter device, in accordance with one embodiment.

0016<figref idref="DRAWINGS">FIG. 8</figref> illustrates the operational flow of relevant aspects of a process at the central game server for a gaming session with an inviter and recipient device during a gaming session.

DETAILED DESCRIPTION

0017In the following description, reference is made to the accompanying drawings which form a part hereof wherein like numerals designate like parts throughout, and in which are shown, by way of illustration, specific embodiments in which the invention may be practiced. It is to be understood that other embodiments may be utilized and structural or logical changes may be made without departing from the scope of the present invention. Therefore, the following detailed description is not to be taken in a limiting sense, and the scope of the present invention is defined by the appended claims and their equivalents.

0018Embodiments of the present invention include a user-friendly technique for having an invited multi-user sessions, such as multi-player gaming session between computing devices. For ease of understanding, the description will be presented primarily in the context of multi-player gaming. However, embodiments of the present invention are not so limited, and may be practiced for other multi-user session applications.

0019In the following description, various aspects of selected embodiments of the present invention will be described. However, it will be apparent to those of ordinary skill in the art and others that alternate embodiments may be practiced with only some or all of the aspects of the present invention. For purposes of explanation, specific numbers, materials and configurations are set forth in order to provide a thorough understanding of the present invention. However, it will be apparent to those of ordinary skill in the art and others that alternate embodiments may be practiced without the specific details. In other instances, well-known features are omitted or simplified in order not to obscure the illustrated embodiments.

0020The various operations will be described as multiple discreet steps in turn, in a manner that is most helpful to understanding of the present invention. However, the order of description should not be construed to imply that these operations are necessarily order dependent. In particular, these operations may not be performed in the order of presentation.

0021The phrase “in one embodiment” is used repeatedly. The phase generally does not refer to the same embodiment, however, it may. The terms “comprising,” “having” and “including” are synonymous, unless the context dictates otherwise.

0022Referring now to <figref idref="DRAWINGS">FIG. 1</figref>, wherein an overview of an example operating environment incorporated with the teachings of the present invention, in accordance with one embodiment, is shown. The operating environment may also be considered and/or referred to as a system or a cluster of systems. As illustrated, example operating environment <b>100</b> includes inviter device <b>200</b>, IM provider server <b>110</b>, relay server <b>120</b>, central game server <b>130</b> and recipient device <b>150</b> operationally coupled to each other. In alternate embodiments, operating environment <b>100</b> may exclude relay server <b>120</b>. Inviter device <b>200</b> may comprise a number of components. <figref idref="DRAWINGS">FIG. 2</figref> illustrates one exemplary embodiment of a inviter device <b>200</b>, which is described below. <figref idref="DRAWINGS">FIGS. 3 and 5</figref> illustrate exemplary communication protocol/methods, one each, for operating environment <b>100</b> without and with the employment of relay server <b>120</b> respectively.

0023In various embodiments, the inviter device <b>200</b>, IM provider server <b>110</b>, relay server <b>120</b>, central game server <b>130</b> and recipient device <b>150</b> are coupled to each other wirelessly, i.e., they are members of a wireless network. In other embodiments, the inviter device <b>200</b>, IM provider server <b>110</b>, relay server <b>120</b>, central game server <b>130</b> and recipient device <b>150</b> are coupled to each other as members of a wire-based or mixed wireless and wire-based network. Regardless of the manner the devices are coupled to each other, for various embodiments, inviter device <b>200</b>, IM provider server <b>110</b>, relay server <b>120</b> and recipient device <b>150</b> are equipped to operate in accordance with the at least one IM protocol, if needed. In various embodiments, recipient device <b>150</b> may be an inviter device <b>200</b> and operate in the role of an inviter to initiate one or more gaming sessions of one or more games. Thus, the terms inviter device and recipient device, as used herein, for the purpose of this specification, including the claims, shall be interpreted with the meaning of of an appropriately equipped device, operating a corresponding one of the inviter or recipient role.

0024<figref idref="DRAWINGS">FIG. 2</figref> illustrates an exemplary inviter device <b>200</b> suitable for use in an embodiment of the present invention. In alternate embodiments, the inviter device <b>200</b> may include many more components (or less) of those shown in <figref idref="DRAWINGS">FIG. 2</figref>. However, it is not necessary that all of these generally conventional computing components be shown in order to disclose an enabling embodiment for practicing the present invention. As shown in <figref idref="DRAWINGS">FIG. 2</figref>, the inviter device <b>200</b> includes a communications interface <b>230</b>, which, in some embodiments of the present invention, may be a Network Interface Controller (“NIC”). The inter-device communications of the communications interface <b>230</b> may be designed to support a local area network, wide area network, personal area network, telephone network, power line network, serial bus or wireless connection. Such a communications interface <b>230</b> would also include the necessary circuitry, driver(s) and/or transceiver for such a connection and would be constructed for use with the appropriate transmission protocols for such connections.

0025The inviter device <b>200</b> also includes a processing unit <b>210</b>, a display <b>240</b> and a memory <b>250</b>, all interconnected along with the communications interface <b>230</b> via a bus <b>220</b>. The memory <b>250</b> generally comprises a random access memory (“RAM”), a read only memory (“ROM”) and a permanent mass storage device, such as a disk drive, flash RAM or the like. The memory <b>250</b> stores an operating system <b>255</b>, an instant messenger <b>260</b>, a game <b>265</b> and game catalog manager (“GCM”) <b>275</b>. In alternate embodiments, bus <b>220</b> may be an hierarchy of bridged buses. While for ease of understanding, operating system <b>255</b>, instant messenger <b>260</b>, game <b>265</b> and GCM <b>275</b> are illustrated as separate software components, in alternate embodiments, they may be comprised of multiple software components, implemented in hardware, or may be subparts of one or more integrated software components.

0026The GCM is adapted to present a list of games for a user of the inviter device <b>200</b> to choose from (e.g. in a hierarchical or otherwise arranged fashion). In various embodiments, GCM may be embedded into the instant messenger <b>260</b>, via a plug-in interface, or may be a separate component external to the instant messenger <b>260</b>. One embodiment utilizes a GCM that is an active program that runs on the inviter device <b>200</b>, while in an alternate embodiment the GCM may comprise a static collection of links provided by a remote computer or the like.

0027It will be appreciated that the software components may be loaded from a computer readable medium into memory <b>250</b> of the inviter device <b>200</b> using a mechanism (not shown) associated with the computer readable medium such as a floppy, tape, DVD (Digital Versatile Disk)/CD (Compact Disk)-ROM drive, flash RAM or communications interface <b>230</b>. In various embodiments, the loading may be performed during the manufacturing of device <b>200</b>, or in the field. In other embodiments, the software components may be downloaded from one or more networked servers.

0028In various embodiments, the communications interface <b>230</b> may facilitate the connection of remote devices to the inviter device <b>200</b>. For example, devices for reading and/or writing in machine readable media, digital cameras, printers, digital music players/recorders (such as MP3 players, etc.), Smart appliances, televisions, and the like. Various input mechanisms may also be coupled to the inviter device <b>200</b>, such as, for example, keyboards and/or mice (not shown).

0029In embodiments of the present invention the inviter device <b>200</b> initiates a gaming session at the inviter device <b>200</b> but “invites” (e.g., sends an IM message to) a recipient device <b>150</b> to participate in the gaming session. <figref idref="DRAWINGS">FIG. 3</figref> illustrates one exemplary series of application level communications between an inviter device <b>200</b> and a recipient device <b>150</b> in accordance with various embodiments.

0030<figref idref="DRAWINGS">FIG. 3</figref> shows the flow of a communication protocol, including the parameters, for operating environment <b>100</b> without the employment of relay server <b>120</b> (which may also be referred to as a peer-to-peer connection topology). In this embodiment, a session ID is sent from the inviter device <b>200</b> to the recipient device <b>150</b> via an IM message. The game client is launched on both machines with the session ID. At that point, the clients make a direct connection to each other. The specific communications between the device are described in more below and shown in <figref idref="DRAWINGS">FIG. 3</figref>.

0031In <figref idref="DRAWINGS">FIG. 3</figref>, the gaming session begins with a game selection <b>305</b> by a user. Next, the user of inviter device <b>200</b> composes <b>310</b> an invitation link to the gaming session for the recipient device <b>150</b>. The invitation link is encapsulated within an IM message and sent <b>315</b> via the IM provider server <b>110</b> to the recipient device <b>150</b>. Concurrently, or shortly thereafter, the inviter device may launch <b>320</b> the game <b>265</b> for which an invitation was sent to the recipient device <b>150</b>. In various embodiments, game <b>265</b> may be executing on inviter device <b>200</b>, or recipient device <b>150</b> or both.

0032The link can be a uniform resource locator (“URL”) pointing to the location of the game with the parameters necessary to launch the game (e.g., session ID as described below). A similar link may be used to launch the game on the inviter device <b>200</b>, potentially with additional parameters (e.g. that this game client instance will be the host). In both situations, this means that the game <b>265</b> does not necessarily need to be installed on either the recipient device <b>150</b> or inviter device <b>200</b> before the invitation is composed and sent. Also, the fact that the link is a URL means that the invitation does not need to be distinctly supported by the IM protocol used by the instant messenger <b>260</b> and IM provider server <b>110</b>.

0033Meanwhile, at the recipient device <b>150</b>, the game invitation link is accepted <b>325</b> and in due course, the game is launched <b>330</b> on one or both of devices <b>150</b> and <b>200</b>. With one or both the inviter device <b>200</b> and the recipient device <b>150</b> executing the game, the recipient device <b>150</b> and the inviter device <b>200</b> exchange game event data <b>335</b> to commence and play the gaming session.

0034In various embodiments, the communications described above and shown in <figref idref="DRAWINGS">FIG. 3</figref> are merely one exemplary set of communications between the inviter device <b>200</b> and the recipient device <b>150</b>. Other communications, both more and fewer, may be employed in other embodiments.

0035In various embodiments, the communications are performed using an IM protocol. In other embodiments, different transmission protocols for gaming sessions may be employed. The exact type of gaming protocol employed is not significant to embodiment of the invention.

0036In general, the various embodiments, the invitation link contains the information necessary to connect players before any game clients are launched. This may be accomplished by two separate but similar ideas: the earlier described session ID and the reservation ID. The choice between the two may be determined by the network topology a given game uses. The session ID may be used for games where players connect to each other in a peer-to-peer fashion, as described earlier. In particular, the inviter device <b>200</b> could be the host and the recipient device <b>150</b> would connect directly to the host. The reservation ID may be used if a Relay Server <b>120</b> (see <figref idref="DRAWINGS">FIG. 5</figref>, and discussion below) and/or a Central Game Server <b>130</b> were present (see <figref idref="DRAWINGS">FIGS. 7 and 8</figref>, and discussion below).

0037The generation of the two ID types may follow industry standard practices, as long as they were unique for the participants of the IM conversation. One method for generating IDs is to take the IM screen name (assumed to be unique) of the inviter and append a random number (e.g. “Joe9375873934”). Another method is to generate a GUID (Globally Unique Identifier), using well-known algorithms. The location of ID generation may be determined by whether the GCM is an active program that runs on the inviter device or not. If so, the appropriate ID would be generated on demand when the user selects a game to play. If the GCM is a collection of static links provided by a web server, the IDs would be generated beforehand while creating the GCM itself.

0038In accordance with the above-described peer-to-peer communications between an inviter device <b>200</b> and a recipient device <b>150</b>, <figref idref="DRAWINGS">FIG. 4</figref> illustrates a process within the inviter device <b>200</b> for a gaming session with at least one recipient device <b>150</b>. The gaming session process <b>400</b> begins at block <b>405</b> where a game is selected from the GCM <b>275</b>. In block <b>410</b>, recipient information is obtained (e.g., from user input, or from a storage location [not show]). A user input may be a selection of a member of a “buddy” list. The recipient information directly or indirectly includes information for sending an IM message to a recipient, such as an IM screen name or an e-mail address. Next, in block <b>415</b> an invitation is composed for the recipient that includes an indication and/or link to the selected game (from block <b>405</b>) and the recipient information for delivery to the recipient. The invitation is sent in block <b>420</b> to an IM provider server <b>120</b> for delivery to the recipient (or recipients if more than one recipient is to be invited). In block <b>425</b>, for the embodiment, the game <b>265</b> is launched on the inviter device <b>200</b>.

0039In various embodiments, e.g. where game play requires multiple players, the game play may be suspended until the recipient joins the gaming session. Accordingly, in decision block <b>430</b>, processing loops in a waiting period until it is determined that game data has been received from at least sufficient number of the recipient devices <b>150</b> in response to the sent invitation(s) for the game to commence. Once decision block <b>430</b> determines that “sufficient” game data has been received from the required number of recipients (which may be zero or more), processing proceeds to block <b>435</b> where inviter device <b>200</b> responds and game play commences. Decision black <b>440</b> determines if game play (and the game) is still active and if so, continues the game play process by cycling back to decision black <b>430</b>. Once decision black <b>440</b> determines that game play is no longer active, then the gaming session may end at block <b>445</b>.

0040In alternate embodiments, the inviter device's address (e.g., Internet Protocol address) might not be available in a reliable fashion for peer-to-peer games (e.g. the user is behind a network address translation [“NAT”] device). Accordingly, in one embodiment, session IDs are then used in conjunction with a Relay Server <b>120</b> in order to establish reliable connections between participants. In such an embodiment, the Relay Server may provide two services in order to accomplish this—IP Exchange and Data Relay. The devices (also referred to as Clients in this context) may connect to the Relay Server using standard Internet protocols (e.g. TCP/IP). The IP Exchange may be used for game clients to translate a given session ID into a collection of IP Addresses for all participants. Since the session ID is unique to a given IM Conversation, and reasonably random in generation, only the appropriate clients will have access to these IP Addresses. After the IP Addresses have been exchanged, the clients will attempt to make a direct connection to a designated host. If the connection was not successful, they may rely on the Relay Server to proxy data between the clients. In one embodiment, the Relay Server does not contain any game logic and only ferries the data, ignorant of its meaning. If the GCM <b>275</b> is an active application, and can figure out the IP Address of the inviter, that information can be appended to the invitation link. In that case, the relay server <b>120</b> would only be used in the case that the clients could not directly connect to the host. The Relay Server and direct connections to the host can be used in combination to transmit data between all participants. Furthermore, even if the relay server <b>120</b> is used for an initial connection, in some embodiments, further attempts to connect at a peer-to-peer level may be attempted.

0041Accordingly, <figref idref="DRAWINGS">FIG. 5</figref> illustrates a similar gaming session to the one shown in <figref idref="DRAWINGS">FIG. 3</figref>, however using a Relay Server <b>120</b>. In <figref idref="DRAWINGS">FIG. 5</figref>, in like manner, the gaming session begins with a game selection <b>505</b>. Next, the inviter device <b>200</b> composes <b>510</b> an invitation link to the gaming session for the recipient device <b>150</b>. The invitation link is encapsulated within an IM message and sent <b>515</b> via the IM provider server <b>110</b> to the recipient device <b>150</b>. Concurrently, or shortly thereafter, the inviter device may launch <b>520</b> the game <b>265</b> for which an invitation was sent to the recipient device <b>150</b>. As described earlier, the game may execute on the inviter device, the recipient device or both. With the employment of a Relay Server <b>120</b>, the game may also execute on a game server, such as Central Game Server <b>130</b>.

0042Meanwhile, at the recipient device <b>150</b>, the game invitation link is accepted <b>525</b> and another copy the game may also be optionally launched <b>530</b> on the recipient device <b>150</b>. With one or both the inviter device <b>200</b> and the recipient device <b>150</b> executing the game, both the recipient device <b>150</b> and the inviter device <b>200</b> send <b>535</b> their user names and session IDs to the relay server <b>120</b>. The relay server <b>120</b> associates <b>540</b> all the user names with the same session IDs as part of the same game session. Next, the relay server <b>120</b> returns access data <b>545</b> (e.g., IP address and connection IDs) along with a list of current user names to each of the inviter device <b>200</b> and recipient device(s) <b>150</b>. The recipient device(s) <b>150</b> and inviter device <b>200</b> respond with game event data <b>550</b> back to the relay server <b>120</b> to commence and play the gaming session.

0043In various embodiments, the communications described above and shown in <figref idref="DRAWINGS">FIG. 5</figref> are merely one exemplary set of communications between the inviter device <b>200</b>, the relay server <b>120</b> and the recipient device <b>150</b>. Other communications, both more and fewer, may be employed in other embodiments.

0044In accordance with the above-described communications between an inviter device <b>200</b> and a recipient device <b>150</b> using a relay server <b>120</b>, <figref idref="DRAWINGS">FIG. 6</figref> illustrates a process within the relay server for a gaming session with at least one inviter device <b>200</b> and at least one recipient device <b>150</b>. The gaming session process <b>600</b> begins at block <b>605</b> where user names with a common session ID are obtained. In block <b>610</b>, the user names with a common session ID are associated with each other as belonging to a common gaming session. In block <b>615</b>, the relay server responds to the users of the gaming session with access data (e.g., IP address and connection IDs) along with a list of current user names for the gaming session. Next in decision block <b>620</b> a determination is made that the game session is still active (e.g., has not timed out or obtained an explicit indication of a session end). In block <b>625</b>, game data is obtained from users of the active game session. The game data is then relayed (e.g., forwarded or otherwise communicated) to the other users of the game session in block <b>630</b>. Processing loops back to decision block <b>620</b> until a determination has been made in decision block <b>620</b> that the game session is no longer active. At which point, the game session ends in block <b>635</b>.

0045As described earlier, Central Game Server(s) <b>130</b> may be used in the case of games that have true client/server topologies, and game logic is run on the game server to facilitate play. Games of this variety may use reservation IDs for invitations that are sent via an IM Message. The reservation ID provides clients a facility to designate a location to meet “within” the Central Game Server. The clients provide the reservation ID to the central game server when a connection is established. If that reservation ID is currently in use, the Central Game Server <b>130</b> will provide all the necessary routing information for the client to navigate to it. If the reservation ID is not currently in use, the central game server will create a new instance of that game and then provide the routing information. This allows the clients to connect in any order and still arrive at the same “location.” In addition, the reservation ID can be queried from the central game server during game play, such that an invitation can be composed while the game is already in progress. Again, the reservation ID is generated in a manner that ensures only participants in the IM conversation should have access to the game instance.

0046In the central game server embodiment, a reservation ID is sent from the inviter device <b>200</b> to the recipient device <b>150</b> via an IM message. The game client <b>265</b> is launched on both machines with the reservation ID. The reservation ID is sent to the central game server <b>130</b> at connect time. The central game server <b>130</b> will provide routing information to let the client navigate to the correct game instance. It will also create the game instance as needed. After both clients navigate directly, the central game server <b>130</b> will perform game logic and be sending/receiving game play data. The specific communications between the devices are shown in <figref idref="DRAWINGS">FIG. 7</figref> and described below.

0047In <figref idref="DRAWINGS">FIG. 7</figref>, where one embodiment of the communication protocol is illustrated, the gaming session begins with a game selection <b>705</b>. Next, the inviter device <b>200</b> composes <b>710</b> an invitation link with a reservation ID to the gaming session for the recipient device <b>150</b>. The invitation link is encapsulated within an IM message and sent <b>715</b> via the IM provider server <b>110</b> to the recipient device <b>150</b>. Concurrently, or substantially thereafter, the inviter device optionally launches <b>720</b> a “thin” client of the game <b>265</b> for which an invitation was sent to the recipient device <b>150</b>.

0048Meanwhile, at the recipient device <b>150</b>, the game invitation link is accepted <b>725</b> and another “thin client” of the game is launched <b>730</b> on recipient device <b>150</b>. With both the inviter device <b>200</b> and the recipient device <b>150</b> executing the game, both the recipient device <b>150</b> and the inviter device <b>200</b> send <b>735</b> their user names and reservation IDs to the central game server <b>130</b>. The central game server <b>130</b> associates <b>740</b> all the user names with the same reservation IDs as part of the same game session. The central game server <b>130</b> also creates <b>745</b> (or accesses and existing) game instance corresponding to the reservation ID. Next, the central game server <b>130</b> returns <b>750</b> access data (e.g., IP address and connection IDs) along with a list of current user names to each of the inviter device <b>200</b> and recipient device(s) <b>150</b>. The recipient device(s) <b>150</b> and inviter device <b>200</b> respond with game event data <b>755</b> back to the central game server <b>130</b> to commence and play the gaming session.

0049In various embodiments, the communications described above and shown in <figref idref="DRAWINGS">FIG. 7</figref> are merely one exemplary set of communications between the inviter device <b>200</b>, the central game server <b>130</b> and the recipient device <b>150</b>. Other communications, both more and fewer, may be employed in other embodiments.

0050When the inviter device <b>200</b> and all recipient devices <b>150</b> connect to the central game server <b>130</b> as clients, they would communicate a reservation ID from the invitation link, and the central game server <b>130</b> would direct them to a specific instance of the game hosted at the central game server <b>130</b>. These reservation IDs can be generated before the games <b>265</b> have been launched, or even installed. While an existing game <b>265</b> is in progress, the appropriate reservation ID would be queried from the game instance and included in an invitation link.

0051In accordance with the above-described communications between an inviter device <b>200</b> and a recipient device <b>150</b> having a central game server <b>130</b> hosted gaming session, <figref idref="DRAWINGS">FIG. 8</figref> illustrates a process within the central game server <b>130</b> for such a gaming session. The gaming session process <b>800</b> begins at block <b>805</b> where user names with a common reservation ID are obtained. In block <b>810</b>, the user names with a common reservation ID are associated with each other as belonging to a common gaming session. Next, in decision block <b>815</b> a determination is made whether a game instance corresponding to the received reservation ID is already active. If no game instance is active, then in block <b>820</b> a new game instance corresponding to the reservation ID is created and processing continues to block <b>825</b>. If however in decision block <b>815</b> it was determined that a game instance corresponding to the reservation ID is already active, then processing proceeds directly to block <b>825</b>. In block <b>825</b>, the central game server <b>130</b> responds to the users of the gaming session with access data (e.g., IP address and connection IDs) along with a list of current user names for the gaming session. Next in decision block <b>830</b> a determination is made that the game session is still active (e.g., has not timed out or obtained an explicit indication of a session end). In block <b>835</b>, game data is obtained from users of the active game session. The central game server <b>130</b> processes the game data for the game instance in block <b>840</b>. In block <b>845</b>, the status of the game instance is updated with the processed game data. Next, in block <b>850</b>, updated game data is then sent to the users of the game session in block <b>850</b>. Processing loops back to decision block <b>830</b> until a determination has been made in decision block <b>830</b> that the game session is no longer active. At which point, the game session may end in block <b>855</b>.

0052Although specific embodiments have been illustrated and described herein, it will be appreciated by those of ordinary skill in the art and others, that a wide variety of alternate and/or equivalent implementations may be substituted for the specific embodiment shown in the described without departing from the scope of the present invention. For example, while illustrative linear on-line gaming sessions have been described above; in various embodiments more complex games having multiple threads and flows of operation may be implemented. This application is intended to cover any adaptations or variations of the embodiment discussed herein. Therefore, it is manifested and intended that the invention be limited only by the claims and the equivalence thereof.