Discovery and distribution of game session information

【0001】

[Technical field to which the invention belongs]

The present invention relates to a game console, and more particularly to the discovery and distribution of game session information.

【0002】

[Conventional technology]

Conventionally, a game system equipped with a dedicated console has been a stand-alone machine that supports a limited number of players (for example, 2 to 4 players). Personal computer-based games have become popular, in part because they can be played online with many remote players over the Internet. Therefore, one trend of dedicated game consoles is to provide the ability to facilitate games over networks, such as Internet-based online games.

【0003】

Network-based games or online games can be played in a centralized server or peer-to-peer manner. In a centralized-server scheme, game systems connect to one or more centralized servers and interact with each other through one or more centralized servers. In the peer-to-peer system, the game systems are interconnected and interact directly with each other. However, even in the peer-to-peer system, one or more centralized servers can be used to assist the communication.

【0004】

[Non-Patent Document 1]

Bruce Schneier, "Applied Cryptography: Protocols, Algorithms, and Source Code in C," John Wiley & Sons, copyright 1994 (second edition 1996) [0005]

[Problems to be Solved by the Invention]

One challenge associated with the use of one or more centralized servers is to protect network traffic between gaming systems from tampering or monitoring by other devices on the network. Gamers are notorious for developing creative and fraudulent means to target network traffic as a good target for such users. Unfortunately, traditional console-based game systems usually did not provide secure communication with each other.

【0006】

The discovery and distribution of game session information described below solves these and other challenges.

【0007】

[Means for solving problems]

This specification describes the discovery and distribution of game session information.

【0008】

According to one embodiment, a request to create a new game session is received from the computer device. Keep a record of the game session identifier for the new game session and the game session key for the new game session. The new game session can be used to join other computer devices.

【0009】

According to another embodiment, a request for information indicating one or more game sessions is received from the computer device. One or more gaming sessions are hosted by one or more other computer devices and are currently available for play. This request is replied with information indicating one or more game sessions and a session key that can be used to communicate with at least one of the one or more other computer devices associated with the game session. To.

【0010】

According to yet another embodiment, the identifier of the location where the game data is stored is received from the computer device. A record of the location and game session key is maintained and the location and game session key of the game data becomes available to other computer devices.

【0011】

The same number is used herein to refer to similar components and / or features.

【0012】

BEST MODE FOR CARRYING OUT THE INVENTION

The description herein assumes that the reader is familiar with basic cryptographic principles such as encryption, decryption, authentication, hashing, and digital signatures. For a basic introduction to cryptography, see the text incorporated herein by reference (see, eg, Non-Patent Document 1).

【0013】

FIG. 1 is a block diagram showing a typical environment 100 in which the discovery and distribution of game session information can be used. Multiple computer devices 102 (1), ..., 102 (c) are coupled to the opponent determination system 104. The bond between device 102 and system 104, and the bond between device 102, may be any of the various bonds that allow communication between each and / or device 102 of system 104 and device 102. In one embodiment, the coupling includes the Internet and can optionally include one or more other networks (eg, a local area network (LAN) or a wide area network (WAN)). For example, each of the computer devices 102 may be installed on a home LAN and each home LAN may be coupled to the system 104 via the Internet. This coupling can be performed using any of a variety of network types and network technologies, including wired and / or wireless networks.

【0014】

The computer device 102 allows each user to play a game with each other. An online game typically means multiple consoles that communicate with each other to allow one or more users of the console to play the game with each other. This communication is usually done over the Internet, but it can also be over other networks (as a substitute for the Internet or in addition to the Internet).

【0015】

Opponent determination system 104 maintains information about multiple game sessions hosted by computer device 102, where players search for game sessions, create new game sessions, join game sessions, and from game sessions. Allows you to get the information used by computer devices to escape and communicate data to each other. A game session host device is the device responsible for initiating a game session, such as by having an opponent determination system 104 (or some other device) to create a new game session. A game session represents an example of a game title that includes one or more players. If all players in a game session end the session (eg, exit the game session, log out of system 104, the player turns off their device, etc.), the game session ends. A game session can include several rounds of play, or a new game session can be created for each round of play. Information about multiple game sessions for each of a plurality of different game titles can be maintained simultaneously by the system 104. The player can stop (leave) the game session and join the game session. Once a session reaches a certain point in gameplay, you can limit your chances of joining that session. Alternatively, the player is free to join or leave the game session during gameplay, so the player at the end of the game session may be different from the player at the start of the game session. Limitations on the possibility of joining or quitting a game session may vary from game title to game title based on the wishes of the game title designer.

【0016】

If a player using a computer device joins a game session, that computer device is also considered to have joined the game session. The device used by each player that is playing a game session is also considered a member of that game session.

【0017】

The computer device 102 has a dedicated game console, additional features (eg, digital video recording to be able to act as a digital VCR, television signals (whether broadcast signals, cable signals, satellite broadcast signals, etc.)). It may be a game console, a desktop PC, a workstation, a portable computer, a mobile phone, an Internet device, a server computer, etc., which incorporates a channel tuning function (such as a channel tuning function for being able to synchronize and decrypt). In addition, different types of devices 102 can use the opponent determination system 104 at the same time. For example, a dedicated game console user can join a game session to play against a portable computer user, or a dedicated game console user from one manufacturer can join a game session to play a dedicated game console from another manufacturer. You can play against the users of.

【0018】

FIG. 2 is a block diagram showing a typical opponent determination system 104 in more detail. The opponent determination system 104 includes an opponent determination interface 120 and an opponent determination database 122. The opponent determination interface 120 receives requests for creating a game session, joining it, exiting it, searching for it, and so on. Upon receiving such a request, the opponent determination interface 120 generates an appropriate command to be issued to the opponent determination database 122 to fulfill the request. Alternatively, the opponent determination interface 120 may simply forward the request to the opponent determination database 122.

【0019】

The opponent determination database 122 maintains a plurality of records 124 that store information about various game sessions currently managed by the opponent determination system 104. The game session managed by the opponent determination system 104 is usually a game session created by the opponent determination system 104. It may be open depending on the game session managed by the opponent determination system 104, so additional players may join the session, but it may be closed depending on the game session, and therefore added. Players cannot join the session. Record 124 can be maintained using any of the various data structures. In one typical embodiment, information about each game session is stored as one entry in one or more tables.

【0020】

The opponent determination system 104 is designed to facilitate the establishment of game sessions between computer devices or between computer devices. For most of the description herein, the opponent determination system 104 is described as managing the game session but not data transfer between or between member devices of the game session. There is. Conversely, computer devices transfer data to or between computer devices, or through another server device (not shown in FIG. 2). Alternatively, some data transfers can be made via the opponent determination system 104.

【0021】

A variety of different information can be maintained in record 124 for each game session. In one embodiment, this information includes at least one game session ID (XNKID) and a game session key (XNKEY). The game session ID uniquely indicates a specific game session managed by the opponent determination system 104. The game session key is an encryption key associated with the game session. This encryption key is made available to all members of the game session and is used by the members of the game session to securely communicate data with each other . It should be noted that although additional keys can be used by each computer device to securely communicate with the opponent determination system 104, this one or more additional keys are different from the game session keys shown in Figure 2. I want to.

【0022】

The game session ID and game session key can be generated by the opponent determination system 104 or the host computer device 102. Alternatively, one of the game session ID and the game session key may be generated by the opponent determination system 104 and the other by the host computer device 102.

【0023】

Although Figure 2 shows only a single database 122, it should be understood that the records maintained by database 122 can be distributed across multiple server devices (referred to as partitioning). Partitioning can be performed in a variety of ways, and in one embodiment, one or more fields in a given row of the table are used to generate a partition number for a particular record, such as a hash function. The algorithm of is applied to the data in one or more of its fields and executed. Different fields such as game title identifier, game session ID, game session key, and combinations thereof can be used. The partition number indicates one of the multiple server devices where the record is stored (or should be stored).

【0024】

FIG. 3 is a flow diagram showing a typical process 160 for creating a new game session. In process 160, both the game session ID and the game session key are generated by the opponent determination system 104. Process 160 can be performed with software, firmware, hardware, or a combination thereof. Process 160 will be described with further reference to the components in Figures 1 and 2.

【0025】

First, the host computer device sends its own identifier and a description of the game in which a new session should be created to the opponent determination system 104 (action 162). The host identifier includes, for example, the network address structure of the host computer device that can communicate with other computer devices joining the game session to allow other computer devices joining the game session to communicate with the host device. .. In one embodiment, the host identifier is a fully qualified address (XNADDR), described in more detail below.

【0026】

The description of the game includes the title of the game and one or more attributes of the game. An attribute is data associated with a game session or a player in a game session. The attributes of the game may vary from game to game depending on the wishes of the game title designer. For example, the attributes are the skill level of the player starting to create a new session, the desired skill level of other players who can join the new session, the location of the game in which the play takes place (eg daytime, nighttime, a particular stadium). In a particular city, on a particular track, weather conditions, etc.), the objects that should be used during play (eg, car type, plane or spaceship type, etc.), the nature of the various characters that appear in the game. (For example, special abilities that can be used, magical power that can be used, etc.) can be shown. Further, rather than including a game title, the game title may be request specific (eg, different request types can be used for each game title).

【0027】

The host computer device 102 can indicate its own desire to create a new game session in a variety of different ways. In one embodiment, action 162 sends a predetermined session ID value (eg, a zero session ID value) to indicate to the opponent determination system 104 that a new game session will be created. Alternatively, a special command can be defined for use by the host computer device 102 to require the creation of a new game session. In yet another alternative form, the request may be specific to some other command or may be the result of another action. For example, if a computer device requests to join a game session with a set of attributes that the current game session does not fit, the opponent determination system 104 will automatically create a new game session with that set of attributes. can do.

【0028】

The opponent determination system 104 then generates a new game session ID and game session key (action 164). New game session IDs can be generated in a variety of different ways. In one embodiment, the opponent determination interface 120 generates a random number or pseudo-random number for use as a game session ID (eg, a Win32® application programming interface that uses a cryptographically strong random number generator. do it). If the random number is the same as another game session ID currently used by the opponent determination system 104, the opponent determination interface 120 generates a new random number for use as the game session ID (such as this). Generation of new random numbers will continue until an opponent determination system 104 generates a random number that is not identical to another game session ID currently in use).

【0029】

The new game session key generated in Action 164 can also be generated in a variety of different ways. In one typical embodiment, the opponent determination system 120 generates random numbers or pseudo-random numbers for use as a game session key (eg, in a Win32® application programming interface, cryptographically strong random number generation. Using a vessel). Alternatively, any of the various traditional cryptographic processes can be used to generate the game session key.

【0030】

The opponent determination system 104 advertises that a new game session is available along with a description of the game (action 166). In one embodiment, the promotion comprises adding a record of the game session to its database and thus making the game session available for search by other computer devices. Alternatively, this promotion can include recommending a gaming session to one or more computer devices. For example, a computer device can register search criteria (eg, a game session with a particular player, a particular skill level, or other attributes) in the opponent determination system 120, and any new game that meets the search criteria. Requests interface 120 to also send session notifications to computer devices.

【0031】

The opponent determination system 104 returns the game session ID and the game session key to the host computer device (operation 168). By returning the game session ID and session key to the host computer device, the host computer device indicates the newly created game session, such as when receiving subsequent notifications about that game session from other members of the session. Can be done. Alternatively, if the computer device is only allowed to host one game session at a time, there is no need to return the game session ID back to the host computer device, which host device received for the hosting game session. Subsequent notifications such as these can simply be assumed to relate to this newly created game session.

【0032】

FIG. 4 is a flow diagram showing another typical process 200 for creating a new game session. In process 200, both the game session ID and the game session key are generated by the host computer device 102. Process 200 can be performed with software, firmware, hardware or a combination thereof. Process 200 will be described with reference to FIGS. 1 and 2.

【0033】

First, the host computer device 102 generates a new game session ID and a new game session key for the new game session (operation 202). The desire to create a new game session can be demonstrated by the host computer device 102 in various ways similar to behavior 162 described above with reference to FIG. The new game session ID and the new game session key can be generated in various ways similar to behavior 164 described above with reference to FIG. The host computer device 102 then transmits the identifier of the host computer device 102, the description of the game for the new game session, the game session ID and the game session key generated in action 202 to the opponent determination system 104 (action 204). The opponent determination system 104 receives this information from the host computer device 102 and advertises that a new game session is available along with a description of the game (action 206). This promotion can be performed in various ways similar to operation 166 described above with reference to FIG.

【0034】

FIG. 5 is a flow diagram showing a typical process 230 of distributing information that allows a computer device to participate in a game session. Process 230 can be performed with software, firmware, hardware, or a combination thereof. Process 160 will be described with further reference to the components in Figures 1 and 2.

【0035】

A computer device wishing to join a new game session sends a game session search request to the opponent determination system 104 (action 232). In one embodiment, the game session search request comprises the desired game title and one or more additional search parameters. Alternatively, the desired game title may not be included (eg, if the player indicates that he wants to play any game). In another alternative, one or more additional search parameters may not be included (for example, if the player indicates that he or she wants to play a particular game title without considering the attributes of the game at all).

【0036】

The opponent determination system 104 receives a game session search request and indicates zero or more current game sessions that meet the search request parameters and have open slots for the player to enter (operation 234). In one embodiment, the opponent determination system 104 uses a computer device to return only a game session having a plurality of open slots equal to or greater than the number of current players. If more than the threshold number of game sessions meets the search request parameters, a subset of those game sessions is returned. The opponent determination system 104 then returns the information indicating the indicated game session to the requesting computer device (operation 236). This information includes a game session key for each of the indicated game sessions, which allows the computer device to securely communicate with one or more other computer devices participating in the game session. This information also includes descriptive information provided by the host computer device when creating a game session (eg, Action 162 in Figure 3 or Action 204 in Figure 4). Therefore, the returned descriptive information can include additional game attributes that exceed the game attributes indicated by the search request parameters.

【0037】

Note that it is possible to perform multiple actions instead of action 236. For example, instead of returning the game session key for all of the indicated game sessions, only the game identifier and descriptive information can be returned to the computer device. The player of the computer device can select one of the indicated game sessions depending on which computer device sends a request for the game session key for the selected game session to the opponent determination system 104. The opponent determination system 104 then returns the requested game session key to the computer device.

【0038】

With reference to FIG. 1 again, the user of computer device 102 can invite a specific user of another computer device (eg, a friend of the user) to join the game session. Such invitations can be sent via the opponent determination system 104 or, as an alternative, via another system (eg, the presence / notification system described below with reference to FIG. 13). The invitation to join a game session includes the game session ID for that session, and the invited user can search for and indicate the appropriate game session.

【0039】

FIG. 6 is a flow diagram illustrating a typical process 260 of distributing information that allows a computer device to join a game session invited to join. Process 260 can be performed with software, firmware, hardware, or a combination thereof. Process 260 is described with further reference to the components in Figures 1 and 2.

【0040】

First, the computer device receives an invitation to join the game session hosted by the host computer device (behavior 262). The computer device sends to the opponent determination system 104 that the invitation has been accepted (action 264). Acceptance in Action 264 may be a particular type of request, or a game search request with one search parameter that is the game session ID of the game session invited to join the computer device. In response, the opponent determination system 104 sends a game session key for the game session to the computer device (operation 266).

【0041】

In one embodiment, the host computer device can create a game session that includes both public and personal slots. As part of the creation process, the host computer device indicates to the opponent determination system 104 how many public slots the game session will contain and how many personal slots the game session will contain. Each slot can accommodate one player. Opponent determination system 104 keeps records of those different slots, public slots can be entered by search (eg, every process 230 in Figure 5), and personal slots can be entered by invitation. (For example, every process 260 in Figure 6). Therefore, when a game session is created, users can identify the game for their friends (those who may be invited later) without worrying about strangers getting into every slot. You can save a slot. The opponent determination system 104, as an alternative, allows invited users to enter public slots when their personal slots are full, and is invited when their personal slots are empty for at least a threshold of time. It is possible to allow variants to those rules, such as allowing non-users to enter their personal slots.

【0042】

In addition to keeping a record of game sessions, the opponent determination system 104 (an alternative, another system that works with system 104) keeps a record of other information stored on individual computer devices 102. can do. For example, certain game titles maintain information about gameplay (eg, the number of fish or obstacles present in a particular part of the lake, the number of special characters or animals generated by computers that form part of a particular scene, etc. Various characteristics of the game's environment, such as weather patterns (for example, how the sea is rough in a particular location). Computer devices playing in this environment typically allow gameplay to be consistent across different players, even if the players are not in a one-on-one match in a close combat environment. I would like to share information.

【0043】

The opponent determination system 104 can facilitate the exchange of information regarding such game titles by maintaining a record of the identifier of the information to be shared and the indication of the position where the information is stored (). For example, whether all computer devices store the information, or only one selected device of the computer device stores the information (in which case, which computer device stores the information). These identifiers can be stored, for example, as attributes of a game session. Therefore, instead of executing a search request to obtain information indicating a game session that the user can join, one in response to a request to the computer device (which may or may not have already joined the game session). The above search request for this game data position can be executed. The game session key can also be returned to the various computer devices playing the game, if desired, to allow the device to exchange game data directly in a secure manner. After acquiring one or more positions of game data from the opponent determination system 104, the computer device then acquires data from that one or more positions (eg, the computer device at those positions). You can access more than one location. In one embodiment, the location is the fully qualified address (XNADDR) of the computer device.

【0044】

FIG. 7 is a flow chart showing a typical process 300 that facilitates the exchange of information between computer devices. Process 300 can be performed with software, firmware, hardware, or a combination thereof. Process 300 is described with reference to the components of FIGS. 1 and 2.

【0045】

First, the computer device sends a request for game data exchange information to the opponent determination system 104 (operation 302). This request can indicate a particular game session, for example by its game session ID. The opponent determination session identifies the game session corresponding to the request (action 304) and identifies the position of the desired game data (action 306). The location of the desired game data may be, for example, one or more specific computer devices in a game session. The opponent determination system can then send its location and game session key to the computer device (operation 308), which can be used by the computer device to acquire game data with the appropriate computer device over a secure connection. Providing possible information to computer devices. Alternatively, if the session key has already been passed to the computer device, there is no need to send the session key in action 308.

【0046】

With reference to FIG. 2 again, various attributes can be stored in record 124 and used by the opponent determination system 104 when creating and searching game sessions. An attribute is data associated with one game session or one player in one game session. In one embodiment, each attribute has an attribute value indicated by an attribute ID. An example of the 32-bit attribute ID format is shown in Table I below. The attribute ID uniquely indicates the attribute in the game session, and the bit range with different ID also describes the attribute. This description can specify which entity the attribute is associated with, what kind of data is used to represent the attribute value, and which namespace the attribute is associated with.

【0047】

In one embodiment, attributes can be associated with global namespaces or title-specific namespaces. Global attributes are pre-defined attributes by the opponent determination system and have a common meaning throughout all games. Title-specific attributes are defined by the game and have only in-game meaning. Therefore, two different game titles can use the same attribute ID to indicate two different and unrelated attributes. The scope of these title-specific attributes is indicated by the title ID, so the attributes are not confused with each other.

【0048】

[table 1]<img file="JP2004065956A_D0001.tif" /> 【0049】

8 to 12 are diagrams showing a typical message format for transmitting a request and a response between the game console 102 of FIG. 1 and the opponent determination system 104. Each message format contains parts that can contain multiple fields or various data described below.

【0050】

FIG. 8 shows a typical message structure 350 for transmitting a game session creation request from the game console 102 to the opponent determination system 104. The message link field contains the length of the message structure 350. The protocol version field contains the protocol version of the opponent determination protocol used. The session ID field contains the game session ID of the corresponding game session. The title ID field contains the identifier of the game title of the corresponding game session.

【0051】

The host address field contains the address structure of the host computer device. In one embodiment, this address structure is referred to as a fully qualified address (XNADDR) for the host computer device. The fully qualified address of the host computer device allows other computer devices to access the host computer device even if the host computer device may be behind a network address translation (NAT) device such as a network router. Contains enough information for it.

【0052】

The fully qualified address of a computer device is the Ethernet (registered trademark) MAC address for the computer device, the local IP address of the computer device (this is the IP address that the computer device knows to have, and the opponent determination system. May differ from the IP address that receives the data packet from the computer device (for example, for NAT devices such as routers that are installed between the computer device and the opponent determination system (or the security in Figure 13 below). An IP address and port (same as the local IP address of the computer device) on which the opponent determination system (or relay means) receives data packets from the computer device. It may or may be different (eg, the address of the NAT device), and the logical device number (a group of multiple opponent determination systems (or relay means) uniquely indicates the opponent determination system (or relay means). The identifier assigned to the opponent determination system (or relay means) for, and the security parameter index (SPI) value (for example, SPI).₁And / or SPI₂), And the computer device ID. The content of the fully qualified address is the information embedded in the data packet received from the computer device and the information received when establishing a secure connection between the computer device and the opponent determination system (or relay means). It can be decided based on.

【0053】

Value SPI₁Indicates the value generated by the computer device that the device contains in the header of each data packet sent to the opponent determination system (or relay means) over a secure communication channel. The first data packet that the game console sends to the opponent decision system (or relay means) to establish a secure communication channel indicates that a new communication channel is to be established. Or SPI of 0 shown in relay means)₁Includes a value. Subsequent data packets contain non-zero values generated by the game console. Similarly, the opponent determination system (or relay means) includes an SPI in the header of each data packet sent to the game console over a secure communication channel.₂Generate a value for. SPI₁By value, the game console identifies the secure communication channel between the game console and the opponent determination system (or transit vehicle) as the same channel to which the corresponding game console sends data packets. Enable and SPI as well₂Depending on the value, the opponent determination system (or relay means) provides a secure communication channel between the game console and the opponent determination system (or relay means) by the corresponding opponent determination system (or relay means). It makes it possible to identify that it is the same as the specific channel to be transmitted. Each secure communication channel usually has a different SPI value, even between the same game console and the opponent determination system (or relay means).

【0054】

The available public slot field specifies the number of searchable player slots available in the game. When a player joins or leaves the game, the available public slot field values are updated accordingly. The available personal slot field specifies the number of personal player slots available in the game. When a player joins or leaves the game, the available personal slot field values are updated accordingly. Only players who have been invited to the game session can enter the individual player slot.

【0055】

The currently filled public slot field specifies the number of public slots the player currently has. When a player joins or leaves the game, the value of this currently filled public slot field is updated accordingly. The currently filled personal slot field specifies the number of personal slots the player currently has. When a player joins or quits the game, the value of this currently filled personal slot field is updated accordingly. The number of attributes field specifies the number of attributes associated with the game session. The attribute offset field specifies an offset for the attribute associated with the game session. The attributes can be configured in any order. Each attribute offset indicates the area of the message that contains the attribute ID and attribute value (for example, a pointer to it).

【0056】

FIG. 9 is a diagram showing a typical message structure 360 for transmitting a response to a game session creation request from the opponent determination system 104 to the game console 102. The session ID field contains the game session ID assigned to the game session. The key exchange key field contains the game session key assigned to the game session.

【0057】

FIG. 10 shows a typical message structure 370 for transmitting a request for deleting a game session from the game console 102 to the opponent determination system 104. The message link field contains the length of the message structure 370. The protocol version field contains the protocol version of the opponent determination protocol in use. The session ID field contains the game session ID of the corresponding game session. The title ID field contains the identifier of the game title of the corresponding game session.

【0058】

FIG. 11 shows a typical message structure 380 for transmitting a game session search request from the game console 102 to the opponent determination system 104. The message link field contains the length of the message structure 380. The protocol version field contains the protocol version of the opponent determination system in use. The title ID field contains the identifier of the game title of the corresponding game session. The search procedure index field specifies which procedure stored in the opponent determination system is used to perform the search. Using a different search procedure index to specify a different type of search to be performed, such as a game session ID-based search (for example, when responding to an invitation to a game) or a search based on other parameters. Can be done.

【0059】

The parameter number field specifies the number of parameters being sent with this game session search field. The parameters may be configured in any order. Each parameter contains a data type indicator followed by parameter data.

【0060】

FIG. 12 shows a typical message structure 390 for transmitting a response to a game session search request from the opponent determination system 104 to the game console 102. The result link field contains the full length of the search result message structure 390 containing any attributes. The session ID field contains the game session ID of the corresponding game session. The host address field contains the address structure of the host computer device. In one embodiment, this address structure is referred to as the fully qualified address (XNADDR) of the host computer device.

【0061】

The available public slot field specifies the number of searchable player slots available in the game. The available personal slot field specifies the number of personal player slots available in the game. The currently filled public slot field specifies the number of public slots currently filled by the player. The currently filled personal slot field specifies the number of personal slots the player currently has. The number of additional attributes field specifies the number of attributes associated with the game session. The attributes can be configured in any order. Each attribute offset indicates the area of the message that contains the attribute ID and attribute value (eg, a pointer to it).

【0062】

In one embodiment, the opponent determination system 122 of FIG. 2 uses multiple tables to store data for various game sessions. These tables and the data stored in each table are described in Tables II-X below. These tables are a match session table (Table II) that contains a master list of all game sessions managed by the opponent determination system 104, and session attributes for all current game sessions managed by the opponent determination system 104. A match attribute table (Table III) containing a list of, and a match attribute information table (Table III) containing a list of valid title-specific attributes used to monitor the number of title-specific attributes a given title is in use. IV) (The range of attributes can be optionally forced on the title or charged based on the number of attributes), for each game title that is certified to use the opponent determination system 104. Match title table with information (Table V), Match session security gateway search table with information that allows reverse search from the security gateway address to the associated game session ID (Table VI) (for security gateways, Figure 13) (See and described in more detail below), Competitive Configuration Table (Table VII) containing configuration information used by the Opponent Determination Database application, and Competitive Zone Table (Table VIII) containing a complete list of network zones (eg, Table VIII). A set of network zones established within the network in which the opponent determination system 104 of FIG. 1 is implemented, such as the data center 410 of FIG. 13), defining which network address prefix resides in which zone. Includes a match zone map (Table IX), and a match zone distance table (Table X) that includes the distance between paired zones (eg, network latency).

【0063】

[Table 2]<img file="JP2004065956A_D0002.tif" /> 【0064】

[Table 3]<img file="JP2004065956A_D0003.tif" /> 【0065】

[Table 4]<img file="JP2004065956A_D0004.tif" /> 【0066】

[Table 5]<img file="JP2004065956A_D0005.tif" /> 【0067】

[Table 6]<img file="JP2004065956A_D0006.tif" /> 【0068】

[Table 7]<img file="JP2004065956A_D0007.tif" /> 【0069】

[Table 8]<img file="JP2004065956A_D0008.tif" /> 【0070】

[Table 9]<img file="JP2004065956A_D0009.tif" /> 【0071】

[Table 10]<img file="JP2004065956A_D0010.tif" /> 【0072】

In one embodiment, a set of application programming interfaces (APIs) is made available to the game title to use the opponent determination feature. These APIs are exposed to game titles on computer devices, which allow game sessions to be created and searched. A set of game session host APIs that help host game sessions include: -XOnlineMatchSessionCreate-XOnlineMatchSessionUpdate-XOnlineMatchSessionDelete-XOnlineMatchGetSessionInfo.

【0073】

A set of game session client APIs that help search game sessions include: -XOnlineMatchSearch-XOnlineMatchSessionFindFromID-XOnlineMatchSearchGetResults-XOnlineMatchSearchParse.

【0074】

The game title on the computer device host of the game session first calls XOnlineMatchSessionCreate to create a new game session. Base session information and structure containing arbitrary attributes are passed. The API formats the game session request and sends it to the opponent determination system. The online task handle is returned. Once the session creation task is complete, the caller can use the task handle to retrieve the game session ID and game session key (key exchange key) using the XOnlineMatchGetSessionInfo API. When session information or attributes change, you can call XOnlineMatchSessionUpdate to send updates to the server. Again, the task handle is returned. If the host no longer wants to promote the game session on the server, XOnlineMatchSessionDelete is called.

【0075】

XOnlineMatchSessionCreate This feature starts a hosted game session and returns an asynchronous task handle. HRESULT XOnlineMatchSessionCreate (IN DWORD dwPublicCurrent, IN DWORD dwPublicAvailable, IN DWORD dwPrivateCurrent, IN DWORD dwPrivateAvailable, IN DWORD dwNumAttributes, IN PXONLINE_ATTRIBUTE pAttributes, IN HANDLE hWorkEvent, IN HANDLE hWorkEvent

XOnlineMatchSessionCreate parameter dwPublicCurrent-Number of players in the session currently occupying the public slot. dwPublicAvailable-Number of public slots available. dwPrvateCurrent-Number of players in the session currently occupying a personal slot. dwPrivateAvailable-Number of personal slots available. dwNumAttributes-The number of attributes that will be advertised for the session. This number should take into account user-specific attributes that can be replicated when multiple users are sitting in front of the console. pAttributes-An array of attribute structures that describe the attributes of a session. hWorkEvent-A handle to the event object created by the caller. The caller can check this event on a regular basis to determine if there is work to be done. The caller can also move to NULL if planning using the polling model. phTask-On input, this parameter should point to a valid task handle variable. Upon successful return, this variable will be populated with a valid handle.

【0077】

XOnlineMatchSessionCreate Return value S_OK-The game session was created successfully. The handle is returned to phTask.

【0078】

XOnlineMatchSessionUpdate This feature is used to change session information and attributes on the server after a session is created. HRESULT XOnlineMatchSessionUpdate (IN XNKID SessionID, IN DWORD dwPublicCurrent, IN DWORD dwPublicAvailable, IN DWORD dwPrivateCurrent, IN DWORD dwPrivateAvailable, IN DWORD dwNumAttributes, IN PXONLINE_ATTRIBUTE pAttributes, IN PXONLINE_ATTRIBUTE pAttributes

XOnlineMatchSessionUpdate Parameter SessionID-Indicates the session being updated. This value can be retrieved from XOnlineMatchSessionGetInfo. dwPublicAvailable-Number of public slots available. dwPrivateCurrent-Number of players in the session currently occupying a personal slot. dwPrivateAvailable-Number of personal slots available. dwNumAttributes-The number of attributes that are to be advertised for the session. This number should take into account user-specific attributes that can be replicated when multiple users are sitting in front of the console. pAttributes-An array of attribute structures that describe the attributes of a session. hWorkEvent-A handle to the event object created by the caller. The caller can check this event on a regular basis to determine if there is work to be done. The caller can also move to NULL if planning using the polling model. phTask-On input, this parameter should point to a valid task handle variable. Upon successful return, this variable will be populated with a valid handle.

【0080】

XOnlineMatchSessionUpdate Return value S_OK-This feature was successful.

【0081】

XOnlineMatchSessionDelete Parameter This feature is used to delete a session and all its attributes from the server. HRESULT XOnlineMatchSessionDelete (IN XNKID SessionID, IN HANDLE hWorkEvent, OUT PXONLINETASK_HANDLE phTask); [0082]

XOnlineMatchSessionDelete Parameter SessionID-Indicates the session being deleted. This value is retrieved from XOnlineMatchSessionGetInfo after the session is created. hWorkEvent-A handle to the event object created by the caller. The caller can check this event on a regular basis to determine if there is work to be done. The caller can also move to NULL if planning using the polling model. phTask-On input, this parameter should point to a valid task handle variable. Upon successful return, this variable will be populated with a valid handle.

【0083】

XOnlineMatchSessionDelete Return value S_OK-This feature was successful.

【0084】

XOnlineMatchGetSessionInfo This feature is used to retrieve session information from the task handle after a successful completion of XOnlineMatchSessionCreate. HRESULT XOnlineMatchGetSessionInfo (IN XONLINETASK_HANDLE hTask, OUT XNKID * pSessionID, OUT XNKEY * pKeyExchangeKey); [0085]

XOnlineMatchGetSessionInfo Parameter hTask-The online task handle returned by XOnlineMatchSessionCreate. pSessionID-The address of the XNKID variable that is supposed to receive the session ID.

【0086】

pKeyExchangeKey-The address of the XNKEY variable that is supposed to receive the key exchange key.

【0087】

XOnlineMatchGetSessionInfo Return value S_OK-Session ID and key have been successfully returned.

【0088】

To perform a game search, the game title calls XOnlineMatchSearch. The game title passes in the procedure index the maximum number of search results it wants to receive and any parameters that should be passed to the search procedure stored in the database. The game also specifies the maximum buffer size that search results can occupy. This buffer size is internally allocated by the API, and any search results that do not match this buffer will be dropped. The game title can optionally specify an event handle that is supposed to be signaled when work remains.

【0089】

XOnlineMatchSearch returns an online task handle. If it indicates that the search task is complete, the game can retrieve an array of search results by calling XOnlineMatchSearchGetResults using the task handle. Search results can be accessed individually at this point. Any attribute returned can be parsed using XOnlineMatchSearchParse. The game knows in advance the order and type of attributes to be returned. Each individual search result contains XNADDR, XNKID and XNKEY used to connect to the game session host.

【0090】

If the unique game session ID is already known by some out-of-band mechanism such as XOnlineMatchSessionFindFromID, then the API can be used to retrieve a single session using the session ID. Upon completion of this task, the caller will use XOnlineMatchSearchGetResults to retrieve the XNADDR, XNKID and XNKEY for the requested session.

【0091】

XOnlineMatchSearch This feature creates a new game session search, sends the search to the server, and returns an asynchronous task handle to monitor the progress of the request. This feature internally allocates a buffer for search results using the size passed by the caller. HRESULT XOnlineMatchSearch (IN DWORD dwProcedureIndex, IN DWORD dwNumResults, IN DWORD dwNumAttributes, IN PXONLINE_ATTRIBUTE pAttributes, IN DWORD dwResultsLen, IN HANDLE hWorkEvent, OUT PXONLINETASK_HANDLE phTask);

XOnlineMatchSearch Parameter dwProcedureIndex-Indicates the stored procedure for the title that is to be performed in the database to perform the search. dwNumResults-Specifies the maximum number of search results that the game is interested in processing. dwNumAttributes-The number of parameters that are passed as part of the request and are to be passed to the final stored procedure. pAttributes-An array of parameter values. dwResultsLen-This parameter specifies the amount of buffer space the API allocates to hold search results. The API attempts to fill the buffer space specified by this parameter. hWorkEvent-A handle to the event object created by the caller. This object is notified when work remains. This parameter is optional and the caller can instead move to NULL to indicate that he is polling. phTask-Returned to success, this parameter points to a handle that uniquely identifies the search. This handle will be used in subsequent API calls.

【0093】

XOnlineMatchSearch Return value S_OK-The search was created successfully.

【0094】

XOnlineMatchSessionFindFromID This feature retrieves information for a single specified session. This feature expects the session ID to be retrieved by some sort of out-of-band mechanism, such as an invitation. This feature is basically an abbreviation for XOnliheMatchSearch if the procedure index, parameters, and maximum results are fixed. All events performed by multiplying XOnlineMatchSearch are also performed by multiplying the API. The returned task handle is used to allow the API to perform its work on a regular basis. This is the same handle returned by XOnlineMatchSearch. HRESULT XOnlineMatchSessionFindFromID (IN XNKID SessionID, IN HANDLE hWorkEvent, OUT PXONLINETASK_HANDLE phTask); [0095]

XOnlineMatchSessionFindFromID Parameter SessionID-XNKID of the session to get. hWorkEvent-A handle to the event object created by the caller. This object will be notified if there is work left. This parameter is optional and the caller can instead move to NULL to indicate that he is polling. phTask-Returned to success, this parameter points to a handle that uniquely identifies the search. This handle will be used in subsequent search API calls.

【0096】

XOnlineMatchSessionFindFromID Return value S_OK-The search request was successfully sent.

【0097】

XOnlineMatchSearchGetResults This feature is used to retrieve a set of search results for a given search result. This feature is called after the task handle has been acquired since the last call to indicate that XOnlineMatchSearch has completed successfully. HRESULT XOnlineMatchSearchGetResults (IN XONLINETASK_HANDLE hTask, OUT PXMATCH_SEARCHRESULT ** prgpSearchResults, OUT DWORD * pdwReturnedResults); [0098]

XOnlineMatchSearchGetResults parameter hTask-The online task handle returned to XOnlineMatchSearch from the last call. prgpSearchResults-Receives a pointer to an array of search result structures. pdwReturnedResults-Receives the number of search result structures pointed to by prgpSearchResults.

【0099】

XOnlineMatchSearchGetResults Return value S_OK-The search request was successfully returned.

【0100】

XOnlineMatchSearchParse This feature is used to retrieve extended attributes from specific search results. The caller needs to know the exact order and type of this extended attribute. HRESULT XOnlineMatchSearchParse (IN PXMATCH_SEARCHRESULT pSearchResult, IN DWORD dwNumSessionAttributes, IN PXONLINE_ATTRIBUTE_SPEC pSessionAttributeSpec, OUT PVOID pQuerySession); [0101]

XOnlineMatchSearchParse parameter pSearchResult-Specifies the search result during parsing. dwNumSessionAttributes-Specifies the number of extended attributes in the search results. pSessionAttributesSpec-Indicates each type of attribute. pQuerySession-buffer to contain attributes.

【0102】

FIG. 13 is a diagram showing a typical online game environment 400. Multiple game consoles 402 (1), 402 (2), ... 402 (n) are coupled to security gateway 404 via network 406. Network 406 represents any one or more of various conventional data communication networks. The network 406 usually includes a packet switching network, but may include a circuit switching network. Network 406 can include a wired and / or wireless portion. In one typical embodiment, the network 406 includes the Internet and can optionally include one or more local area networks (LANs) and / or wide area networks (WANs). At least part of network 406 is a public network, which is a publicly accessible network. Virtually anyone can access the public network.

【0103】

In some cases, the network 406 includes a LAN (eg, a home network) with a routing device installed between the game console 402 and the security gateway 404. This routing device can perform Network Address Translation (NAT). This allows multiple devices on the LAN to share the same IP address on the Internet, and also to protect one or more devices on the LAN from access by malicious or malicious users over the Internet. It can function as a firewall.

【0104】

The security gateway 404 acts as a gateway between the public network 406 and the private network 408. The dedicated network 408 can be any of a wide range of conventional networks, such as local area networks. The dedicated network 408 and other devices described in more detail below are located within the data center 410, which acts as a secure zone. The data center 410 is composed of reliable communication through a reliable communication means. Therefore, encryption and authentication are not required in secure zone 410. The exclusive nature of network 408 indicates that access to network 408 is limited. That is, access to network 408 is restricted to only certain individuals (eg, restricted by the owner or operator of data center 410).

【0105】

A security gateway 404 is a group of security gateway computer devices. These security gateway computer devices jointly implement a security gateway 404. The security gateway 404 can optionally include one or more conventional load balancing devices that function to direct requests directed by the security gateway computer device to the appropriate device of the computer device. This instruction or load balancing is performed in a way that attempts to balance the load almost evenly on various security gateway computer devices (alternatively, according to some other criteria).

【0106】

In addition, within the data center 410, one or more monitoring servers 412, one or more presence / notification front doors 414, one or more presence servers 416 and one or more notification servers 418 (jointly). Existence / notification service), one or more opponent determination front door 420 (eg interface 120 in Figure 2) and one or more opponent determination servers 422 (eg database 122 in Figure 2) ( There is a joint opponent determination system), and one or more statistics front doors 424 and one or more statistics servers 426 (jointly implement statistics services). Servers 416, 418, 422 and 426 serve the game console 402 and can therefore be referred to as service devices. Other service devices may be added to and / or replaced by one or more of the servers 416, 418, 422 and 426. Further, although FIG. 13 shows only one data center, there may be multiple data centers with which the game console 402 can communicate. These data centers may operate independently or as alternatives (eg, to configure one large data center available for game console 402).

【0107】

The game console 402 is located remotely from the data center 410 and accesses the data center 410 via network 406. A game console 402 wishing to communicate with one or more devices in the data center establishes a secure communication channel between the console 402 and the security gateway 404. The game console 402 and the security gateway 404 encrypt and authenticate the data packets that are exchanged. This ensures that the data packet is securely transmitted between the game console 402 and the security gateway 404 without being recognized by any other device that can capture or copy the data packet without breaking the code. Can be done. Data can be embedded in each data packet transmitted from the game console 402 to the security gateway 404 or from the security gateway 404 to the game console 402. This embedded data is called packet content or data content. Packets can also contain essentially additional information based on the packet type.

【0108】

The secure communication channel between the console 402 and the security gateway 404 is based on the security ticket. The console 402 authenticates itself and one or more current users of the console 402 to the key distribution center 428 and obtains a security ticket from the key distribution center 428. Console 402 then uses this security ticket to establish a secure communication channel with security gateway 404. When establishing a secure communication channel with the security gateway 404, the game console 402 and the security gateway 404 authenticate themselves to each other, and session security known only to that particular game console 402 and the security gateway 404. Set the key. This session security to encrypt the data transferred between the game console 402 and the security gateway cluster 404 so that no other device (including other game consoles 402) can read the data. The key is used. A session security key is also used to authenticate the data packet as originating from a security gateway 404 or game console 402 that claims to originate the data packet. Therefore, such a session security key is used to establish a secure communication channel between the security gateway 404 and the various game consoles 402.

【0109】

Once a secure communication channel has been established between the game console 402 and the security gateway 404, encrypted data packets can be securely transmitted between them. If the game console 402 wants to send data to a particular service device in data center 410, the game console 402 encrypts that data and sends it to one or more specific service devices that the data packet is targeting. Requests the transfer of encrypted data and sends the data to security gateway 404. The security gateway 404 receives this data packet, authenticates and decrypts the data packet, and then encapsulates the data content of the packet into another message for transmission to the appropriate service over the dedicated network 408. The security gateway 404 determines the appropriate service for a message based on one or more requested services targeted by the data packet.

【0110】

Although this specification has mainly described that the encrypted data packet is transmitted between the security gateway 404 and the game console 402, some data packets may be partially encrypted (a part of the data packet). Encrypts, not the other part). Which part of the data packet is encrypted and which part is not encrypted may depend on the wishes of the designer of the data center 410 and / or the game console 402. For example, the designer may choose to allow the transmission of voice data between consoles 402 so that users of console 402 can have conversations with each other. That is, the designer can further choose to allow any other data in the packet to be encrypted, but not the voice data. Moreover, in another alternative form, some data packets may not have an encrypted part (ie, the entire data packet is unencrypted). Note that all data packets can be authenticated, even if the data packets are unencrypted or only partially encrypted.

【0111】

Similarly, if a service device in the data center 410 wants to propagate data to the game console 402, the data center will send data content to the security gateway 404 via a dedicated network 408 to the game console 402. Send a message, including instructions for the particular game console 402 to which the data content should be sent. The security gateway 404 embeds the data content in the data packet, encrypts the data packet so that it can only be decrypted by a particular game console 402, and authenticates the data packet as originating from the security gateway 404. To do.

【0112】

Each security gateway device in security gateway 404 is typically responsible for a secure communication channel with one or more game consoles 402, so each security gateway device manages or manages one or more game consoles, or It can be regarded as being in charge of handling. Various security gateway devices are in communication with each other and can communicate messages with each other. For example, a security gateway device that needs to send a data packet to an unmanaged game console can send a message to all other security gateway devices along with the data that should be sent to that game console. it can. This message is received by the security gateway device that is responsible for managing the game console and sends the appropriate data to the game console. Alternatively, the security gateway device may be aware of which game console is being handled by which security gateway device. This is explicit like each security gateway device that maintains a table of game consoles handled by other security gateway devices, but the security gateway device responsible for a particular game console based on the game console identifier It may be implicit to determine which one.

【0113】

One or more monitoring servers 412 serve to notify the device in data center 410 of the unavailable game console 402, or to notify the unavailable security gateway device of the security gateway 404. The game console 402 has a hardware or software failure, the console shuts down without logging out of the data center 410, the network connection cable to the console 402 is disconnected from the console 402, or other network problems (eg). , The LAN to which the console 402 is connected is not working properly) and may become unusable for a variety of different reasons. Similarly, the security gateway device of Security Gateway 404 is different in variety such as hardware or software failure, device power down, network connection cable to device disconnected from device, other network problems, etc. It may become unusable for some reason.

【0114】

Each security gateway device in a security gateway 404 is monitored by one or more monitoring servers 412, which detects when one of the security gateway devices becomes unavailable. When a security gateway device becomes unavailable, monitoring server 412 sends a message to each of the other devices in data center 410 (servers, front doors, etc.) that the security device is no longer available. Each of the other devices can operate on this information as it deems appropriate (for example, the particular game console managed by the security gateway device is no longer in communication with the data center 410. , Therefore it may be assumed that various terminations are performed). Alternatively, only certain devices (eg, only those that are interested in the availability of security gateway devices) can receive such messages from monitoring server 412.

【0115】

The security gateway 404 monitors individual game consoles 402 and detects when one of the game consoles 402 becomes unavailable. If the security gateway 404 detects that the game console is no longer available, the security gateway 404 sends a message to the game console monitoring server 412 that is unavailable. In response, Surveillance Server 412 sends a message to each of the other devices (or selected devices) in Datacenter 410 that the game console is no longer available. Each of the other devices can then operate on this information as it deems appropriate.

【0116】

One or more Existence Servers 416 hold and process data about the status or existence of a given user logged into Data Center 410 for online games. One or more notification servers 418 maintain multiple queues of outgoing messages destined for players logged in to data center 410. The presence / notification front door 414 is one or more server devices that act as a relay between the security gateway 404 and the servers 416 and 418. One or more load balancing devices (not shown) can be included in the presence / notification front door 414 to balance the load among multiple server devices acting as front door 414. The security gateway 404 propagates a message about servers 416 and 418 to front door 414, which indicates whether the message should be delivered to specific server 416 or specific server 418. The actual embodiments of servers 416 and 418 are extracted from the security gateway 404, such as which server is responsible for managing data about which user using the front door 414. The security gateway 404 simply forwards a message destined for the presence / notification service to the presence / notification front door 414 and transfers the message to the appropriate one of one or more servers 416 and one or more servers 418. It may be left to the front door 414 to specify the route.

【0117】

One or more opponent determination servers 422 mutually retain and process data regarding combinations of online players as described above. Competitive front door 420 includes one or more server devices (and optionally one or more load balancing devices), and front door 414 extracts one or more servers 416 and one or more servers 418. It works to extract one or more match servers 422 from the security gateway 404 in a manner similar to the method.

【0118】

One or more statistics servers 426 hold and process data about various statistics of online games. The specific statistics used may vary at the request of the game designer (eg, top 10 scores or times, world ranking for all online players in the game, list of users who found the most items or longest. A list of users who have played for hours, etc.). Statistics How the front door 426 contains one or more server devices (and optionally one or more load balancing devices) and the front door 414 extracts one or more servers 416 and one or more servers 418. It works to extract one or more statistics servers 426 from the security gateway 404 in a similar way to.

【0119】

Therefore, it can be seen that the security gateway 404 works to protect devices in the secure zone of data center 410 from untrusted public network 406. All devices in data center 410 are trusted, so there is no need to encrypt communications in secure zones within data center 410. However, if the information is encrypted in such a way that it can only be decrypted by the game console 402 to which it is directed, which one should be transmitted from the device in the data center 410 to the game console 402. Even such information passes through the security gateway cluster 404.

【0120】

FIG. 14 is a diagram illustrating a typical computer environment 500 that can be used to implement the techniques described herein. The Computer Environment 500 is merely an example of a computer environment and is not intended to imply any limitation on the scope of use or functionality of computer and network architectures. Also, the computer environment 500 should not be understood to have any dependencies or requirements with respect to any component or combination thereof of the components shown in the typical computer environment 500.

【0121】

The computer environment 500 includes a general-purpose computer device in the computer 502 format. The computer 502 may be, for example, the opponent determination system 104 or computer device 102 of FIG. 1, the opponent determination interface 120 or opponent determination database 122 of FIG. 2, the servers 412, 416, 418 and 422 and / or 426 of FIG. It may be the front door 414, 420 or 424 of FIG. The components of computer 502 include, but are not limited to, one or more processors or processors 504 (optionally including an encryption processor or coprocessor), system memory 506, and various system components including processor 504. Can include a system bus 508 that connects to system memory 506.

【0122】

The system bus 508 is one or more of multiple types of bus configurations, including a memory bus or memory controller, peripheral buses, accelerated graphics ports, and processors or local buses that use any of the various bus architectures. Represents. As an example, such architectures are known as Industry Standard Architecture (ISA) Bus, Micro Channel Architecture (MCA) Bus, Extended ISA (EISA) Bus, Video Electronics Standards Association (VESA) Local Bus, and Mezanin Bus. Peripheral Component Interconnect (PCI) buses can be included.

【0123】

Computer 502 typically includes various computer-readable media. Such media may be any usable medium accessible by computer 502, including both volatile and non-volatile media, removable and non-removable media.

【0124】

System memory 506 includes volatile memory such as random access memory (RAM) 510 and / or computer-readable media in the form of non-volatile memory such as read-only memory (ROM) 512. The basic input / output system (BIOS) 514 contains basic routines that are useful for transferring information between elements of computer 502, such as at boot time, and are stored in ROM 512. The RAM 510 typically contains data and / or program modules that are directly accessible by processing device 504 and / or are currently in operation.

【0125】

Computer 502 may also include other removable / non-removable, volatile / non-volatile computer storage media. As an example, FIG. 14 shows a hard disk drive 516 for reading from and writing to a non-removable non-volatile magnetic medium (not shown), a removable non-volatile magnetic disk 520 (eg, a "floppy® disk"). ) Magnetic disk drive 518 for reading from and writing to it, and optical disk drive 522 for reading and / or writing from a removable non-volatile optical disk such as a CD-ROM, DVD-ROM or other optical medium. Shown. The hard disk drive 516, the magnetic disk drive 518, and the optical disk drive 522 are each connected to the system bus 508 by one or more data medium interfaces 526. Alternatively, hard disk drive 516, magnetic disk drive 518, and optical disk drive 522 can be connected to system bus 508 through one or more interfaces (not shown).

【0126】

Disk drives and their associated computer-readable media provide non-volatile storage for computer-readable instructions, data structures, program modules, and other data for computer 502. This example shows a hard disk 516, a removable magnetic disk 520, and a removable optical disk 524, but to implement this typical computer system and environment, store data accessible by a computer. Other types of computer-readable media that can be used, such as magnetic cassettes or other magnetic storage devices, flash memory cards, CD-ROMs, digital versatile disks (DVDs), or other optical storage devices, random access memory (RAM). It should be understood that read-only memory (ROM), electrically erasable and writable read-only memory (EEPROM), etc. can also be used.

【0127】

Program modules include hard disk 516, magnetic disk 520, optical disk 524, ROM 512, and / or RAM 510, including, for example, operating system 526, one or more application programs 528, other program modules 530, and program data 532. You can store as many as you like. Such an operating system 526, one or more application programs 528, other program modules 530, and program data 532 (or combinations thereof) are all or one of the resident components that each support a distributed file system. The department can be carried out.

【0128】

The user can enter commands and information into computer 502 through input devices such as keyboard 534 and pointing device 536 (eg, "mouse"). Other input devices 538 (not specifically shown) can include microphones, joysticks, gamepads, satellite receiving antennas, serial ports, scanners, and the like. These and other input devices are connected to the processor 504 via an I / O interface 540 coupled to system bus 508, but with other interfaces such as a parallel port, game port, or universal serial bus (USB). And can also be connected by bus configuration.

【0129】

A monitor 542 or other type of display can also be connected to system bus 508 via an interface such as a video adapter 544. In addition to monitor 542, other output peripheral devices can also include components such as speakers (not shown) and printer 546 that can be connected to computer 502 via input / output interface 540.

【0130】

Computer 502 can operate in a networked environment using a logical connection to one or more remote computers, such as remote computer device 548. As an example, the remote computer device 548 may be a personal computer, a portable computer, a server, a router, a network computer, a peer device or other common network node, a game console, and the like. The remote computer device 548 is shown as a portable computer capable of including many or all of the elements and functions described herein with respect to the computer 502.

【0131】

The logical connection between computer 502 and remote computer 548 is shown as a local area network (LAN) 550 and a general wide area network (WAN) 552. Such network connection environments are widespread in offices, corporate computer networks, intranets, and the Internet.

【0132】

When implemented in a LAN network connection environment, computer 502 is connected to local network 550 via a network interface or adapter 554. When implemented in a WAN network connection environment, computer 502 typically includes other means of establishing communication via modem 556 or wide network 552. Modem 556, which may be internal or external to computer 502, can be connected to system bus 508 via I / O interface 540 or other suitable mechanism. It should be understood that the network connection illustrated is an example and other means of establishing one or more communication links between computers 502 and 548 can be used.

【0133】

In a network connection environment as shown with Computer Environment 500, the program module shown for Computer 502, or a portion thereof, can be stored in remote storage. As an example, the remote application program 558 resides in the memory device of the remote computer 548. For illustration purposes, other executable program components such as application programs and operating systems are shown in separate blocks herein, but such programs and components are stored in different storage components of computer device 502 at various times. It should be understood that it resides in and is run by one or more data processors in a computer.

【0134】

Various modules and techniques are described herein in the general context of computer-executable instructions executed by one or more computers or other devices, such as program modules. In general, a program module includes routines, programs, objects, components, data structures, etc. that perform a particular task or perform a particular abstract data type. Generally, the functions of the program modules can be combined or distributed as desired in various embodiments.

【0135】

One embodiment of these modules and techniques can be stored on, or communicated with, in some form of computer-readable medium. The computer-readable medium may be any usable medium accessible by the computer. As an example, but not limited to, a computer-readable medium can include a "computer storage medium" and a "communication medium".

【0136】

"Computer storage medium" is a volatile medium medium, non-volatile medium, removal performed by any method or technique for storing information such as computer readable instructions, data structures, program modules, or other data. Includes removable and non-removable media. Computer storage media include, but are not limited to, RAM, ROM, EEPROM, flash memory or other memory technologies, CD-ROMs, digital versatile disks (DVDs) or other optical storage devices, magnetic cassettes, magnetic tapes, magnetics. Includes disk storage, or other magnetic storage device, or other medium that is used to store desired information and is accessible by a computer.

【0137】

A "communication medium" typically implements a computer-readable instruction, a data structure, a program module, or a modulated data signal such as a carrier wave or other transfer mechanism. The communication medium includes any information delivery medium. The term "modulated data signal" means a signal that has one or more of the property sets or has been modified, such as by a method of encoding information into a signal. By way of example, but not limited to, communication media include wired media such as wired networks or direct wiring connections and radio media such as acoustic media, RF media, infrared media, and other radio media. Any combination of the above is included in the scope of computer readable media.

【0138】

Figure 15 shows the functional components of the Game Console 600 in more detail. The game console 600 can be used, for example, as the computer device 102 of FIG. The Game Console 600 is a processor to central processing unit (CPU) 601 and various types of memory such as flash ROM (read-only memory) 604, RAM (random access memory) 606, hard disk drive 608, and portable media drive 609. It has a memory controller 602 that facilitates access to the. The CPU601 is equipped with a level 1 cache 610 and a level 2 cache 612 for temporary storage of data, which reduces the number of memory access cycles and thus increases processing speed and throughput.

【0139】

The CPU601, memory controller 602, and various memory devices are via one or more buses, including serial and parallel buses, memory buses, peripheral buses, and processors or local buses using any of the various bus architectures. Are interconnected. As an example, such architectures are known as Industry Standard Architecture (ISA) Bus, Micro Channel Architecture (MCA) Bus, Extended ISA (EISA) Bus, Video Electronics Standards Association (VESA) Local Bus, and Mezanin Bus. Peripheral Component Interconnect (PCI) buses can be included.

【0140】

As one suitable embodiment, the CPU601, memory controller 602, ROM604, and RAM606 are integrated into one common module 614. In this embodiment, the ROM 604 is configured as a flash ROM connected to the memory controller 602 via a PCI (peripheral component interconnect) bus and a ROM bus (neither shown). RAM606 is configured as multiple DDR SDRAMs (Double Data Rate Synchronous Dynamic RAM) that are independently controlled by a memory controller 602 via a separate bus (not shown). .. The hard disk drive 608 and the portable media drive 609 are connected to the memory controller via the PCI bus and the ATA (AT attachment) bus 616.

【0141】

The 3D graphics processing device 620 and the video encoder 622 constitute a video processing pipeline for high-speed, high-resolution graphics processing. Data is transported from the graphics processor 620 to the video encoder 622 via a digital video bus (not shown). The audio processing device 224 and the audio codec (coder / decoder) 626 constitute a corresponding audio processing pipeline with hi-fi stereo processing. Audio data is carried between the audio processor 624 and the audio codec 626 via a communication link (not shown). Video processing pipelines and audio processing pipelines output data to A / V (audio / video) port 628 for transmission to televisions or other displays. In the illustrated embodiment, the video and audio processing components 620-628 are implemented in module 614.

【0142】

Similarly, in module 614, the USB host controller 630 and the network interface 632 are implemented. The USB host controller 630 is coupled to the CPU 601 and the memory controller 602 via a bus (for example, the PCI bus), and functions as a host for the peripheral controllers 636 (1) to 636 (4). Network interface 632 provides access to networks (eg, the Internet, home networks, etc.) and offers a wide variety of wired interface components or wireless, including Ethernet® cards, modems, Bluetooth modules, cable modems, and more. It can be any of the interface components.

【0143】

The game console 600 has two dual controller support subassemblies 640 (1) and 640 (2), each subassembly supporting two game controllers 636 (1) to 636 (4). The front panel I / O subassembly 642 supports a power switch 631 and a media drive eject button 633, as well as any LED (light emitting diode) or other indicator exposed on the outer surface of the game console. Subassemblies 640 (1), 640 (2), and 642 are coupled to module 614 via one or more cable assemblies 644.

【0144】

The eight memory units 634 (1) to 634 (8) are shown as two memory units per controller so that they can be connected to the four controllers 636 (1) to 636 (4). Each memory unit 634 provides an additional storage area that can store games, game parameters, and other data. When inserted into the controller, memory unit 634 is accessible by memory controller 602.

【0145】

The system power supply module 650 powers the components of the game console 600. Fan 652 cools the circuit inside the game console 600.

【0146】

The console user interface (UI) application 660 is stored on hard disk drive 608. When the game console is powered on, various parts of the console application 660 are loaded into RAM606 and / or caches 610, 612 and run on CPU601. The console application 660 presents a graphical user interface that provides a consistent user experience when navigating to the different media types available in the game console.

【0147】

The Game Console 600 implements an encryption engine to perform common encryption functions such as encryption, decryption, authentication, digital signatures, and hashing. The encryption engine can be implemented as part of the CPU 601 or as software stored on the hard disk drive 608 running on the CPU, just as the CPU is configured to perform cryptographic functions. Alternatively, the game console 600 can include an encryption processor or coprocessor designed to perform cryptographic functions.

【0148】

The game console 600 can be operated as a stand-alone system by simply connecting the system to a television or other display. In this stand-alone mode, the game console 600 allows one or more players to play games, watch movies, or listen to music. However, by integrating the broadband connections made available via the network interface 632, it is possible to operate the game console 600 as a participant in an online game as described above.

【0149】

In this specification, various processes are shown in a flow chart format. Note that the actions required by these processes can be performed in the order shown in the flow diagram or in a different order. For example, in FIG. 3, the operations may be executed in the order shown or in a different order (for example, the operation 168 may be executed prior to the operation 166 or at the same time). As another example, in FIG. 4, the operations may be performed in the order shown or in a different order (for example, the operation 206 may be executed prior to the operation 204 or at the same time. ).

【0150】

Although the above description uses terms specific to structural functions and / or methodical behaviors, the invention as defined in the claims is limited to the specific functions or behaviors described. Please understand that it is not. Instead, specific features and behaviors are disclosed as typical forms of practicing the present invention.

[Simple explanation of drawings]

FIG. 1 is a block diagram showing a typical environment in which the discovery and distribution of game session information can be used.

FIG. 2 is a block diagram showing a typical opponent determination system in more detail.

FIG. 3 is a flow diagram showing a typical process for creating a new game session.

FIG. 4 is a flow diagram showing another typical process for creating a new game session.

FIG. 5 is a flow diagram illustrating a typical process for distributing information that allows a single computer device to participate in a game session.

FIG. 6 is a flow diagram illustrating a typical process for distributing information that allows a computer device to join a game session invited to join.

FIG. 7 is a flow chart showing a typical process for facilitating information exchange between computer devices.

FIG. 8 is a diagram showing a typical message structure for transmitting a game session creation request.

FIG. 9 is a diagram showing a typical message structure for transmitting a response to a game session creation request.

FIG. 10 shows a typical message structure for transmitting a request to delete a game session.

FIG. 11 is a diagram showing a typical message structure for transmitting a game session search request.

FIG. 12 is a diagram showing a typical message structure for transmitting a response to a game session search request.

FIG. 13 is a block diagram showing a typical online game environment.

FIG. 14 illustrates a typical computer environment that can be used to implement the techniques described herein.

FIG. 15 is a diagram showing the functional components of the game console in more detail.

[Explanation of symbols]

102 Computer device 104 Opponent decision support system