US20060287099A1

On-line gaming session and party management

Claim Score by NHIP

Abstract

A game hosting service manages game sessions and groups of players. The service creates, starts, and ends a game session. The service also manages the joining and deleting of players and groups of players both prior to and during game play. The service collects, stores, and optionally arbitrates statistics for each player such a game score and relative ranking with other players. The service assigns a group ID to a group of players to allow the group to migrate across game sessions. The game hosting service utilizes session management APIs to nest multiple sessions, thus enabling groups of players to remain intact across multiple sessions.

US20060287099A1, drawing sheet 1 — Sheet 1 of 15

Term

Projected expiry 12 June 2029.

20 claims: 3 independent, 17 dependent

1
A method for managing a computer-based game session, said method comprising:establishing, by a game hosting service, a first session identifier indicative of a group of players;establishing, by said game hosting service, a second session identifier indicative of said group of players and a game session;said game hosting service utilizing said second session identifier to allow said group of players, to replay said game;and said game hosting service utilizing said first session identifier to allow said group of players, to join another game session.
7
A method for managing a computer-based game session between a game hosting service and at least one game device, said method comprising:creating, by said game hosting service, a game session;joining, by said game hosting service, at least one of a player and a group of players to said game session;starting, by said game hosting service, said game session;ending, by said game hosting service, said game session;and removing, by said game hosting service, an association of all players with said game session.
14
Broadest claimClaim Score 79, broad(NHIP)A computer-readable medium having computer-executable instructions for performing the acts of:creating, by a game hosting service, a game session;joining, by said game hosting service, at least one of a player and a group of players to said game session;starting, by said game hosting service, said game session;ending, by said game hosting service, said game session;and removing, by said game hosting service, an association of all players with said game session.

Independent claims3

130 paragraphs in 6 sections, as filed

0001This application is a continuation-in-part of U.S. patent application Ser. No. 11/156,877, filed Jun. 20, 2005, titled “SETTING UP ON-LINE GAME SESSIONS OUT OF A GAME CONTEXT,” the disclosure of which is hereby incorporated by reference in its entirety.

TECHNICAL FIELD

0002The technical field generally relates to gaming and multimedia devices, and more specifically relates to on-line game sessions.

BACKGROUND

0003In online gaming, game hosting services and game developers have created a number of ways to track and personalize the online gaming experience. One drawback of existing systems is that many of the features have grown up independent of each other. Games send blobs of data about gamers back and forth to a central service, but the service has no way to understand and aggregate the data outside of the game context. Games can host their own Websites, but the data displayed there is not universally accessible to other games.

0004In a sense, then, the service and games offer two parallel communities that offer great—but separated—resources for gamers. First, in the game community, while playing a game, the gamer can see the community of others who play the specific game, the leaderboards for that game, and his personal achievements in that game. A game can tell a gamer, from the Service data, if a Friend is online, but it can't tell the gamer what, exactly that Friend is doing on the Service or when he will be available.

0005Second, in the service community, the service knows a gamer player's history, all of the games he's played, the amount of time he spends online, the size of his Friends list and all of the games that Friends have played or are playing, the Friends invites sent and received, the Messages sent and received, and all of the Feedback the gamer has given and received.

0006Systems have tried to leverage these on-line communities to match various players to allow them to play multi-player games. Nevertheless, in general such systems, which typically emphasize skill or experience in a single game or small family of games, do not allow groups of players who are likely to enjoy shared interaction based on a variety of personal considerations to form a group outside of the game context and then collectively engage in a multiplayer game.

0007Further, because matchmaking interfaces have typically been part of each individual game's code, gamers have not had the ability to create a match with other players in one game and then roam with that group of players to another game.

SUMMARY

0008This Summary is provided to introduce a selection of concepts in a simplified form that are further described below in the Detailed Description Of The Illustrative Embodiments. This Summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used to limit the scope of the claimed subject matter.

0009Systems and methods for playing multi-player computer-based games receive configuration settings from a plurality of different games. The configuration settings provides information regarding parameters of the game so that said service has the capability of matching a plurality of players according to the game's allowed parameters or let players create party sessions according to those parameters and then invite others to play in them.

0010A game hosting service is provided that has a database with information about a plurality of players and information about a plurality of different games that operate on a computing device. Coupled to the service is an input device for receiving from a player a selection of one of the plurality of different games and the player's particular choice among the configuration settings for said game. The service is functional apart from the game and allows the player to select any one of a number of different games from different game developers. Also coupled to the service is an output device for outputting a start message to a plurality of computing devices wherein said computing devices are selected as a function of the plurality of players and the one of the plurality of different games. The message contains information indicative of the configuration settings so that all of the computing devices can begin the game in the same way.

0011The game hosting service also includes party and session management APIs (application programming interfaces) for maintaining between the game hosting service and the game consoles a unique identifier that describes groupings of players. The game hosting service manages creation, starting, ending, and deletion of game sessions. The game hosting service manages statistics arbitration functions and also functions to determine if players can join in a game session. The game hosting service collects, stores and optionally arbitrates statistics for each player, including game score and relative standing with respect to other players in a game session. Also coupled to the service is an input device for accepting a game completed message from a game. This message contains information about the party of players returning to the console to choose to play a different game.

0012The information in the database about the plurality of players comprises information indicative of game playing skill and social attributes of said players. The systems and methods are capable of matching a subset of players as a function of the game playing skill and social attributes of said players.

BRIEF DESCRIPTION OF THE DRAWINGS

0013The foregoing summary, as well as the following detailed description of on-line gaming session and party management, is better understood when read in conjunction with the appended drawings. For the purpose of illustrating on-line gaming session and party management, there is shown in the drawings exemplary constructions thereof; however, on-line gaming session and party management is not limited to the specific methods and instrumentalities disclosed. In the drawings:

0014<figref idref="DRAWINGS">FIG. 1</figref> is a block diagram of an exemplary computer network environment in which aspects of on-line gaming session and party management can be implemented;

0015<figref idref="DRAWINGS">FIG. 2</figref> is a block diagram illustrating an exemplary console that can be incorporated into a network computing environment such as the network computing environment of <figref idref="DRAWINGS">FIG. 1</figref>;

0016<figref idref="DRAWINGS">FIG. 3</figref> is a block diagram illustrating the interaction of a console with the remote service;

0017<figref idref="DRAWINGS">FIG. 4</figref> illustrates the information gathered to build a User Profile;

0018<figref idref="DRAWINGS">FIG. 5</figref> is example illustration of a user interface displaying User Profile information;

0019<figref idref="DRAWINGS">FIG. 6</figref> is another example illustration of a user interface displaying User Profile information;

0020<figref idref="DRAWINGS">FIG. 7</figref> is anther example illustration of a user interface displaying User Profile information;

0021<figref idref="DRAWINGS">FIG. 8</figref> illustrates a feedback mechanism whereby a game player can provide feedback on other game players.

0022<figref idref="DRAWINGS">FIG. 9</figref> through <figref idref="DRAWINGS">FIG. 12</figref> depict an exemplary scenario of a game hosting service managing a computer-based game session;

0023<figref idref="DRAWINGS">FIG. 13</figref> is a flow diagram of an exemplary process for managing an on-line game session;

0024<figref idref="DRAWINGS">FIG. 14</figref> is a flow chart illustrating an exemplary user interface flow in setting up a matchmaking session;

0025<figref idref="DRAWINGS">FIG. 15</figref> illustrates a user interface whereby players can filter choices for a matchmaking session and then choose among a list of sessions according to their descriptors;

0026<figref idref="DRAWINGS">FIG. 16</figref> also illustrates a user interface whereby players can filter choices for a matchmaking session and then choose among a list of sessions according to their descriptors; and

DETAILED DESCRIPTION OF ILLUSTRATIVE EMBODIMENTS

0027<figref idref="DRAWINGS">FIG. 1</figref> is diagram of an exemplary computer network that serves to illustrate aspects of on-line gaming session and party management. Here computers 100a-100e may host various ones of the computing objects such as games and other applications. Although the physical environment shows the connected devices as computers, such illustration is merely exemplary and may comprise various digital devices such as PDAs, game consoles, etc. Moreover, communications network 160 may itself comprise a number of computers, servers and network devices such as routers and the like.

0028There is a variety of systems, components, and network configurations that support distributed computing environments. For example, computing systems may be connected together by wireline or wireless systems, by local networks or widely distributed networks. Currently, many of the networks are coupled to the Internet which provides the infrastructure for widely distributed computing and encompasses many different networks. Aspects of the on-line gaming session and party management could be usable to distribute computer-readable instructions, code fragments, applications and the like to various distributed computing devices.

0029The network infrastructure enables a host of network topologies such as client/server, peer-to-peer, or hybrid architectures. The “client” is a member of a class or group that uses the services of another class or group to which it is not related. Thus, in computing, a client is a process (i.e., roughly a set of instructions or tasks) that requests a service provided by another program. The client process utilizes the requested service without having to “know” any working details about the other program or the service itself. In a client/server architecture, particularly a networked system, a client is usually a computer that accesses shared network resources provided by another computer (i.e., a server). A server is typically a remote computer system accessible over a remote network such as the Internet. The client process may be active in a first computer system, and the server process may be active in a second computer system, communicating with one another over a communications medium, thus providing distributed functionality and allowing multiple clients to take advantage of the information-gathering capabilities of the server.

0030Clients and servers communicate with one another utilizing the functionality provided by a protocol layer. For example, Hypertext-Transfer Protocol (HTTP) is a common protocol that is used in conjunction with the World Wide Web (WWW) or, simply, the “Web.” Typically, a computer network address such as a Uniform Resource Locator (URL) or an Internet Protocol (IP) address is used to identify the server or client computers to each other. Communication among computing devices is provided over a communications medium. In particular, the client and server may be coupled to one another via TCP/IP connections for high-capacity communication.

0031In general, the computer network may comprise both server devices and client devices deployed in a network environment (in a peer-to-peer environment devices may be both clients and servers). Communications network 160 may be a LAN, WAN, intranet or the Internet, or a combination of any of these that facilitates communication among a number of computing devices 10a-10e. Moreover, communication network 160 may comprise wireless, wireline, or combination wireless and wireline connections. Additionally, the computer network may comprise a distributed computing environment. In such an environment a computing task may be spread over a number of computing devices that are addressable elements in a computer network.

0032According to an aspect of on-line gaming session and party management, communication network 160 may host a service 150 that is accessible from the plurality of computers 100a-100e. The service 150 gathers information and tracks users of computers 100a-100e to provide computing services for all of the users of the service.

0033<figref idref="DRAWINGS">FIG. 2</figref> illustrates the functional components of a multimedia/gaming console 100 that may be used as the computers 100a-100e in the network of <figref idref="DRAWINGS">FIG. 1</figref>. The multimedia console 100 has a central processing unit (CPU) 101 having a level 1 cache 102, a level 2 cache 104, and a flash ROM (Read Only Memory) 106. The level 1 cache 102 and a level 2 cache 104 temporarily store data and hence reduce the number of memory access cycles, thereby improving processing speed and throughput. The CPU 101 may be provided having more than one core, and thus, additional level 1 and level 2 caches 102 and 104. The flash ROM 106 may store executable code that is loaded during an initial phase of a boot process when the multimedia console 100 is powered ON.

0034A graphics processing unit (GPU) 108 and a video encoder/video codec (coder/decoder) 114 form a video processing pipeline for high speed and high resolution graphics processing. Data is carried from the graphics processing unit 108 to the video encoder/video codec 114 via a bus. The video processing pipeline outputs data to an A/V (audio/video) port 140 for transmission to a television or other display. A memory controller 110 is connected to the GPU 108 to facilitate processor access to various types of memory 112, such as, but not limited to, a RAM (Random Access Memory).

0035The multimedia console 100 includes an I/O controller 120, a system management controller 122, an audio processing unit 123, a network interface controller 124, a first USB host controller 126, a second USB controller 128 and a front panel I/O subassembly 130 that are preferably implemented on a module 118. The USB controllers 126 and 128 serve as hosts for peripheral controllers 142(1)-142(2), a wireless adapter 148, and an external memory device 146 (e.g., flash memory, external CD/DVD ROM drive, removable media, etc.). The network interface 124 and/or wireless adapter 148 provide access to a network (e.g., the Internet, home network, etc.) and may be any of a wide variety of various wired or wireless adapter components including an Ethernet card, a modem, a Bluetooth module, a cable modem, and the like.

0036System memory 143 is provided to store application data that is loaded during the boot process. A media drive 144 is provided and may comprise a DVD/CD drive, hard drive, or other removable media drive, etc. The media drive 144 may be internal or external to the multimedia console 100. Application data may be accessed via the media drive 144 for execution, playback, etc. by the multimedia console 100. The media drive 144 is connected to the I/O controller 120 via a bus, such as a Serial ATA bus or other high speed connection (e.g., IEEE 1394).

0037The system management controller 122 provides a variety of service functions related to assuring availability of the multimedia console 100. The audio processing unit 123 and an audio codec 132 form a corresponding audio processing pipeline with high fidelity and stereo processing. Audio data is carried between the audio processing unit 123 and the audio codec 132 via a communication link. The audio processing pipeline outputs data to the A/V port 140 for reproduction by an external audio player or device having audio capabilities.

0038The front panel I/O subassembly 130 supports the functionality of the power button 150 and the eject button 152, as well as any LEDs (light emitting diodes) or other indicators exposed on the outer surface of the multimedia console 100. A system power supply module 136 provides power to the components of the multimedia console 100. A fan 138 cools the circuitry within the multimedia console 100.

0039The CPU 101, GPU 108, memory controller 110, and various other components within the multimedia console 100 are interconnected via one or more buses, including serial and parallel buses, a memory bus, a peripheral bus, and a processor or local bus using any of a variety of bus architectures. By way of example, such architectures can include a Peripheral Component Interconnects (PCI) bus, PCI-Express bus, etc.

0040When the multimedia console 100 is powered ON, application data may be loaded from the system memory 143 into memory 112 and/or caches 102, 104 and executed on the CPU 101. The application may present a graphical user interface that provides a consistent user experience when navigating to different media types available on the multimedia console 100. In operation, applications and/or other media contained within the media drive 144 may be launched or played from the media drive 144 to provide additional functionalities to the multimedia console 100.

0041The multimedia console 100 may be operated as a standalone system by simply connecting the system to a television or other display. In this standalone mode, the multimedia console 100 allows one or more users to interact with the system, watch movies, or listen to music. However, with the integration of broadband connectivity made available through the network interface 124 or the wireless adapter 148, the multimedia console 100 may further be operated as a participant in the larger network community as illustrated in <figref idref="DRAWINGS">FIG. 1</figref>.

0042According to an aspect of on-line gaming session and party management, when a game is executed on console 100, it provides information to a service operating on communications network 160. The service tracks the information for all of the users connected to the service to provide a rich user experience. The service tracks user information across games, consoles, computing devices, etc. By tracking the information for all users of the service, the service can aggregate statistics for all users and measure game playing ability, provide a richer user experience by providing information about friends (e.g., what game they are playing and what skill level they have attained), track user achievements and generally measure statistics for a game aggregated over a large user community.

0043In order to provide a consistent data set across games, the system contemplates a schematized, configuration driven process where each game generates a configuration file (according to the schema defined by the service) that defines the game data for a particular game. Through a game configuration process, games describe the data the game generates about each game player. By using the configuration process, the service will be able to understand the data as it flows from the game, and it will be able to integrate it in meaningful ways with the other data that the service understands to create a rich profile of each user of the service. The profile will follow the user wherever he goes on the service, i.e. it is game and location independent.

0044For each user (alternatively referred to as a player or gamer), the service will collect a number of pieces of data (called Profile Data) to build the User Profile in every game session—and even after a game session is concluded. In general, the pieces of the service experience that feed profile include:

00451. What the user says about himself or herself (including account set up and the construction of an elaborate personal profile, including the preferred social gameplay “zone”).

00462. What others say about the user (feedback scores and a publicly visible reputation).

00473. What the games say about the user (game configuration and integration of data that comes out of game play to compute a player's skill, among other things).

00484. What the system says about the user (time online, aggregates of games played, Friends list, console behavior etc.)

0049The system creates a “User Profile,” which serves as a building block for services and applications that aim to create a social community of gamers and grow relationships among players. The User Profile is the entirety of information (e.g., metadata) related to a specific user (i.e., the game player's digital identity). The User Profile is developed from a set of services that collect and expose this information in a meaningful way to the community. The User Profile also provides for personalization such that users can customize and enhance their gaming experience. As will be discussed in greater detail below, the User Profile consists of various components, including, but not limited to, a Gamercard, game achievements, and gamer preferences.

0050Referring to <figref idref="DRAWINGS">FIG. 3</figref>, there is illustrated an overview of an exemplary architecture that may be used to implement the User Profile interaction as well as user interaction with the game session service described more fully herein. The console 100 interacts with a remote service 150 that provides services 158 such as voice/chat, a friends list, matchmaking, content download, roaming, feedback, tournaments, voice messaging, and updates to gamers. The service 150 also maintains the User Profiles in a profile database 162 and configuration data 164 used by the services 158 and games 154. The service 150 collects User Profiles, aggregates, processes information supplied by other services 158, and fulfills real-time client requests for retrieving User Profile-related services. The User Profiles in the database 162 are also used by the games 154 to enable, among other things, personalization and customization, etc.

0051Using the console 100, the user may interact with a Guide 156. The Guide 156 provides an interface where the user may navigate to, and enter, various online areas and options provided by the service 158. The configuration data 164 stored by the service 150 may be used to determine features and options provided by the Guide 156. When the game 154 is running, a defined set of APIs (including SetContext, SetProperty, SetAchievement, and Session APIs for writing data about players, and a number of specialized read APIs for viewing stats, achievements, and other User Profile data) are used to call and interact with the services 158. When requesting User Profile information via the APIs, the game 154 may pass a unique identifier of a user. The service 150 may return a Gamercard (discussed below), game stats, game achievements, affiliations, game settings, etc. Additional details of the various aspects of the exemplary architecture are provided below.

0052Service 158 assists in tracking and displaying a wide-variety of in-game stats, such as number of points, best lap times, and (importantly, for calculating the skill value needed in Matchmaking) win/loss. All stats are provided by the various games that a user plays and provided to the service for inclusion in a player's User Profile. For example, a first-person shooter title may want to define a ‘Points’ Property to be tracked independently for each ‘Map’ Context (e.g. 5 Points on Blood Creek vs. 10 Points on Battle Range). That information could be displayed as: <tables id="TABLE-US-00001" num="1"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="3"><colspec colname="OFFSET" colwidth="35PT" align="left" /><colspec colname="1" colwidth="70PT" align="left" /><colspec colname="2" colwidth="112PT" align="center" /><thead><row><entry /><entry /></row><row><entry /><entry namest="OFFSET" nameend="2" align="center" rowsep="1" /></row><row><entry /><entry>“PER-MAP POINTS”</entry><entry /></row><row><entry /><entry>Map</entry><entry>Points</entry></row><row><entry /><entry namest="OFFSET" nameend="2" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="3"><colspec colname="OFFSET" colwidth="35PT" align="left" /><colspec colname="1" colwidth="70PT" align="left" /><colspec colname="2" colwidth="112PT" align="char" char="." /><tbody valign="top"><row><entry /><entry>Blood Creek</entry><entry>5</entry></row><row><entry /><entry>Battle Range</entry><entry>10</entry></row><row><entry /><entry namest="OFFSET" nameend="2" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0053Each game can support a minimal set of information that matches the character of the game and that can be tracked for each user of the service 158.

0054<figref idref="DRAWINGS">FIG. 4</figref> illustrates the information gathered to build a User Profile. The owner of User Profile 166 can edit his/her User Profile 166 directly and control who can view each section of the User Profile. The User Profile 166 may be edited via general fields (e.g., tile, country, language, gender, greeting, etc.) and/or system settings (e.g., voice output, controller vibration, character name, game format, game mode, etc.). Privacy/Opt-out Settings can be tuned for the User Profile 166 to, e.g., restrict presence information only to friends, allow game achievements to be visible to all, etc.

0055The User Profile is associated with a list of other players known as “Friends.” Friends are other gamers who the player has invited (and who have accepted the invitation) to be on a Friends List.

0056The User Profile is also associated with a list of players known as “Recent Players.” The Recent Players are a list of the most recent N players that the User Profile owner has played with across all games.

0057The User Profile 166 may include feedback provided by other players 170. Feedback helps others learn about a particular gamer. For example, if the gamer uses foul language or aggressive play in game sessions, other gamers may submit feedback to the service 150. The feedback mechanism improves the user experience by building reputations. Players are therefore anonymous, but not unknown because of the accumulated feedback.

0058In another aspect of the system, the service 150 and games 154 track online and offline activity of users to provide usage statistics in the Gamer Profile 166. When a gamer plays online, a particular game title is added to list of games played that is made visible to others. While offline, the game console 100 and game 154 track the user's activity via a mechanism for instrumenting games to collect detailed information about a specific player's in-game statistics and accomplishments. The Gamer Profile 166 is updated during the next connection to the service 150 to reflect the offline play. Game achievements may be reported to the service 154 by games via the User Profile data mechanism.

0059Referring to <figref idref="DRAWINGS">FIGS. 5-8</figref>, the Gamer Profile can be viewed in a number of ways and forms, and is typically displayed in the Gamercard 172. The Gamercard 172 is the visual representation of the Gamer Profile 166 that is available to games on the console 100 and, e.g., the web. The Gamercard 172 serves as a summary or snapshot of a player's Gamer Profile 166. Gamers may use the Gamercard to set up a matchmaking list where gamers are added to a preferred player's list to play again in the future.

0060As shown in <figref idref="DRAWINGS">FIG. 5</figref>, the Gamercard 172 may be divided into two regions, a base area 174 and a context-specific (or extended) area 176. The base area 174 provides a set of Gamer Profile information in a standard and consistent way across multiple contexts, whereas the extended area 176 may be customized to fit a specific context. Although the Gamercard 172 of <figref idref="DRAWINGS">FIGS. 5-8</figref> are shown in the context of the Guide 156, the Gamercard 172 may be visually separated from the rest of the screen and adopt the background color of the screen it is displayed on.

0061The base area 174 may be provided in different variants corresponding to differing contexts, while being a consistent view within each context. For example, an online Gamercard 172 is shown when one player is looking at another player's Gamercard 172 during an online session. The online base area 174 includes details such as the player's Gamertag, gamer tile, overall community rating, gamer Cred (a points-based reward points system), gamer zone, country, membership tier, awards, etc. An offline Gamercard 172 is shown when a player is looking at his/her own Gamercard 172. The offline base area 174 may include a subset of the online base area and may further include information regarding titles played and time played. The base area 174 of a Gamercard 172 is preferably fixed in size, has a consistent, static layout and has a fixed placement of all information elements, such as Tile or Gamer Cred.

0062The extended area 176 may include a set of Gamercard Actions, such as “View Profile,” “Send Friend Invite,” and “Send Feedback,” etc. The extended area of the Gamercards is preferably not fixed in size, because it may vary based on the context. As shown in <figref idref="DRAWINGS">FIGS. 5-7</figref> a user may scroll through the list of other users via the Guide 156 and a friends list 178. The Gamercard for other users may be displayed as the user scrolls among his/her friends or the user may be presented with an option to see a full view of the Gamer Profile. The full view mode consists of different views of the extended area 176 and may include several sections, such as a Profile Summary, Community Feedback, Game Achievements, Activity, and Social Network. The Guide 156 may advance through the list of friends, Recent Players (and summary sections for each player), a user home page for navigating to various options and settings, etc.

0063The profile summary includes information regarding number of games played, time played, tile, greeting, etc. The community feedback includes ratings on style, sportsmanship, language, cooperation, etc. The game achievements section includes recent titles, experience points (gamer Cred), time played, game-specific stats and achievements, etc. The activity section includes Gamer Cred earned, sessions played, total time played, active days on the service, etc. The social network includes friends, groups, positive/negative feedback count, etc.

0064Matchmaking: For online, multi-player games, Matchmaking connects a game player to a session. A Match made session is an instance of game play that includes two (2) or more players or gamers playing a game until they either decide to terminate the session or until the session meets its end criteria (as defined by the game). The person who creates the session is the host. Some games are hostless, meaning that the game does not assign any special function to the person who originated the game. In such a case, the originator may, in fact, be a person who was searching for a session with specific criteria and, when it was not found, the game created a session for the person and advertised it for others to match into it. Matchmaking involves joining a session that has, as a minimum, one player already in place. A session is said to be joinable if there are open slots available to the person seeking a slot and the game play has not yet begun (the game is in “lobby” state). Some games that have join in progress sessions will advertise that a session is joinable until every public slot is filled. A gamer makes a Match by selecting “Matchmaking” in a game or in an out-of-game Matchmaking system. The Matchmaking UI may allow a gamer to add some filters to his search for a session (e.g. like specifying a map or difficulty level), or it may push a gamer directly into a search query. In most cases, with or without filters, a gamer is given a session search result which consists of a list of sessions. Each session is defined by a session descriptor that includes a short summary the most salient information about that session. A gamer then selects a session and joins it. Typically, a player then enters a lobby and awaits other players to match into the game before game play begins. In some cases, no search result is shown, and players are dropped instead directly into the lobby of the game that best meets their search criteria.

0065One kind of matchmaking, “Social Matchmaking,” included in this system leverages User Profile data and the “Affiliates List” to improve the social dynamics of match sessions. When a game player chooses to matchmake into a session in the system described here as “Social Match,” in the first session, the profile data he has set describing himself is used to “prime the pump” and find the best fellow new gamers to play with. Just by playing, the game player associates with a group of fellow gamers who become Recent Players on an “Affiliates List” (described below). The service preferably prioritizes playing with Recent Players over strangers in future session, but once a game player gives positive feedback, these “positive feedback” people are remembered by the system and are given even higher priority. Over time, as a gamer becomes very familiar with a set of players, he invites them to become friends. These friend gamers are given the highest priority.

0066This Social Matchmaking system will connect people who have similar intent and who share a similar profile to insure that they all have a good time, in and out of game play (but primarily in game play). Matchmaking—with its use feedback and profile data—facilitates people expanding and refreshing their online community with increasingly refined matches over time. Ultimately, Matchmaking will bind people to the service as a safe, secure place to meet new people and create a history of positive experiences.

0067Several of the aspects of User Profile that surface in a Gamercard can be used to match a game player to a session. At a high level, according to an aspect of on-line gaming session and party management, when a game player signs up in the service 150, he is asked to select a Gamer Zone that best describes the kind of social environment he prefers to play in. Before the service has other profile data to use, this Gamer Zone is used to match the game player with other players who have selected the same Zone. This match is done by a simple database query looking for Social sessions that contain a majority of players with this same Zone.

0068As time goes on and the service has additional data about each player, this Match query can be improved by averaging multiple key aspects of User Profile (still the Zone, but as time goes on, also feedback reputation, skill computed via stats, and his experience defined by Achievements achieved) for each participant in a session. The system then can provide a session “profile” that can be compared with the User Profile of a player seeking a match. The match system can then query this session profile by comparing it to the values in a User Profile of an individual who wishes to join the session. If the match of the User Profile is sufficiently close to the session profile values (sharing the same Zone and within a pre-specified range for each of the numeric values for reputation, skill, and experience), then the user will be shown that session as a Match. If the match comparison is not within the pre-specified ranges, then the user's query will continue on to compare to other sessions' session profiles until a positive result is achieved. In exemplary embodiments, NAT type, physical proximity to other players, time played on the system, games played, etc., or a combination thereof for example, are folded in on the back end when a Match search is performed.

0069In addition to Matchmaking based on a query with User Profile, the Social Matchmaking system, in conjunction with the tracking of friends, Recent Players, and feedback on Recent Players, builds a network of Affiliates who are prioritized for Match.

0070The Affiliates list is a prioritized list of people for a player that includes (1) Friends (i.e. people who the player has invited, and who have accepted the invitation, to a preferred social network that allows exchange of messages and state information), (2) Positive Feedback people (i.e. people about whom the player has given positive feedback), and (3) Recent Players. The Social Matchmaking service always looks first (before conducting the query above) for the presence of Affiliate sessions on the service. If any person on a player's Affiliates list is online and in a joinable session, the service will return that session. If there are multiple Affiliate sessions, the ones with Friends are given priority over those with Positive Feedback People or those with Recent Players. Positive Feedback People are given priority over Recent Players.

0071In accordance with the above, <figref idref="DRAWINGS">FIG. 6</figref> illustrates a list of Recent Players in the Guide 156. A person is added to a player's Recent Players list when the player has played an online game session with the person. The Gamercard displayed when browsing Recent Players shows the base area and an extended area that provides information regarding recent games, feedback, and presence of the Recent Players. <figref idref="DRAWINGS">FIG. 7</figref> illustrate further details that may be obtained about Recent Players, such as general achievements.

0072Importantly, <figref idref="DRAWINGS">FIG. 8</figref> illustrates a feedback mechanism whereby a game player can provide feedback on other game players. This feedback options is only available on a Gamercard when the viewing player has played with the person before. This feedback information is then used to improve matchmaking results, i.e., indicates whether or not you would want to play with this game player in future games. By giving positive feedback on a person, that person moves up in priority in that player's Affiliates list. Moreover, the feedback affects the game player's reputation and may change the group of players with whom the player is grouped in future games.

0073Feedback is, then, for the purposes of Matchmaking, the creation of a “one-way” friends list, i.e., a low threshold mechanism to build a list of people you meet again and again. This mechanism is generally invisible except as an improved matchmaking experience. For example, when a game player indicates that he would like to play with a particular person again, the system tracks that information in a one-way friend list so that the other player doesn't have to be invited or accept an invitation to be on a friends list.

0074If a player gives negative feedback on a person, that person moves to an “Avoid” list, and for the purposes of Social Matchmaking, future sessions containing that person will be avoided for the player.

0075In additional to social matchmaking as described above (using User Profile data and matching with Affiliates), the system also offers a “Ranked Match” option that matches players only based on their skill in a particular game. This skill, collected as a game statistic, is also stored in the User Profile. Skill-based match is preferred by competitive players.

0076Out-of-game Matchmaking is a multi-part system for creating sessions (as defined above) that includes setting up a game in the match configuration tool, generating a user interface out-of-game (i e. in the console system app UI) that allows gamers to search for a session according to game parameters and the social attributes (User Profile, Affiliates list) known by the service. It also includes a console system app UI (part of the Guide) that allows players to browse Gamercards and invite their Affiliates (friends, Recent Players, and positive feedback people) to assemble a Party of players. The system then offers a “StartSession” message that passes from the console system to the game a schematized list of game settings and unique player IDs associated with each session particpant. It also includes a set of APIs that allow the console and the game to manage the groupings of players assembled in the console application by associating each grouping with a unique ID that can be passed back and forth from console to game. And finally, it includes “GameCompleted” message that allows the game to pass the list of players back to the console application when the players finish the game but wish to stay together as a party and roam to another game.

0077The Match Configuration Tool allows game developers to input the game's matchmaking session description according to a schema. With the tool, the game tells the service the steps that a gamer will need to go through to create a multi-player on-line game session. This definition makes sure that the service understands all of the key game permutations (from map names to vehicle types) so that the service can capture the starting point of a game session. The match configuration tool includes a node that allows games to create one set of Ranked customized settings and one set of Social customized settings. The two edit screens should be identical, except for the “Ranked” v. “Social” label at the top of each screen. These edit screens will be used to created out-of-game match UI that allows gamers to create customized match queries (ala Optimatch) in the Guide.

0078Each edit screen allows a game developer to insert a simple list of contexts and/or properties from those he has already created or that are predefined in the tool (“number of player,” for example, is pre-defined since it is required for all games). Contexts are enumerated lists of strings whereas properties are numeric values (integers or floating point values). An example of a context is “Map” and its enumerations would include all the possible maps available in the game. The game developer can also create and insert new contexts and properties.

0079For each context and property added, the game developer must also provide a localized string label that provides the text that will appear next to the multi-select options in the out-of-game match UI. The default localized string label should be the string label for the context or property itself.

0080The default value for context values in the UI will be based on the default chosen when the context values were created. For properties, however, the developer must specify the range of values, the step size (for numeric properties), and the default.

0081For contexts in which the number of players is relevant, the game indicates the minimum and maximum number of players allowed for each context value setting. For example, for a “map” context, the game can specify that a minimum of 2 players and a maximum of 16 players can play on the “Waterloo” context value.

0082“StartSession” message: The system also provides the format of a StartGame message that the game will need to accept when a gamer has created a session in the out-of-game application according to the schema defined in the configuration tool. This message includes the session choices (map, difficulty level etc.) that the gamer chose based on the options the game developers indicated in the configuration process. With this message, the game can then inject the gamer into a lobby to await others to join the session via matchmaking.

0083The StartGame message contains the following information: <ul id="ul0001" list-style="none"><li id="ul0001-0001" num="0000"><ul id="ul0002" list-style="none"><li id="ul0002-0001" num="0084"> Personally Unique Identifiers (PUIDs) for all gamers in the session </li><li id="ul0002-0002" num="0085"> Host PUID (for Standard games) </li><li id="ul0002-0003" num="0086"> Ranked/Standard Flag </li><li id="ul0002-0004" num="0087"> Unique Party ID </li><li id="ul0002-0005" num="0088"> Game settings (set in “Customize” screen in the system app UI by session host or acting host)—sent as context/property list. </li><li id="ul0002-0006" num="0089"> Game Title ID </li></ul></li></ul>

0090When a game receives a StartGame message, it accepts all of the players into a pre-game lobby. In that lobby, for Ranked games, the game begins a countdown and then injects the players into game play. No gamer has the option to adjust the game settings. For a Social game, the host can choose to adjust game settings if needed, and some detailed game settings (e.g choose car color etc.) can be available to all gamers. The host can then start the game, or the game can start the game as it normally would when a sufficient party is created.

0091GameCompleted Message. When a game is completed and the host chooses to return his party to the out-of-game lobby from the post-game lobby, the game sends the system a GameCompleted message.

0092The GameCompleted message contains the following information: <ul id="ul0003" list-style="none"><li id="ul0003-0001" num="0000"><ul id="ul0004" list-style="none"><li id="ul0004-0001" num="0093"> PUIDs for all gamers in the session (the same as the list from the StartGame message, minus any members who dropped out of the party or disconnected their consoles) </li><li id="ul0004-0002" num="0094"> Host PUID (for Standard games; the host may have changed if the game allows for host migration and the original host dropped out of the game) </li><li id="ul0004-0003" num="0095"> Party ID </li><li id="ul0004-0004" num="0096"> Game Title ID </li><li id="ul0004-0005" num="0097"> Last game settings (these are sent back so that the console app can cache them for the host so that they are pre-set next time the host selects the game in the system app UI) </li></ul></li></ul>

0098Session and Party Management. Session APIs between a game hosting service and various game systems provide a single entity for managing pre-game functions before a session is started, for managing in-game functions while a session is ongoing, and for managing post-game functions after a session is ended. Session APIs also manage arbitration functions and manage parties, or groups, of players. To better understand session APIs, an exemplary scenario is described illustrating interactions between a session and game systems.

0099<figref idref="DRAWINGS">FIG. 9</figref> is an illustration of three game systems and a game hosting service about to interact. <figref idref="DRAWINGS">FIG. 9</figref> shows Blue system 904, Red system 906, Green system 908, and the game hosting service 902 comprising two sessions: session 910 and session 912. Each session has associated session APIs. Each game system can comprise a multimedia console, such as multimedia console 100 of <figref idref="DRAWINGS">FIG. 2</figref>, for example. The game hosting service 902 is advertising the two sessions 910, 912. In this exemplary scenario, player Red is just beginning the matchmaking UI, and player Blue is finishing the same matchmaking UI. Player Green's game is running, but player Green is not yet active.

0100Player Blue is searching for a specific type of session and can not find a session with the correct parameters via the game hosting service 902. As depicted in <figref idref="DRAWINGS">FIG. 10</figref>, Player Blue thus decides to host a session via the Blue game system 904. The session APIs 916 creates session 914 and the session 914 is advertised in Matchmaking. Player Blue waits for more players to join the session 914. Player Red is selecting options in the matchmaking UI. And Player Green is still inactive.

0101As the exemplary scenario continues, Player Red searches for sessions in matchmaking and finds three sessions; session 910, session 912, and session 914. In accordance with various social and skill information pertaining to player Red and parameters associated with the session 914, player Red's game system 906 and the game hosting service 902 determine that session 914 is the best session for player Red to join. Player Red's game system 906 interfaces with the session APIs 916 to create a local copy of the session 914 in player Red's game system 906. Player Red's game system 906 also interacts with the session APIs 916 to add player Red to the session 914. Communication, such as via a network for example, is established between player Red's game system 906 and player Blue's game system 904 as depicted by link 918.

0102Referring to <figref idref="DRAWINGS">FIG. 11</figref>, player Red's game system 906 sends, via the link 918, a request to player Blue's game system 904 requesting to join the session 914 as depicted by arrow 920. A PUID associated with player Red also is sent with the request to join message. Player Blue's game system 904 receives the request message, and utilizing player Red's PUID, player Blue's game system 904 interacts with the session APIs 916 to request that player Red be joined in the session 914. Player Blue's game system 904 receives a response from the session APIs 916 accepting the request to join player Red in the session 914. Player Blue's game system 904 sends, via the link 918, a response telling player Red he has been joined in the session 914, as indicated by arrow 922. Player Blue's game system 904 sends, along with the affirmative response to player Red's game system 906, a complete list of players in the game, and any additional data necessary to set up the game code prior to playing. At this point in the exemplary scenario, player Blue is waiting for enough players to start the game, and player Green is still inactive. Next, player Red's game system 906 interacts with the session APIs 916, utilizing player Blue's PUID to join the session 914. This results in both player Red's game system 906 and player Blue's game system 904 having synchronized versions of the game to be played in session 914. Player Red now waits for player Blue to signal the beginning of the game and player Green is still inactive.

0103Referring to <figref idref="DRAWINGS">FIG. 12</figref>, at this point in the exemplary scenario, player Blue decides to invite his friend player Green into the game by sending him an invitation over a network communications channel. Player Green notices the invite and accepts it. Player Green's game system 908 receives a notification and retrieves a session information cookie from its internal storage, such as a mass memory unit or a hard disk drive memory, for example. Player Green's game system 908 interacts with session APIs 916 to build a local copy of the session 914 and to add player Green to the session 914. Player Green's game system 908 then sends a request to player Blue's game system 904 to join player Green to the session 914. Player Red is waiting for the game to start.

0104Player Blue's game system 904 receives the message from player Green's game system 908 asking to join the session 914. Player Blue's game system 904 again interacts with session APIs 916 to join the remote player (i.e., player Green). Upon the session APIs 916 telling player Blue's game system 904 that player Green can be joined, player Blue's game system 904 returns the affirmative response and a list of all players in the session to player Green's game system 908 (along with any data needed to set up game code prior to gameplay). Additionally, player Blue's game system 904 sends a message to player Red's game system 906 alerting player Red's game system 906 to add the new player (i.e., player Green) to the session (along with any other needed game data). Player Red's game system 906 and player Green's game system 908 receives players Blue's messages. Player Red's game system interacts with session APIs 916, utilizing player Green's PUID, to synchronize with player Blue's game system 904. Player Green's game system 908 interacts with session APIs 916 to synchronize with player Blue's game system 904.

0105This process continues until enough players are joined in the session 914. When enough players have joined the session 914, player Blue's game system 904 then initiates gameplay. All joined game systems interact with session APIs 916 to start the session 914. During gameplay, depending on session flags and state, additional players can join the session, and current players can leave the session. The interaction with the session APIs to leave a session is handled similarly to joining a session. The host game system is responsible for notifying all other game systems to remove players from the session (and from the game code).

0106Once an end condition is reached for the game, the host game system notifies the other game systems to interact (by sending the appropriate calls) with the session APIs to end the session. Game systems needing to write statistics write them prior to ending the session. Once a call to end a session has been received for all game systems, the respective players are considered in the post-game state. Post game players can either end a session (the session is deleted), or game play can be rolled over and continue by starting the session again.

0107As illustrated by the above exemplary scenario, session APIs manage pre-game functions, in-game functions, post-game functions, arbitration functions, and parties (groups of players). Although all APIs are not called in all scenarios, session APIs include, but are not limited to, an API for creating a session (XSessionCreate), an API for joining a session (XSessionJoinLocal and XSessionJoinRemote), an API for leaving a session (XSessionLeaveLocal and XSessionLeaveRemote), an API for arbitration (XSessionArbitrationRegister), and API for starting a session (XSessionStart), an API for flushing statistics (XSessionFlushStats), an API for ending a session (XSessionEnd), and an API for deleting a session (XSessionDelete).

0108Sessions track gameplay states through specific session API calls. API calls are made on all copies of the session (copied to individual game systems) in order to keep backend player information up to date. Sessions track pre-game states, in-game states, and post-game states. The pre-game state starts when a session is created and ends when a session is started. During the pre-game state, players are joining, leaving and/or changing settings. APIs called during the pre-game state include: XSessionJoinLocal, XSessionJoinRemote, XSessionLeaveLocal, XSessionLeaveRemote, XSessionModify, XSessionArbitrationRegister (for arbitrated sessions), XUserSetContext, and XUserSetProperty.

0109The in-game state starts when gameplay is started and ends when gameplay is ended. Players are playing the game during the in-game state. APIs called during the in-game state include: XSessionJoinLocal, XSessionJoinRemote (for join-in-progress enabled sessions), XSessionLeaveLocal, XSessionLeaveRemote, XSessionWriteStats, XSessionFlushStats (for longer sessions that risk losing accumulated statistics, such as a single-player with stats session), XUserSetContext, and XUserSetProperty.

0110The post-game state starts when gameplay is ended and ends when a session is deleted. During the post game state, players are in a post game lobby or the session is being cleaned up. In an exemplary embodiment, no APIs are called during the post-game state, because the session has ended and no further API calls are necessary. A session can be ‘rolled over’ by not deleting the session after the session ends. In this case, there is a seamless transition between the post-game and pre-game states. After XSessionEnd has completed, the title can join or leave players, and/or modify settings until starting the session again.

0111Sessions also manage additional functions. Arbitration of statistics is managed by sessions, including automatic session time extension. Sessions automatically extend session time as needed to finish a game. Thus, game application developers are freed from determining minimum session durations. Family settings checks are built into the session APIs. Thus game application developers are not required to make separate privilege checks. Sessions automatically provide updates to matchmaking service. As a host of a session makes session API calls, the matchmaking service is notified with relevant updates. Examples when the matchmaking service would be automatically updated include scenarios in which players are added or removed from the session (slot updates); when a match-schema-relevant context or property is changed; and when changes of game state update a match aspect (e.g., changing joinability of the session after XSessionStart for non-join-in-progress sessions). Sessions provide consistent joining of players/groups whether being joined from a game invite or from the gaming service's presence feature. Once an invite notification is received, the same path is followed to get the player/group into the game regardless of whether it is an invite join or a presence join. Sessions are enabled for all gameplay scenarios, such as online multi-player, online-enabled single-player, offline single player, and system-link, for example. Thus, game application code development is simplified.

0112Players can be grouped together in or across game sessions. Game applications developers have the flexibility to implement party or group scenarios as desired. Session APIs support party creation and facilitate “play again” scenarios by creating 2 flavors of session ID for each gathering of players for game play. Referring to Table A below and <figref idref="DRAWINGS">FIG. 13</figref>, the first session ID is created at step 1302. The first session ID is indicative of the group of players (gamers). The first session ID (A, in the Table A below) is a kind of “meta-session” (the Party) associated with the host of the game (and in a hostless game or in a case of host-migration, the ID A is associated with the person who is the under-the-covers host—identified as host in the game code but not explicitly identified as a host to the players). As gamers join the party in the pre-game lobby (or as they accept invites and gather with the host) in the out-of-game console system, they join this party ID (A) at step 1304.

0113When the party is passed to the game, the session starts (XSessionCreate), and a new, second session ID (B) is created and assigned to the group at step 1306 by the game and is used until the session tracked just within the game is deleted (XSessionDelete). The party ID (A) persists with the host and all of the gamers who have joined the party.

0114When game play starts, a third session ID for tracking statistics is created at step 1308. The game play session is tracked with the third ID, C, created when XSessionStart is called. The third session ID is used to track all statistics associated with each player who actually plays in the round.

0115If no new players try to join the game (step 1310), the game continues at step 1312. If more players try to join the game (step 1310) and no slots are available (step 1314), the request to join the game is denied at step 1316. If slots are available (step 1314), it is determined if players can join the game in progress at step 1318. If join in progress is allowed (step 1318), the player(s) is added to the first, second, and third session IDs, and joined in the game at step 1320. In a game that has open slots (step 1314) but where join in progress is not allowed (step 1318), as depicted at step 1322, once game play begins, new gamers can continue to join this party ID A (and B, if the game allows) and can wait in the out-of-game match lobby UI in the console even while the session ID C remains closed (because the game is in progress). These new gamers who joined A can further wait in a game lobby (associated with B) for the other gamers to finish.

0116All data about the actual game play is associated with the ID C. In a join-in-progress game, a new gamer would need to join both the second ID (B) and the third ID (C) at the same time, then, to participate in the game play. If the host permits, the person could also be joined to the party ID (A).

0117When the round of game play ends (XSessionEnd), the gamers can choose to play again (in unranked game only). If they do, the party ID remains (and allows them to play again, keeping them together) as well as the overall game session ID (B), but the game play session ID (C) is abandoned as soon as XSessionEnd is called. When a new round of play starts (XSessionStart) a new game play session ID (D) is generated for tracking statistics.

0118The game retains the party ID and the information that this was an out-of-game match created game. At the end of each session of game play (Ranked games only allow one round of gameplay so this is not relevant, but the game can offer a “Convert to Standard” game that allows one gamer to designate himself as host and automatically send invites to the other gamers to join him in an out-of-game match lobby), the game offers the host to return the party to the out-of-game lobby or to play again. If he selects to return to the out-of-game lobby, the game sends the console a GameCompleted message and ends the game play session with the XSessionDelete API.

0119The party ID A is deleted when the host disbands the group of players from the out-of-game match lobby or, in cases with host migration, when no new host takes over the game. The flow looks like this: <tables id="TABLE-US-00002" num="2"><table frame="none" colsep="0" rowsep="0" pgwide="1"><tgroup align="left" colsep="0" rowsep="0" cols="4"><colspec colname="1" colwidth="84PT" align="left" /><colspec colname="2" colwidth="84PT" align="left" /><colspec colname="3" colwidth="84PT" align="left" /><colspec colname="4" colwidth="56PT" align="left" /><thead><row><entry namest="1" nameend="4" align="center">TABLE A</entry></row><row><entry /></row><row><entry namest="1" nameend="4" align="center" rowsep="1" /></row><row><entry /><entry /><entry /><entry>Tracking ID</entry></row><row><entry>Host API call/activity</entry><entry>Player2 API call/activity</entry><entry>Player3 API call/activity</entry><entry>for group</entry></row><row><entry namest="1" nameend="4" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry>XSessionCreateParty</entry><entry /><entry /><entry>A is created in</entry></row><row><entry /><entry /><entry /><entry>console code.</entry></row><row><entry>Out of Game Lobby</entry><entry /><entry /><entry>A</entry></row><row><entry /><entry>Query</entry></row><row><entry /><entry>XSessionJoinParty</entry><entry /><entry>A</entry></row><row><entry /><entry>Out of Game Lobby</entry><entry /><entry>A</entry></row><row><entry /><entry /><entry>Query</entry></row><row><entry /><entry /><entry>XSessionJoinParty</entry><entry>A</entry></row><row><entry /><entry /><entry>Out of Game Lobby</entry><entry>A</entry></row><row><entry>StartSession message</entry><entry>Player prompted to insert</entry><entry>Player prompted to insert</entry><entry>Console passes</entry></row><row><entry>passed from console app to</entry><entry>game disk.</entry><entry>game disk.</entry><entry>StartGame</entry></row><row><entry>game.</entry><entry /><entry /><entry>message—with</entry></row><row><entry>Host selects a game from</entry><entry /><entry /><entry>all game settings</entry></row><row><entry>out-of-game match UI,</entry><entry /><entry /><entry>and list of</entry></row><row><entry>inserts game disk, and</entry><entry /><entry /><entry>players - to</entry></row><row><entry>inputs the game settings.</entry><entry /><entry /><entry>game code</entry></row><row><entry>XSessionCreatet</entry><entry>XSessionCreatet</entry><entry>XSessionCreatet</entry><entry>B is created by</entry></row><row><entry /><entry /><entry /><entry>game to track</entry></row><row><entry /><entry /><entry /><entry>the gathering of</entry></row><row><entry /><entry /><entry /><entry>players in the</entry></row><row><entry /><entry /><entry /><entry>game (A persists</entry></row><row><entry /><entry /><entry /><entry>in the</entry></row><row><entry /><entry /><entry /><entry>background)</entry></row><row><entry>In-Game Lobby</entry><entry>In-Game Lobby</entry><entry>In-Game Lobby</entry><entry>B</entry></row><row><entry>XSessionStart</entry><entry>XSessionStart</entry><entry>XSessionStart</entry><entry>C (game-play</entry></row><row><entry /><entry /><entry /><entry>session ID) is</entry></row><row><entry /><entry /><entry /><entry>created by game</entry></row><row><entry /><entry /><entry /><entry>while A and B</entry></row><row><entry /><entry /><entry /><entry>persist in the</entry></row><row><entry /><entry /><entry /><entry>background.</entry></row><row><entry>Game play</entry><entry>Game play</entry><entry>Game play</entry><entry>Stats are tracked</entry></row><row><entry /><entry /><entry /><entry>for all of the</entry></row><row><entry /><entry /><entry /><entry>players</entry></row><row><entry /><entry /><entry /><entry>associated with</entry></row><row><entry /><entry /><entry /><entry>C.</entry></row><row><entry>XSessionEnd</entry><entry>XSessionEnd</entry><entry>XSessionEnd</entry><entry>C is closed (A, B</entry></row><row><entry /><entry /><entry /><entry>persist in the</entry></row><row><entry /><entry /><entry /><entry>background)</entry></row><row><entry>In-Game Lobby</entry><entry>In-Game Lobby</entry><entry>XSessionDelete</entry><entry>All players</entry></row><row><entry /><entry /><entry>Player chooses to quit game</entry><entry>associated with</entry></row><row><entry /><entry /><entry>at this point and return to</entry><entry>B remain</entry></row><row><entry /><entry /><entry>out-of-game lobby to wait</entry><entry>together to play</entry></row><row><entry /><entry /><entry>for Player1 and Player2.</entry><entry>next session. A</entry></row><row><entry /><entry /><entry>GameCompleted message</entry><entry>persists in the</entry></row><row><entry /><entry /><entry>sent.</entry><entry>background so</entry></row><row><entry /><entry /><entry /><entry>that player who</entry></row><row><entry /><entry /><entry /><entry>quits game and</entry></row><row><entry /><entry /><entry /><entry>calls</entry></row><row><entry /><entry /><entry /><entry>GameCompleted</entry></row><row><entry /><entry /><entry /><entry>can wait in out-</entry></row><row><entry /><entry /><entry /><entry>of-game lobby.</entry></row><row><entry>XSessionStart</entry><entry>XSessionStart</entry><entry>Out-of-game lobby.</entry><entry>D is created (A,</entry></row><row><entry /><entry /><entry /><entry>B persist in the</entry></row><row><entry /><entry /><entry /><entry>background)</entry></row><row><entry>Game play</entry><entry>Game play</entry><entry>Out-of-game lobby.</entry><entry>D (A, B persist</entry></row><row><entry /><entry /><entry /><entry>in the</entry></row><row><entry /><entry /><entry /><entry>background)</entry></row><row><entry>XSessionEnd</entry><entry>XSessionEnd</entry><entry>Out-of-game lobby.</entry><entry>D is closed (A,</entry></row><row><entry /><entry /><entry /><entry>B persists in the</entry></row><row><entry /><entry /><entry /><entry>background)</entry></row><row><entry>In-Game Lobby</entry><entry>In-Game Lobby</entry><entry>Out-of-game lobby.</entry><entry>Player1 and</entry></row><row><entry /><entry /><entry /><entry>Player2 remain</entry></row><row><entry /><entry /><entry /><entry>associated by A,</entry></row><row><entry /><entry /><entry /><entry>B. Player3 is</entry></row><row><entry /><entry /><entry /><entry>still waiting in</entry></row><row><entry /><entry /><entry /><entry>out-of-game</entry></row><row><entry /><entry /><entry /><entry>lobby,</entry></row><row><entry /><entry /><entry /><entry>associated with</entry></row><row><entry /><entry /><entry /><entry>A only.</entry></row><row><entry>XSessionDelete</entry><entry>XSessionDelete</entry><entry>Out-of-game lobby.</entry><entry>B is closed in</entry></row><row><entry /><entry /><entry /><entry>game.</entry></row><row><entry>GameCompleted message</entry><entry>GameCompleted message</entry><entry>Out-of-game lobby.</entry><entry>Game passes</entry></row><row><entry /><entry /><entry /><entry>GameCompleted</entry></row><row><entry /><entry /><entry /><entry>message back to</entry></row><row><entry /><entry /><entry /><entry>console.</entry></row><row><entry>Out-of-game lobby.</entry><entry>Out-of-game lobby.</entry><entry>Out-of-game lobby.</entry><entry>All players</entry></row><row><entry /><entry /><entry /><entry>gather together</entry></row><row><entry /><entry /><entry /><entry>again in out-of-</entry></row><row><entry /><entry /><entry /><entry>game lobby.</entry></row><row><entry>Host decides to dissolve</entry></row><row><entry>party.</entry></row><row><entry>XSessionDeleteParty</entry><entry>XSessionDeleteParty</entry><entry>XSessionDeleteParty</entry><entry>A is closed and</entry></row><row><entry /><entry /><entry /><entry>all players go</entry></row><row><entry /><entry /><entry /><entry>their separate</entry></row><row><entry /><entry /><entry /><entry>ways.</entry></row><row><entry namest="1" nameend="4" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0120Once the configuration process is complete and the game has instrumented its code so that it can accept the StartGame message from the service, manage the grouping of players with the session and party API, and pass back the GameCompleted message to the service when the group wishes to leave the game, the service can render the out-of-game matchmaking User Interface (UI) in the console system application. The UI includes three main parts: find a session, create a session (to allow others to search and join), and browse/find people to assemble a party. That UI is better understood with reference to <figref idref="DRAWINGS">FIG. 14</figref>. Initially at step 1102, the player has completed the matchmaking process with other players that match the criteria of friends and/or Affiliates. The system then indicates the number of players that meet the matchmaking criteria selected by a player. The UI presents a player with three selections: selection A essentially provides the game player with the ability to find a game that has been started by another player and to join that session. In that case, the UI presents to the player a list of games and allows the player to select a game screen at step 1104. The screen displays a number of games (e.g., Halo, PGR, etc.) along with the number of gamers and the number of Affiliates/friends in each game. This additional information about where the player's Affiliates (friends, Recent Players, and positive feedback people) are currently playing helps in making the game selection. After selecting a particular game, a Select a Session Screen 1106 lists the total number of sessions at the top of the screen (each filter reduces the number of sessions) and allows the gamer to proceed with one of three options:

0121The first option is Select a Session (each session listed by Session Descriptor that includes key attributes about the people and settings of the session). The session selection puts the player into the out of game lobby 1114. There, the player will wait until a start game message is sent to the player's console 100 to start the game session. If the player chooses this option, he will usually be dropped into a hostless game (i.e. a game where no one player controls the settings). The game settings may be chosen at random. “Hostless” games cannot return together to the out-of-game Lobby. When the game ends, the players can choose to continue in the same game with the same settings, the game can choose to randomly rotate the game settings, or the players can leave.

0122The second option is to Filter on People Settings (including reputation, skill, type of gamer, e.g., casual, hardcore, etc.). <figref idref="DRAWINGS">FIG. 14</figref> depicts this activity in box 1108. This step leverages the User Profile but allows the player to choose which aspects of his profile to emphasize in filtering the long list of sessions available.

0123Filter on Game Settings offers a subset of Session Definition options described in the configuration process, above. For example, a player may desire to filer on a particular game level so that only sessions at that level will appear in the screen selections. The Filter on Game Settings is depicted by box 1110. Among game settings is the ability to choose “Hostless” v. “Hosted (Party)” games.

0124<figref idref="DRAWINGS">FIG. 15</figref> depicts a UI for a particular game where both the Game Settings and People Settings may be filtered in one simple screen.

0125When choosing among sessions, the player can view a session descriptor for each session. The system app UI shows a per-game-mode session descriptor that contains a summary of key User Profile averages for the session, a summary of the major game settings, and a “Session Label” that identifies the type of game play in the session (defined by the “Zone” of the players in the game). This data helps a player get an “at-a-glance” view of each session so that he can pick the best one to join. The data in the session descriptor includes: <ul id="ul0005" list-style="none"><li id="ul0005-0001" num="0000"><ul id="ul0006" list-style="none"><li id="ul0006-0001" num="0126"> Game name </li><li id="ul0006-0002" num="0127"> Host's name </li><li id="ul0006-0003" num="0128"> Community reputation rating of the players in the game </li><li id="ul0006-0004" num="0129"> Atmosphere or rules of the game (e.g., use of mature language, level of competitiveness) </li><li id="ul0006-0005" num="0130"> Game settings (e.g., type of game, level or track being played) </li><li id="ul0006-0006" num="0131"> Connection speed (i.e., ping) </li><li id="ul0006-0007" num="0132"> Skill level of the players in the game </li><li id="ul0006-0008" num="0133"> Whether there are friends of yours in the game </li><li id="ul0006-0009" num="0134"> Whether there are friends of your friends in the game </li><li id="ul0006-0010" num="0135"> Whether there are people you have enjoyed playing with previously in the game </li><li id="ul0006-0011" num="0136"> Language spoken in the game </li><li id="ul0006-0012" num="0137"> The country game is being hosted in </li></ul></li></ul>

0138<figref idref="DRAWINGS">FIG. 16</figref> depicts a UI where a player is selecting a particular session (the yellow boxed selection) among a list of sessions and is viewing some of the session descriptor details.

0139If the player would rather create a game session than join an existing session, the player can select “Create a Match” and move to step 1112. In that case, the player proceeds to a screen that allows the player pick a game title for which he would like to create a session. At that point, the player can define the game based on the game configuration options. For example, the player can select the level of play, the number of players, and so on. After the player defines the game session (defined by the game in the configuration process), the player enters a game lobby until participants join. That game session will then show up on other gamers screens that were searching for a game to join (i.e., as illustrated in steps 1104 and 1106). Games set up in this way are “hosted” games (hosted by the player who created the session) that result in a game “Party,” and when they are completed, all of the players have the option of either continuing in the same game, letting the host change the game settings for that game, or returning to the out-of-game lobby.

0140Private Parties are managed in by identifying the assembly of players in the party separately from the gathering of players for a particular session of game play.

0141In addition to waiting for gamers to join the game session, the player can actively seek participants and build a Party by choosing “Create a Party.” As shown in step 1124, the player can browse the Gamercards on friends list, Recent Players list and or otherwise find gamers with User Profiles that meet certain search criteria, e.g., having a certain skill level, locale, and/or reputation, or who are otherwise friends or Affiliates. After finding the various matching gamers, the player can invite them to join a Party session directly by sending that gamer an invite to the Party session. If the player accepts the invite he is joined in the OOG (Out-Of-Game) match Party lobby. Alternatively, a voice channel can be opened whereby the gamers can communicate, e.g., about the game session. Finally, while browsing for gamers, selected gamers can be added to the player's Affiliates list so that they will be noted as Affiliates in future game selections.

0142The Party Lobby (1112), when accessed from the “Create a Party Flow” allows the designated host to choose among all games available on his played games list and all the played games list of players currently in the Party Lobby. It will call out those games on the host's list that are not available to one or more players in the lobby. If the host chooses to play one of the games unavailable to one or more players, those players can wait in the lobby for the party to return or can leave. The host will not be able to start a game that drops all the players.

0143When the players have completed game play in a party game, the game must give the players the option to return to the OOG match party lobby. The game must send back to the system a “Game Completed” message. The out-of-game party lobby allows the group of players to remain together and communicate with each other with the host player designated to choose which game to play next and, once the game is chosen, which settings for the game to choose (map etc.)

0144Because of the limitations of the game (as specified in the Session Description), some game types may not be available to the party (e.g. if there are 6 people in the party, some game types may not be selectable because only 4 players are allowed).

0145Although sessions manage much of the game experience, in an exemplary embodiment, the host game system is responsible for managing communications between game systems to keep sessions in sync, manage gameplay states, and play the game. Each game system maintains a local copy of a session, and sessions do no behind-the-scenes communication with each other. Thus, titles are responsible for ensuring that the local copies of the session remain in sync with the host game system's copy of the session. When new players ask to join a session, if successful, the host communicates the addition of the new player(s) to all connected game systems. The host game system also is responsible for communicating the departure of a player while a session is active.

0146For arbitrated sessions, the host game system also is responsible for managing re session registration. The host of the session, when ready to start, indicates to all connected game systems that they should call XSessionArbitrationRegister. After all other game systems have registered, the host game system registers. Alternately, the host game system can register early (before the other game systems are finished registering), and then register again after all game systems have completed. A list of all currently registered players is returned from a successful registration call. After receiving this list, it is the host game system's responsibility to process the list and notify all clients of any players who did not successfully register. These players are removed from the session and can not participate in the gameplay.

0147Sessions APIs create and delete sessions. Sessions are created with the XSessionCreate API. Various options and flags are specified to create a session. One option to specify is the game type such as “Capture the Flag,” King of the Hill,”or “Deathmatch.” That is, the Game_Type is set prior to creating a session. In an exemplary embodiment, if game type is not set, a default game type of ranked session is set. Once XSessionCreate has completed, game type is locked for that session and the game type context can be altered as necessary to create other sessions. In addition to game type, session flags appropriate to the needs of the session are specified at creation time. These flags initiate the setting up of feature integration for the session. Some of the flags can be toggled after a session is created. Exemplary flags and respective effects are listed in the table below. <tables id="TABLE-US-00003" num="3"><table frame="none" colsep="0" rowsep="0" pgwide="1"><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="196PT" align="left" /><colspec colname="2" colwidth="140PT" align="left" /><thead><row><entry /></row><row><entry namest="1" nameend="2" align="center" rowsep="1" /></row><row><entry>Flag Name</entry><entry>Effect</entry></row><row><entry namest="1" nameend="2" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry>XSESSION_CREATE_HOST</entry><entry>Sets the local session copy as the host of the</entry></row><row><entry /><entry>session. In an exemplary embodiment, there</entry></row><row><entry /><entry>is one host per session.</entry></row><row><entry>XSESSION_CREATE_USES_PRESENCE</entry><entry>Advertises the session in the presence</entry></row><row><entry /><entry>service. When players join via a player's</entry></row><row><entry /><entry>Gamercard options menu, this is the session</entry></row><row><entry /><entry>they will join. In an exemplary embodiment,</entry></row><row><entry /><entry>a player can join only one presence session.</entry></row><row><entry>XSESSION_CREATE_USES_STATS</entry><entry>Sets up the session to track player statistics.</entry></row><row><entry /><entry>If this flag is not passed, no statistics are</entry></row><row><entry /><entry>collected for the session.</entry></row><row><entry>XSESSION_CREATE_USES_MATCHMAKING</entry><entry>Advertises the session in the matchmaking</entry></row><row><entry /><entry>service, making it searchable. This flag is</entry></row><row><entry /><entry>passed in order to have a session joinable</entry></row><row><entry /><entry>through matchmaking.</entry></row><row><entry>XSESSION_CREATE_USES_ARBITRATION</entry><entry>Sets up the session to use the arbitration</entry></row><row><entry /><entry>service. This flag is passed for all ranked</entry></row><row><entry /><entry>sessions.</entry></row><row><entry>XSESSION_CREATE_USES_PEER_NETWORK</entry><entry>Sets up XNET key registration for the session.</entry></row><row><entry /><entry>Also signals enforcement of multi-player and</entry></row><row><entry /><entry>parental controls privilege settings.</entry></row><row><entry>XSESSION_CREATE_INVITES_DISABLED</entry><entry>Disables the ability of players to send invites</entry></row><row><entry /><entry>from the Guide. Does not prevent invites</entry></row><row><entry /><entry>sent with the XInviteSend API.</entry></row><row><entry>XSESSION_CREATE_JOIN_VIA_PRESENCE_DISABLED</entry><entry>Disables the ability of players to join the</entry></row><row><entry /><entry>session from a player's Gamercard.</entry></row><row><entry>XSESSION_CREATE_JOIN_IN_PROGRESS_DISABLED</entry><entry>Disables the ability of players to join the</entry></row><row><entry /><entry>session (either from matchmaking or from</entry></row><row><entry /><entry>presence) after XSessionStart has been</entry></row><row><entry /><entry>called.</entry></row><row><entry namest="1" nameend="2" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0148The XSessionDelete API is called is called to delete a session. When XSessionDelete is called, the session is cleaned up. Any players in the session are removed and XNET registration keys are unregistered. All memory used for the session is freed as well.

0149Session APIs also manage functions associated with joining and leaving sessions. Users (local or remote) can be joined to a session. XSessionJoinLocal and XSessionJoinRemote are called, respectively, to join users locally and remotely. XSessionJoinLocal and XSessionJoinRemote perform the same function in that they each add users to a session. XSessionJoinLocal and XSessionJoinRemote expect to use different user IDs, however, XSessionJoinRemote can be used for local users as well as remote users as long as the remote user ID is utilized. Thus, titles can elect to use XSessionJoinRemote for all users.

0150Similarly, XSessionLeaveLocal and XSessionLeaveRemote are called, respectively, to remove local and remote users. XSessionLeaveLocal and XSessionLeaveRemote perform the same function in that they each remove users from a session. XSessionLeaveLocal and XSessionLeaveRemote expect to use different user IDs, however, XSessionLeaveRemote can be used for local users as well as remote users as long as the remote user ID is utilized. In fact, titles can elect to use XSessionLeaveRemote for all users.

0151Statistics are reported prior to calling XSessionLeave. Statistics are not reported for players who have left the session. Ultimately, the game decides what statistics to write for the match. In an exemplary embodiment, two statistics are always reported: the session team and relative score. The session team is the team the player was with during the session (a unique value in a non-team game). Statistics cannot be recorded on the service for a player after XSessionLeave has been called for that player. Titles can either write these statistics and call XSessionLeave as the player exits, or the title can log the information and take care of statistics writes and leaves at the end of the game (prior to calling XSessionEnd).

0152When a player quits or disconnects before he/she has completed game play, the player's skill data is written prior to calling XSessionLeave for him/her. The session team is written for the team the player was on when he or she left the session. In an exemplary embodiment, when a player does not finish the game, a relative score of last place (regardless of the player's actual score) is assigned to that player. This helps to prevent a player from quitting a game when his/her score is high simply to improve his/her statistics.

0153While illustrative embodiments have has been described in connection with various Figures, it is to be understood that other similar embodiments can be used or modifications and additions can be made to the described embodiment for performing the same function of on-line gaming session and party management without deviating therefrom.

Contents6

Every citation, both ways

Citations
Document	Relation	Office	Cited during
US10398985B2	Cited by	United States of America	Applicant
US12303783B2	Cited by	United States of America	Applicant
EP2212001B1	Cited by	European Patent Office (EPO)	Examiner
US9901817B2	Cited by	United States of America	Search report
US2010178985A1	Cited by	United States of America	Pre-grant
US11369873B2	Cited by	United States of America	Applicant
US2018126282A1	Cited by	United States of America	Search report
US9437072B2	Cited by	United States of America	Applicant
US9132351B2	Cited by	United States of America	Applicant
US12208337B2	Cited by	United States of America	Applicant
US10506268B2	Cited by	United States of America	Search report
US2007218446A1	Cited by	United States of America	Pre-grant
US2020007900A1	Cited by	United States of America	Search report
US11684849B2	Cited by	United States of America	Search report
US9871837B1	Cited by	United States of America	Search report
US9731203B2	Cited by	United States of America	Search report
US2012202603A1	Cited by	United States of America	Pre-grant
US10463972B2	Cited by	United States of America	Applicant
US8732315B2	Cited by	United States of America	Applicant
US2010016006A1	Cited by	United States of America	Pre-grant
US2014304295A1	Cited by	United States of America	Pre-grant
US11344814B2	Cited by	United States of America	Applicant
US8197313B2	Cited by	United States of America	Applicant
US10967276B2	Cited by	United States of America	Applicant
US9596277B1	Cited by	United States of America	Applicant
CN103442051A	Cited by	China	Search report
US2018109820A1	Cited by	United States of America	Search report
US10186002B2	Cited by	United States of America	Applicant
US2011250971A1	Cited by	United States of America	Pre-grant
US2019287041A1	Cited by	United States of America	Search report
US11247125B2	Cited by	United States of America	Search report
US11318390B2	Cited by	United States of America	Applicant
US10130872B2	Cited by	United States of America	Applicant
US2012225724A1	Cited by	United States of America	Pre-grant
US8353771B2	Cited by	United States of America	Search report
US10917665B2	Cited by	United States of America	Search report
US2010146271A1	Cited by	United States of America	Pre-grant
US2007265067A1	Cited by	United States of America	Pre-grant
US2009075737A1	Cited by	United States of America	Pre-grant
US9993735B2	Cited by	United States of America	Applicant
US2006121990A1	Cited by	United States of America	Pre-grant
US9656176B2	Cited by	United States of America	Applicant
US2010069156A1	Cited by	United States of America	Pre-grant
US2010306672A1	Cited by	United States of America	Pre-grant
US8262472B2	Cited by	United States of America	Applicant
US10277683B2	Cited by	United States of America	Search report
WO2019074952A3	Cited by	World Intellectual Property Organization (WIPO)	International search
US9308455B1	Cited by	United States of America	Search report
US8083591B2	Cited by	United States of America	Search report
US12440764B2	Cited by	United States of America	Search report
US2012135809A1	Cited by	United States of America	Pre-grant
US12168182B2	Cited by	United States of America	Applicant
US8891492B1	Cited by	United States of America	Applicant
US2010222147A1	Cited by	United States of America	Pre-grant
US10695677B2	Cited by	United States of America	Applicant
US9578094B1	Cited by	United States of America	Applicant
US9478100B2	Cited by	United States of America	Search report
US8221238B1	Cited by	United States of America	Applicant
US2008172491A1	Cited by	United States of America	Pre-grant
US2013316832A1	Cited by	United States of America	Pre-grant
WO2010141259A1	Cited by	World Intellectual Property Organization (WIPO)	International search
US2013231179A1	Cited by	United States of America	Search report
US8979647B2	Cited by	United States of America	Search report
US2009082101A1	Cited by	United States of America	Pre-grant
US2014274258A1	Cited by	United States of America	Pre-grant
US10646785B2	Cited by	United States of America	Applicant
US2019287041A1	Cited by	United States of America	Search report
US11918896B2	Cited by	United States of America	Search report
US9536372B2	Cited by	United States of America	Applicant
US2023117046A1	Cited by	United States of America	Pre-grant
US2009111576A1	Cited by	United States of America	Pre-grant
US10286327B2	Cited by	United States of America	Applicant
US11420119B2	Cited by	United States of America	Search report
US11662051B2	Cited by	United States of America	Applicant
US2008287190A1	Cited by	United States of America	Pre-grant
WO2011011466A1	Cited by	World Intellectual Property Organization (WIPO)	International search
US10835816B2	Cited by	United States of America	Applicant
US10463960B1	Cited by	United States of America	Applicant
US10552446B2	Cited by	United States of America	Search report
US2015280986A1	Cited by	United States of America	Pre-grant
US9083728B1	Cited by	United States of America	Applicant
US8137201B2	Cited by	United States of America	Search report
US8393948B2	Cited by	United States of America	Applicant
US2013007013A1	Cited by	United States of America	Pre-grant
US11405347B1	Cited by	United States of America	Search report
US2022233955A1	Cited by	United States of America	Search report
US2023173390A1	Cited by	United States of America	Search report
TWI427527B	Cited by	Taiwan Province of China	Examiner
US2013288801A1	Cited by	United States of America	Pre-grant
US2009325712A1	Cited by	United States of America	Pre-grant
US10130889B2	Cited by	United States of America	Applicant
US9039507B2	Cited by	United States of America	Applicant
US11712630B2	Cited by	United States of America	Applicant
US8195809B2	Cited by	United States of America	Search report
GB2485506A	Cited by	United Kingdom	Search report
US2022319278A1	Cited by	United States of America	Search report
US8229796B2	Cited by	United States of America	Applicant
CN110276510A	Cited by	China	Search report
US11140207B2	Cited by	United States of America	Applicant
US2011106885A1	Cited by	United States of America	Pre-grant

Showing 100 of 192

19 members in 8 offices

This recordMember, by publication datePriority claim

Priority claims6

Priority claims
Document	Office	Kind	Date
15687705	United States of America	A	2005-06-20
15687705	United States of America	A	2005-06-20
31295905	United States of America	A	2005-12-20
11156877	–	–	–
US20050156877	–	–	–
US20050312959	–	–	–

Members19

Family members, oldest first
Document	Office	Kind
US2006287096A1	United States of America	A1	2006-12-21
US2006287099A1	United States of America	A1	2006-12-21
WO2007001628A2	World Intellectual Property Organization (WIPO)	A2	2007-01-04
WO2007001628A3	World Intellectual Property Organization (WIPO)	A3	2007-10-04
KR20080017327A	Republic of Korea	A	2008-02-26
EP1894123A2	European Patent Office (EPO)	A2	2008-03-05
CN101180621A	China	A	2008-05-14
JP2008546469A	Japan	A	2008-12-25
RU2007147424A	Russian Federation	A	2009-06-27
BRPI0611981A2	Brazil	A2	2010-10-13
RU2419844C2	Russian Federation	C2	2011-05-27
EP1894123A4	European Patent Office (EPO)	A4	2012-03-07
CN101180621B	China	B	2012-06-20
US8241129B2	United States of America	B2	2012-08-14
US2012283023A1	United States of America	A1	2012-11-08
KR101292432B1	Republic of Korea	B1	2013-07-31
US8535165B2	United States of America	B2	2013-09-17
US8585501B2	United States of America	B2	2013-11-19
JP5376945B2	Japan	B2	2013-12-25

85 transactions on the USPTO file

Allowed after 4 non-final rejections, 2 final rejections and 2 RCEs.

Non-final rejections: 4
Final rejections: 2
RCEs: 2
Appeals: 0

Over time

Point at a mark for the transaction

Transactions

Prosecution transactions, newest first
	Event	Code
2025-12-22	Expire PatentEXP.	EXP.
2025-07-07	Maintenance Fee Reminder MailedREM.	REM.
2021-05-05	Payment of Maintenance Fee, 8th Year, Large EntityM1552	M1552
2019-09-19	Correspondence Address ChangeC.ADB	C.ADB
2013-11-19	Recordation of Patent Grant MailedPGM/	PGM/
2013-11-19	Patent Issue Date Used in PTA CalculationAllowedPTAC	PTAC
2013-10-31	Email NotificationEML_NTR	EML_NTR
2013-10-30	Issue Notification MailedAllowedWPIR	WPIR
2013-10-23	Dispatch to FDCD1935	D1935
2013-10-22	Application Is Considered Ready for IssuePILS	PILS
2013-10-16	Response to Reasons for AllowanceREAS	REAS
2013-10-16	Issue Fee Payment VerifiedN084	N084
2013-10-16	Issue Fee Payment ReceivedIFEE	IFEE
2013-08-04	Electronic ReviewELC_RVW	ELC_RVW
2013-08-02	Email NotificationEML_NTF	EML_NTF
2013-08-02	Email NotificationEML_NTR	EML_NTR
2013-08-02	Mail Examiner Initiated Interview SummaryMEXIE	MEXIE
2013-08-02	Mail Reasons for AllowanceMEX.R	MEX.R
2013-08-02	Mail Notice of AllowanceAllowedMN/=.	MN/=.
2013-07-05	Notice of Allowance Data Verification CompletedAllowedN/=.	N/=.
2013-07-05	Case Docketed to Examiner in GAUDOCK	DOCK
2013-07-02	Paralegal or electronic terminal disclaimer approvedP574	P574
2013-07-02	Date Forwarded to ExaminerFWDX	FWDX
2013-07-01	Reasons for AllowanceEX.R	EX.R
2013-06-28	Terminal Disclaimer FiledDIST	DIST
2013-06-28	Supplemental ResponseSA..	SA..
2013-06-26	Interview Summary - Examiner InitiatedEXIE	EXIE
2012-03-09	Date Forwarded to ExaminerFWDX	FWDX
2012-03-09	Disposal for a RCE / CPA / R129AbandonedABN9	ABN9
2012-02-23	Request for Continued Examination (RCE)RCEX	RCEX
2012-02-23	Workflow - Request for RCE - BeginBRCE	BRCE
2011-11-29	Electronic ReviewELC_RVW	ELC_RVW
2011-11-23	Email NotificationEML_NTF	EML_NTF
2011-11-23	Mail Final Rejection (PTOL - 326)Final rejectionMCTFR	MCTFR
2011-11-18	Final RejectionFinal rejectionCTFR	CTFR
2011-09-23	Date Forwarded to ExaminerFWDX	FWDX
2011-09-20	Information Disclosure Statement consideredIDSC	IDSC
2011-09-20	Electronic Information Disclosure StatementEIDS.	EIDS.
2011-09-20	Response after Non-Final ActionA...	A...
2011-09-20	Information Disclosure Statement (IDS) FiledWIDS	WIDS
2011-06-23	Electronic ReviewELC_RVW	ELC_RVW
2011-06-20	Email NotificationEML_NTF	EML_NTF
2011-06-20	Mail Non-Final RejectionNon-final rejectionMCTNF	MCTNF
2011-06-01	Non-Final RejectionNon-final rejectionCTNF	CTNF
2010-05-26	Email NotificationEML_NTR	EML_NTR
2010-05-26	Change in Power of Attorney (May Include Associate POA)PA..	PA..
2010-05-24	Correspondence Address ChangeC.AD	C.AD
2010-04-27	Date Forwarded to ExaminerFWDX	FWDX
2010-04-27	Disposal for a RCE / CPA / R129AbandonedABN9	ABN9
2010-04-22	Request for Continued Examination (RCE)RCEX	RCEX
2010-04-22	Workflow - Request for RCE - BeginBRCE	BRCE
2010-02-02	Mail Final Rejection (PTOL - 326)Final rejectionMCTFR	MCTFR
2010-02-01	Final RejectionFinal rejectionCTFR	CTFR
2009-11-28	Date Forwarded to ExaminerFWDX	FWDX
2009-11-23	Response after Non-Final ActionA...	A...
2009-11-23	Request for Extension of Time - GrantedXT/G	XT/G
2009-05-27	Mail Non-Final RejectionNon-final rejectionMCTNF	MCTNF
2009-05-26	Non-Final RejectionNon-final rejectionCTNF	CTNF
2009-03-09	Date Forwarded to ExaminerFWDX	FWDX
2009-02-02	Response after Non-Final ActionA...	A...
2009-02-02	Request for Extension of Time - GrantedXT/G	XT/G
2009-01-27	Case Docketed to Examiner in GAUDOCK	DOCK
2008-09-30	Mail Non-Final RejectionNon-final rejectionMCTNF	MCTNF
2008-09-29	Non-Final RejectionNon-final rejectionCTNF	CTNF
2008-09-15	Mail Miscellaneous Communication to ApplicantMM327	MM327
2008-09-15	Miscellaneous Communication to Applicant - No Action CountM327	M327
2008-06-11	Improper Request for Continued ExaminationIRCE	IRCE
2008-06-11	Workflow - Request for RCE - BeginBRCE	BRCE
2008-05-10	Date Forwarded to ExaminerFWDX	FWDX
2008-03-05	Response after Non-Final ActionA...	A...
2007-12-11	Mail Non-Final RejectionNon-final rejectionMCTNF	MCTNF
2007-12-10	Non-Final RejectionNon-final rejectionCTNF	CTNF
2007-09-27	Case Docketed to Examiner in GAUDOCK	DOCK
2007-03-07	Case Docketed to Examiner in GAUDOCK	DOCK
2006-10-05	Case Docketed to Examiner in GAUDOCK	DOCK
2006-07-24	IFW TSS Processing by Tech Center CompleteTSSCOMP	TSSCOMP
2006-07-24	Case Docketed to Examiner in GAUDOCK	DOCK
2006-01-30	Application Dispatched from OIPEOIPE	OIPE
2006-01-30	Application Is Now CompleteCOMP	COMP
2006-01-13	Cleared by OIPE CSRL194	L194
2006-01-03	IFW Scan & PACR Auto Security ReviewSCAN	SCAN
2005-12-20	Information Disclosure Statement consideredIDSC	IDSC
2005-12-20	Information Disclosure Statement (IDS) FiledM844	M844
2005-12-20	Information Disclosure Statement (IDS) FiledWIDS	WIDS
2005-12-20	Initial Exam Team nnIEXX	IEXX

9 legal events, as the office reported them to INPADOC

Over the term

Point at a mark for the event

Events

Legal events, newest first
	Event	Code
2026-01-13	Lapsed due to failure to pay maintenance feeLapsedFP	FP
2025-12-22	Lapse for failure to pay maintenance feesLapsedPATENT EXPIRED FOR FAILURE TO PAY MAINTENANCE FEES (ORIGINAL EVENT CODE: EXP.); ENTITY STATUS OF PATENT OWNER: LARGE ENTITYLAPS	LAPS
2025-12-22	Information on status: patent discontinuationPATENT EXPIRED DUE TO NONPAYMENT OF MAINTENANCE FEES UNDER 37 CFR 1.362STCH	STCH
2025-07-07	Fee payment procedureMAINTENANCE FEE REMINDER MAILED (ORIGINAL EVENT CODE: REM.); ENTITY STATUS OF PATENT OWNER: LARGE ENTITYFEPP	FEPP
2021-05-05	Maintenance fee paymentMAFP	MAFP
2017-05-04	Fee paymentFPAY	FPAY
2014-12-09	AssignmentAS	AS
2013-10-30	Information on status: patent grantGrantedPATENTED CASESTCF	STCF
2006-02-21	AssignmentAS	AS

On-line gaming session and party management

Claim Score by NHIP

Abstract