Classifications

• • A63F13/12—
• • A—HUMAN NECESSITIES
  • A63—SPORTS; GAMES; AMUSEMENTS
  • A63F—CARD, BOARD, OR ROULETTE GAMES; INDOOR GAMES USING SMALL MOVING PLAYING BODIES; VIDEO GAMES; GAMES NOT OTHERWISE PROVIDED FOR
  • A63F13/00—Video games, i.e. games using an electronically generated display having two or more dimensions
  • A63F13/70—Game security or game management aspects
  • A63F13/79—Game security or game management aspects involving player-related data, e.g. identities, accounts, preferences or play histories
  • A63F13/795—Game security or game management aspects involving player-related data, e.g. identities, accounts, preferences or play histories for finding other players; for building a team; for providing a buddy list
• • G—PHYSICS
  • G06—COMPUTING; CALCULATING OR COUNTING
  • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
  • G06Q50/00—Systems or methods specially adapted for specific business sectors, e.g. utilities or tourism
  • G06Q50/10—Services
• • A—HUMAN NECESSITIES
  • A63—SPORTS; GAMES; AMUSEMENTS
  • A63F—CARD, BOARD, OR ROULETTE GAMES; INDOOR GAMES USING SMALL MOVING PLAYING BODIES; VIDEO GAMES; GAMES NOT OTHERWISE PROVIDED FOR
  • A63F13/00—Video games, i.e. games using an electronically generated display having two or more dimensions
  • A63F13/30—Interconnection arrangements between game servers and game devices; Interconnection arrangements between game devices; Interconnection arrangements between game servers
• • A—HUMAN NECESSITIES
  • A63—SPORTS; GAMES; AMUSEMENTS
  • A63F—CARD, BOARD, OR ROULETTE GAMES; INDOOR GAMES USING SMALL MOVING PLAYING BODIES; VIDEO GAMES; GAMES NOT OTHERWISE PROVIDED FOR
  • A63F13/00—Video games, i.e. games using an electronically generated display having two or more dimensions
  • A63F13/70—Game security or game management aspects
  • A63F13/71—Game security or game management aspects using secure communication between game devices and game servers, e.g. by encrypting game data or authenticating players
• • A—HUMAN NECESSITIES
  • A63—SPORTS; GAMES; AMUSEMENTS
  • A63F—CARD, BOARD, OR ROULETTE GAMES; INDOOR GAMES USING SMALL MOVING PLAYING BODIES; VIDEO GAMES; GAMES NOT OTHERWISE PROVIDED FOR
  • A63F13/00—Video games, i.e. games using an electronically generated display having two or more dimensions
  • A63F13/70—Game security or game management aspects
  • A63F13/79—Game security or game management aspects involving player-related data, e.g. identities, accounts, preferences or play histories
  • A63F13/798—Game security or game management aspects involving player-related data, e.g. identities, accounts, preferences or play histories for assessing skills or for ranking players, e.g. for generating a hall of fame
• • A—HUMAN NECESSITIES
  • A63—SPORTS; GAMES; AMUSEMENTS
  • A63F—CARD, BOARD, OR ROULETTE GAMES; INDOOR GAMES USING SMALL MOVING PLAYING BODIES; VIDEO GAMES; GAMES NOT OTHERWISE PROVIDED FOR
  • A63F2300/00—Features of games using an electronically generated display having two or more dimensions, e.g. on a television screen, showing representations related to the game
  • A63F2300/50—Features of games using an electronically generated display having two or more dimensions, e.g. on a television screen, showing representations related to the game characterized by details of game servers
• • A—HUMAN NECESSITIES
  • A63—SPORTS; GAMES; AMUSEMENTS
  • A63F—CARD, BOARD, OR ROULETTE GAMES; INDOOR GAMES USING SMALL MOVING PLAYING BODIES; VIDEO GAMES; GAMES NOT OTHERWISE PROVIDED FOR
  • A63F2300/00—Features of games using an electronically generated display having two or more dimensions, e.g. on a television screen, showing representations related to the game
  • A63F2300/50—Features of games using an electronically generated display having two or more dimensions, e.g. on a television screen, showing representations related to the game characterized by details of game servers
  • A63F2300/55—Details of game data or player data management
  • A63F2300/5546—Details of game data or player data management using player registration data, e.g. identification, account, preferences, game history
  • A63F2300/558—Details of game data or player data management using player registration data, e.g. identification, account, preferences, game history by assessing the players' skills or ranking

Definitions

• Some organized competitions may attempt to match players of equal skill in a final round.
• the NCAATM National College Athletics Association
• basketball tournament takes sixty-five teams, and seeds the teams such that (assuming no upsets) its two semifinal games pit the top four teams against one another (i.e., the four number 1 seeds).
• the path of each number 1 seed through the earlier rounds of the tournament is riddled with imbalanced matchups.
• the first round of the NCAATM basketball tournament pits the top seed in a bracket against the lowest seed in a bracket (16 th seed).
• the NCAATM arrangement requires a fixed, limited lineup of teams (the 65 teams in seeded order), and would not easily translate into a video game community having thousands (or millions) of players, and players who may drop out or come in at any time.
• tournament parameters may be defined in advance, and may be automatically instantiated by the game's communication network so that tournaments can be created as needed and exist indefinitely, without the need for constant human supervision. This definition may be done using, for example, an Internet page interface, or by an end user's video game user interface.
• a tournament administrator may log in with a tournament server to define the tournament, entering tournament parameters.
• the tournament may be instantiated one or more times, and the separate instances may individually, and automatically, communicate with the various participants, manage game- session results, and determine tournament winners.
• scoring arbitration may be used to resolve anomalies in scores reported by the various game consoles in the tournament.
• a tournament server may compare its received results with results received by a separate leaderboard process, where the separate leaderboard process may use more secured transmissions with the game consoles to help verify communications.
• tournaments may run according to a schedule, and may be configured to run one after another (e.g., substantially continuously).
• a window factor can identify an amount of time that must elapse before players can be reunited in a game session, to minimize effect of having same players play each other throughout a tournament. Also, a new player factor can be used to adjust scores of newly-entered participants.
• tournament parameters and game settings may be downloaded to a game console to automatically configure the player's machine for the next round of a tournament.
• a qualification period may precede the tournament, during which players may attempt to qualify by posting their corresponding scores.
• Players may be notified of their qualification status, and may be notified again if the status changes due to subsequent players' qualification attempts, and may be given an option to make another attempt at qualification.
• a tournament may be instanced multiple times to accommodate differing levels of qualifiers.
• tournaments may be dynamically adjusted to accommodate variable numbers of qualifying tournament entries.
• the tournament parameters such as number of winners per match, number of players per match, number of rounds, number of players in the tournament's final round, and others, may be varied so that a desired number of qualifiers may participate in the tournament. Entrants may be ranked using a ratio of their total score to the total possible score for rounds that they have played, and that ranking may be used in later groupings of players.
• tournament user interfaces may be displayed to allow user navigation through the tournament process.
• the user may play an interactive, online multiplayer and multi-round video game, and view a list of tournaments for which he/she has qualified.
• Other options may be offered as well, such as searching for tournaments that satisfy user-desired criteria, or displaying tournament and/or competitor details.
• Figure 1 illustrates a game console that may be used to implement various features described herein.
• Figure 2 illustrates components that may be used in the console shown in Figure 1.
• FIG. 17 Figure 3 illustrates how various consoles, and other elements, may be interconnected to implement features described herein.
• Figure 4 illustrates an example network configuration using game consoles.
• Figure 5a illustrates an example computing device that may be used to implement features described herein.
• Figures 5b-m illustrate example software elements and concepts for implementing features described herein.
• [21J Figure 6 illustrates an example process for conducting tournaments.
• Figure 7 illustrates an example of a tournament data structure.
• Figures 8a-b illustrate an example process for a type of tournament
• Figure 8c illustrates an example progression of ranking and reranking.
• Figure 9 illustrates another example process for an alternative type of tournament.
• Figures 10a and 10b illustrate an example seeding bracket and process for seeding.
• Figure 11 illustrates another example seeding bracket.
• Figure 12 illustrates an example relationship chart showing how various user interface screens may be used on a player's console.
• FIG. 1A illustrates an example of a suitable gaming system environment 100 on which computer games, video games, and or other electronic games (collectively referred to herein as computer games) may be played.
• the gaming system environment 100 is only one example of a suitable computing environment and is not intended to suggest any limitation as to the scope of use or functionality of the features described herein. Neither should the gaming system environment 100 be interpreted as having any dependency or requirement relating to any one or combination of components illustrated in the illustrative operating gaming system environment 100.
• program modules include routines, programs, objects, components, data structures, etc. that perform particular tasks or implement particular abstract data types.
• the features described herein may also be practiced in distributed computing environments where tasks are performed by remote processing devices that are linked through a communications network.
• program modules may be located in both local and remote computer storage media including memory storage devices.
• FIG. 1 shows an exemplary gaming system 100.
• Gaming system 100 may include a game console 102 and one or more handheld controllers, as represented by controllers 104(1) and 104(2).
• the game console 102 may be equipped with an internal or external hard disk drive and a portable media drive 106 that supports various forms of portable storage media as represented by optical storage disc 108. Examples of suitable portable storage media include DVD, CD-ROM, game discs, and so forth.
• Game console 102 may have a number of slots 110 on its front face to support up to four controllers, although the number and arrangement of slots may be modified.
• a power button 112 and an eject button 114 are also positioned on the front face of the game console 102.
• the power button 1 12 switches power to the game console and the eject button 1 14 alternately opens and closes a tray of the portable media drive 106 to allow insertion and extraction of the storage disc 108.
• game console 102 may be a dedicated computing device for home entertainment, and may be a closed, secure system that only executes authenticated and authorized applications.
• the game console 102 may be optimized for executing game programs (e.g., having increased processing support for gaming applications, such as physics co-processors, math co-processors, graphics coprocessors, higher resolution video output, higher fidelity audio output, etc.), and may omit certain features commonly found on personal computing devices, such as an alphabetic keyboard, internal hardware expansion slots, printer communication port, etc.
• game programs e.g., having increased processing support for gaming applications, such as physics co-processors, math co-processors, graphics coprocessors, higher resolution video output, higher fidelity audio output, etc.
• Game console 102 may connect to a television or other display (not shown) via A/V interfacing cables 120.
• a power cable 122 provides power to the game console.
• Game console 102 may further be configured with broadband network capabilities, as represented by the cable or modem connector 124 to facilitate access to a network, such as the Internet.
• Connector 124 may also be fitted with a wireless adapter to connect to one or more wireless networks.
• Each controller 104 may be coupled to the game console 102 via a wire or wireless interface.
• the controllers are USB (Universal Serial Bus) compatible and are connected to the console 102 via USB cables 130.
• Controller 102 may be equipped with any of a wide variety of user interaction mechanisms.
• each controller 104 may be equipped with two thumbsticks 132(1) and 132(2), a D-pad 134, buttons 136 (e.g., 'A ⁇ 'B', 'X', ⁇ '), and two triggers 138.
• the thumbsticks 132 may be analog directional control units, and may include analog potentiometers to detect a degree of position in the X- and Y- coordinates.
• D-pad 134 may be a directional pad, with inputs for entering directional commands such as up, down, left and right, or combinations of these directions (e.g., upper-left). D-pad 134 may also be analog, and may provide input as to a degree of pressure used to press in a particular direction. These mechanisms are merely representative, and other known gaming mechanisms may be substituted for or added to those shown in Figure 1.
• a memory unit (MU) 140 may be inserted into the controller 104 to provide additional and portable storage.
• Portable memory units enable users to store game parameters and user accounts, and port them for play on other consoles.
• each controller is configured to accommodate two memory units 140, although more or less than two units may be employed in other implementations.
• a headset 142 may be connected to the controller 104 or game console 102 to provide audio communication capabilities. Headset 142 may include a microphone for audio input and one or more speakers for audio output.
• Gaming system 100 is capable of playing, for example, games, music, and videos. With the different storage offerings, titles can be played from the hard disk drive or the portable medium 108 in drive 106, from an online source, or from a memory unit 140. For security, in some embodiments executable code can only be run from the portable medium 108.
• a sample of what gaming system 100 is capable of playing include game titles played from CD and DVD discs, from the hard disk drive, or from an online source; digital music played from a CD in the portable media drive 106, from a file on the hard disk drive (e.g., "WINDOWSTM” Media Audio (WMA) format), or from online streaming sources; and digital audio/video played from a DVD disc in the portable media drive 106, from a file on the hard disk drive (e.g., Active Streaming Format), or from online streaming sources.
• game titles played from CD and DVD discs, from the hard disk drive, or from an online source digital music played from a CD in the portable media drive 106, from a file on the hard disk drive (e.g., "WINDOWSTM” Media Audio (WMA) format), or from online streaming sources
• WMA Media Audio
• digital audio/video played from a DVD disc in the portable media drive 106 from a file on the hard disk drive (e.g., Active Streaming Format), or from online streaming sources.
• FIG. 2 shows functional components of the gaming system 100 in more detail.
• the game console 102 has a central processing unit (CPU) 200 and a memory controller 202 that facilitates processor access to various types of memory, including a flash ROM (Read Only Memory) 204, a RAM (Random Access Memory) 206, a hard disk drive 208, and the portable media drive 106.
• the CPU 200 is equipped with a level 1 cache 210 and a level 2 cache 212 to temporarily store data and hence reduce the number of memory access cycles, thereby improving processing speed and throughput.
• the CPU 200, memory controller 202, and various memory devices 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.
• bus architectures can include an Industry Standard Architecture (ISA) bus, a Micro Channel Architecture (MCA) bus, an Enhanced ISA (EISA) bus, a Video Electronics Standards Association (VESA) local bus, and a Peripheral Component Interconnects (PCI) bus also known as a Mezzanine bus.
• the CPU 200, memory controller 202, ROM 204, and RAM 206 are integrated onto a common module 214.
• ROM 204 is configured as a flash ROM that is connected to the memory controller 202 and a ROM bus (not shown).
• RAM 206 is configured as multiple DDR SDRAM (Double Data Rate Synchronous Dynamic RAM) that are independently controlled by the memory controller 202 via separate buses (not shown).
• the hard disk drive 208 and portable media drive 106 are connected to the memory controller via the PCI bus and an ATA (AT Attachment) bus 216.
• a 3D graphics processing unit 220 and a video encoder 222 form a video processing pipeline for high speed and high resolution graphics processing. Data is carried from the graphics processing unit 220 to the video encoder 222 via a digital video bus (not shown).
• An audio processing unit 224 and an audio codec (coder/decoder) 226 form a corresponding audio processing pipeline with high fidelity and stereo processing. Audio data is carried between the audio processing unit 224 and the audio codec 226 via a communication link (not shown).
• the video and audio processing pipelines output data to an A/V (audio/video) port 228 for transmission to the television or other display.
• the video and audio processing components 220-228 are mounted on the module 214.
• USB host controller 230 is coupled to the CPU 200 and the memory controller 202 via a bus (e.g., PCI bus) and serves as host for the peripheral controllers 104(1)- 104(4).
• the network interface 232 provides access to a network (e.g., Internet, home network, etc.) and may be any of a wide variety of various wire or wireless interface components including an Ethernet card, a modem, a Bluetooth module, a cable modem, and the like.
• the game console 102 has two dual controller support subassemblies 240(1) and 240(2), with each subassembly supporting two game controllers 104(l)-104(4).
• a front panel I/O subassembly 242 supports the functionality of the power button 112 and the eject button 114, as well as any LEDs (light emitting diodes) or other indicators exposed on the outer surface of the game console.
• the subassemblies 240(1), 240(2), and 242 are coupled to the module 214 via one or more cable assemblies 244.
• game console 102 may also include a keyboard input subassembly 240(3), to which is connected a keyboard 254.
• the keyboard 254 and its subassembly might be offered as part of a developer's kit version of the console 102, to allow the use of a keyboard for entering text commands and data for testing purposes.
• the keyboard 254 may communicate directly with a controller port (e.g., as in subassemblies 240), and the use of a separate keyboard input subassembly is not necessary.
• a keyboard driver and subassembly may be omitted from the console, and instead the console may be coupled to a second computing device (e.g., another PC, or a debugging workstation) via USB cable, by which the second computing device may send command sequences to the game console, reducing the need in the game console for separate software and/or hardware for interpreting text command sequences entered via the keyboard.
• a second computing device e.g., another PC, or a debugging workstation
• Eight memory units 140(1)- 140(8) are illustrated as being connectable to the four controllers 104(I)-104(4), i.e., two memory units for each controller. Each memory unit 140 offers additional storage on which games, game parameters, and other data may be stored. When inserted into a controller, the memory unit 140 can be accessed by the memory controller 202.
• a system power supply module 250 provides power to the components of the gaming system 100.
• a fan 252 cools the circuitry within the game console 102.
• the game console 102 implements a uniform media portal model that provides a consistent user interface and navigation hierarchy to move users through various entertainment areas.
• the portal model offers a convenient way to access content from multiple different media types — game data, audio data, and video data — regardless of the media type inserted into the portable media drive 106.
• a console user interface (UI) application 260 is stored on the hard disk drive 208.
• various portions of the console application 260 are loaded into RAM 206 and/or caches 210, 212 and executed on the CPU 200.
• the console application 260 presents a graphical user interface that provides a consistent user experience when navigating to different media types available on the game console.
• the gaming system 100 may be operated as a standalone system by simply connecting the system to a television or other display. In this standalone mode, the gaming system 100 allows one or more players to play games, watch movies, or listen to music. However, with the integration of broadband connectivity made available through the network interface 232, the gaming system 100 may further be operated as a participant in a larger network gaming community. This network gaming environment is described next.
• FIG. 3 shows an exemplary network gaming environment 300 that interconnects multiple gaming systems 100(1), ..., 100(g) via a network 302.
• the network 302 represents any of a wide variety of data communications networks. It may include public portions (e.g., the Internet) as well as private portions (e.g., a residential Local Area Network (LAN)), as well as combinations of public and private portions.
• Network 302 may be implemented using any one or more of a wide variety of conventional communications media including both wired and wireless media. Any of a wide variety of communications protocols can be used to communicate data via network 302, including both public and proprietary protocols. Examples of such protocols include TCP/IP, IPX/SPX, NetBEUI, etc.
• one or more online services 304(1), ..., 304(s) may be accessible via the network 302 to provide various services for the participants, such as hosting online games, serving downloadable music or video files, hosting gaming competitions, serving streaming audio/video files, and the like.
• the network gaming environment 300 may further involve a key distribution center 306 that plays a role in authenticating individual players and/or gaming systems 100 to one another as well as online services 304.
• the distribution center 306 distributes keys and service tickets to valid participants that may then be used to form games amongst multiple players or to purchase services from the online services 304.
• the network gaming environment 300 introduces another memory source available to individual gaming systems 100 — online storage.
• the gaming system 100(1) can also access data files available at remote storage locations via the network 302, as exemplified by remote storage 308 at online service 304(s).
• FIG 4 is a block diagram of another illustrative online gaming environment 400, e.g. "XBOXTM LIVETM" by Microsoft Corporation of Redmond, Washington.
• Multiple game consoles 402(1), 402(2), ..., 402(n) are coupled to a security gateway 404 via a network 406.
• Each game console 402 can be, for example, a game console 102 of Figure 1 or Figure 2.
• Network 406 represents any one or more of a variety of conventional data communications networks.
• Network 406 will typically include packet switched networks, but may also include circuit switched networks.
• Network 406 can include wire and/or wireless portions.
• network 406 includes the Internet and may optionally include one or more local area networks (LANs) and/or wide area networks (WANs).
• LANs local area networks
• WANs wide area networks
• At least a part of network 406 is a public network, which refers to a network that is publicly-accessible. Virtually anyone can access the public network.
• network 406 includes a LAN (e.g., a home network), with a routing device situated between game console 402 and security gateway 404.
• This routing device may perform network address translation (NAT), allowing the multiple devices on the LAN to share the same IP address on the Internet, and also operating as a firewall to protect the device(s) on the LAN from access by malicious or mischievous users via the Internet.
• NAT network address translation
• Security gateway 404 operates as a gateway between public network 406 and a private network 408.
• Private network 408 can be any of a wide variety of conventional networks, such as a local area network. Private network 408, as well as other devices discussed in more detail below, is within a data center 410 that operates as a secure zone. Data center 410 is made up of trusted devices communicating via trusted communications. Thus, encryption and authentication within secure zone 410 is not necessary.
• the private nature of network 408 refers to the restricted accessibility of network 408 — access to network 408 is restricted to only certain individuals (e.g., restricted by the owner or operator of data center 410).
• Security gateway 404 is a cluster of one or more security gateway computing devices. These security gateway computing devices collectively implement security gateway 404. Security gateway 404 may optionally include one or more conventional load balancing devices that operate to direct requests to be handled by the security gateway computing devices to appropriate ones of those computing devices. This directing or load balancing is performed in a manner that attempts to balance the load on the various security gateway computing devices approximately equally (or alternatively in accordance with some other criteria).
• Also within data center 410 are: one or more monitoring servers 412; one or more presence and notification front doors 414, one or more presence servers 416, one or more notification servers 418, and a profile store 428 (collectively implementing a presence and notification service or system 430); one or more match front doors 420 and one or more match servers 422 (collectively implementing a match service); and one or more statistics front doors 424 and one or more statistics servers 426 (collectively implementing a statistics service).
• the servers 416, 418, 422, and 426 provide services to game consoles 402, and thus can be referred to as service devices. Other service devices may also be included in addition to, and/or in place of, one or more of the servers 416, 418, 422, and 426.
• Game consoles 402 are situated remotely from data center 410, and access data center 410 via network 406. A game console 402 desiring to communicate with one or more devices in the data center logs in to the data center and establishes a secure communication channel between the console 402 and security gateway 404.
• Game console 402 and security gateway 404 encrypt and authenticate data packets being passed back and forth, thereby allowing the data packets to be securely transmitted between them without being understood by any other device that may capture or copy the data packets without breaking the encryption.
• Each data packet communicated from game console 402 to security gateway 404, or from security gateway 404 to game console 402 can have data embedded therein. This embedded data is referred to as the content or data content of the packet. Additional information may also be inherently included in the packet based on the packet type (e.g., a heartbeat packet).
• the secure communication channel between a console 402 and security gateway 404 is based on a security ticket.
• Console 402 authenticates itself and the current user(s) of console 402 to a key distribution center 429 and obtains, from key distribution center 429, a security ticket.
• Console 402 then uses this security ticket to establish the secure communication channel with security gateway 404.
• the game console 402 and security gateway 404 authenticate themselves to one another and establish a session security key that is known only to that particular game console 402 and the security gateway 404. This session security key is used to encrypt data transferred between the game console 402 and the security gateway cluster 404, so no other devices (including other game consoles 402) can read the data.
• the session security key is also used to authenticate a data packet as being from the security gateway 404 or game console 402 that the data packet alleges to be from.
• session security keys secure communication ""channels can be established between the security gateway 404 and the various game consoles 402.
• a service device in data center 410 desires to communicate data to a game console 402
• the data center sends a message to security gateway 404, via private network 408, including the data content to be sent to the game console 402 as well as an indication of the particular game console 402 to which the data content is to be sent.
• Security gateway 404 embeds the data content into a data packet, and then encrypts the data packet so it can only be decrypted by the particular game console 402 and also authenticates the data packet as being from the security gateway 404.
• some data packets may be partially encrypted (some portions of the data packets are encrypted while other portions are not encrypted). Which portions of the data packets are encrypted and which are not can vary based on the desires of the designers of data center 410 and/or game consoles 402. For example, the designers may choose to allow voice data to be communicated among consoles 402 so that users of the consoles 402 can talk to one another — the designers may further choose to allow the voice data to be unencrypted while any other data in the packets is encrypted. Additionally, in another alternative, some data packets may have no portions that are encrypted (that is, the entire data ' packet is unencrypted). It should be noted that, even if a data packet is unencrypted or only partially encrypted, all of the data packet can still be authenticated.
• Each security gateway device in security gateway 404 is responsible for the secure communication channel with typically one or more game consoles 402, and thus each security gateway device can be viewed as being responsible for managing or handling one or more game consoles.
• the various security gateway devices may be in communication with each other and communicate messages to one another. For example, a security gateway device that needs to send a data packet to a game console that it is not responsible for managing may send a message to all the other security gateway devices with the data to be sent to that game console. This message is received by the security gateway device that is responsible for managing that game console and sends the appropriate data to that game console.
• the security gateway devices may be aware of which game consoles are being handled by which security gateway devices - this may be explicit, such as each security gateway device maintaining a table of game consoles handled by the other security gateway devices, or alternatively implicit, such as determining which security gateway device is responsible for a particular game console based on an identifier of the game console.
• Monitoring server(s) 412 operate to inform devices in data center 410 of an unavailable game console 402 or an unavailable security gateway device of security gateway 404.
• Game consoles 402 can become unavailable for a variety of different reasons, such as a hardware or software failure, the console being powered-down without logging out of data center 410, the network connection cable to console 402 being disconnected from console 402, .other network problems (e.g., the LAN that the console 402 is on malfunctioning), etc.
• a security gateway device of security gateway 404 can become unavailable for a variety of different reasons, such as hardware or software failure, the device being powered-down, the network connection cable to the device being disconnected from the device, other network problems, etc.
• Each of the security gateway devices in security gateway 404 is monitored by one or more monitoring servers 412, which detect when one of the security gateway devices becomes unavailable. In the event 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 gateway device is no longer available. Each of the other devices can operate based on this information as it sees fit (e.g., it may assume that particular game consoles being managed by the security gateway device are no longer in communication with data center 410 and perform various clean-up operations accordingly). Alternatively, only certain devices may receive such a message from the monitoring server 412 (e.g., only those devices that are concerned with whether security gateway devices are available).
• Security gateway 404 monitors the individual game consoles 402 and detects when one of the game consoles 402 becomes unavailable. When security gateway 404 detects that a game console is no longer available, security gateway 404 sends a message to monitoring server 412 identifying the unavailable game console. In response, monitoring server 412 sends a message to each of the other devices in data center 410 (or alternatively only selected devices) that the game console is no longer available. Each of the other devices can then operate based on this information as it sees fit.
• Presence server(s) 416 hold and process data concerning the status or presence of a given user logged in to data center 410 for online gaming.
• Notification server(s) 418 maintains multiple notification queues of outgoing messages destined for a player logged in to data center 410.
• Presence and notification front door 414 is one or more server devices that operate as an intermediary between security gateway 404 and servers 416 and 418.
• One or more load balancing devices may be included in presence and notification front door 414 to balance the load among the multiple server devices operating as front door 414.
• Security gateway 404 communicates messages for servers 416 and 418 to the front door 414, and the front door 414 identifies which particular server 416 or particular server 418 the message is to be communicated to.
• Security gateway 404 can simply forward messages that target the presence and notification service to presence and notification front door 414 and rely on front door 414 to route the messages to the appropriate one of server(s) 416 and server(s) 418.
• Match server(s) 422 hold and process data concerning the matching of online players to one another.
• An online user is able to advertise a game available for play along with various characteristics of the game (e.g., the location where a football game will be played, whether a game is to be played during the day or at night, the user's skill level, etc.). These various characteristics can then be used as a basis to match up different online users to play games together.
• Match front door 420 includes one or more server devices (and optionally a load balancing device(s)) and operates to abstract match server(s) 422 from security gateway 404 in a manner analogous to front door 414 abstracting server(s) 416 and server(s) 418.
• Statistics server(s) 426 hold and process data concerning various statistics for online games. The specific statistics used can vary based on the game designer's desires (e.g., the top ten scores or times, a world ranking for all online players of the game, a list of users who have found the most items or spent the most time playing, etc.).
• Statistics front door 426 includes one or more server devices (and optionally a load balancing device(s)) and operates to abstract statistics server(s) 426 from security gateway 404 in a manner analogous to front door 414 abstracting server(s) 416 and server(s) 418.
• Title server(s) 432 may be provided for each individual game title or program supported by the online service. Each title server 432 may act as a server and communicate with game consoles 402 to execute programs and/or modules for conducting an online gaming session. The server 432 may be given as much, or as little, control over actions in a game as desired by the game developer.
• some games may rely on the centralized title server 432 to perform calculations and processing having to do with interactions among multiple players on different game consoles 402, such as determining which player character was first to a particular point on a map, or controlling the appearance of a common environment in which the various players' characters appear, and may rely on the individual consoles 402 to handle the just the more localized aspects, such as the actual rendering of images and results, and initial processing of user inputs.
• consoles 402 may rely more on the consoles 402 for processing. Processing responsibilities for a given game may be distributed among a plurality of consoles 402 that are connected to a game session. Or, the game may select a subset of the consoles 402 connected to the session, and cause that console to act as the server for the session. In such a situation, title server 432 may simply coordinate communications between the game consoles 402, or may simply perform initial startup functions (e.g., game type, startup authorization, etc.), and then await results.
• initial startup functions e.g., game type, startup authorization, etc.
• tournament servers 434 may also be present to manage tournament functionality. This functionality will be described in greater detail below, and may generally relate to the creation, management and/or termination of online multiplayer tournaments.
• the various servers described above need not reside on separate machines, as some or all of them may be combined into a common process or machine.
• security gateway 404 operates to shield devices in the secure zone of data center 410 from the untrusted, public network 406. Communications within the secure zone of data center 410 need not be encrypted, as all devices within data center 410 are trusted. However, any information to be communicated from a device within data center 410 to a game console 402 passes through security gateway cluster 404, where it is encrypted in such a manner that it can be decrypted by only the game console
• title server 432 and tournament server 434 may reside behind a second security gateway 405.
• Security gateway 405 may be the same as security gateway 404, or it may be a simplified one to omit features not needed by its servers and devices.
• One or more features described herein may be embodied in computer-executable instructions (i.e., software) stored in RAM memory 206, non-volatile memory 108, 208, 308, or any other resident memory on game console 102.
• software modules include routines, programs, objects, components, data structures, etc. that perform particular tasks or implement particular abstract data types when executed by a processor in a computer or other device.
• the computer executable instructions may be stored on a computer readable medium such as one or more hard disks 208, removable storage media 108 (e.g., CD-ROM, DVD, disk, etc.), solid state memory, RAM 206, etc.
• the functionality of the software modules may be combined or distributed as desired in various embodiments.
• the functionality may be embodied in whole or in part in firmware or hardware equivalents such as application specific integrated circuits (ASIC), field programmable gate arrays (FPGA), and the like.
• ASIC application specific integrated circuits
• FPGA field programmable gate arrays
• FIG. 5 A illustrates an example of a suitable computing system environment 500 on which the features described herein may be implemented.
• the computing system environment 500 is only one example of a suitable computing environment and is not intended to suggest any limitation as to the scope of use or functionality of the features described herein. Neither should the computing environment 500 be interpreted as having any dependency or requirement relating to any one or combination of components illustrated in the exemplary operating environment 500.
• program modules include routines, programs, objects, components, data structures, etc., that perform particular tasks or implement particular abstract data types.
• the features may also be practiced in distributed computing environments where tasks are performed by remote processing devices that are linked through a communications network.
• program modules may be located in both local and remote computer storage media including memory storage devices.
• an exemplary system for implementing the features described herein includes a general purpose computing device in the form of a computer 510.
• Components of computer 510 may include, but are not limited to, a processing unit 520, a system memory 530, and a system bus 521 that couples various system components including the system memory to the processing unit 5.20.
• the system bus 521 may be any of several types of bus structures including a memory bus or memory controller, a peripheral bus, and a local bus using any of a variety of bus architectures.
• such architectures include Industry Standard Architecture (ISA) bus, Micro Channel Architecture (MCA) bus, Enhanced ISA (EISA) bus, Video Electronics Standards Association (VESA) local bus, and Peripheral Component Interconnect (PCI) bus also known as Mezzanine bus.
• ISA Industry Standard Architecture
• MCA Micro Channel Architecture
• EISA Enhanced ISA
• VESA Video Electronics Standards Association
• PCI Peripheral Component Interconnect
• Computer 510 typically includes a variety of computer readable media.
• Computer readable media can be any available media that can be accessed by computer 510 and includes both volatile and nonvolatile media, removable and non-removable media.
• Computer readable media may comprise computer storage media and communication media.
• Computer storage media includes both volatile and nonvolatile, and removable and non-removable media implemented in any method or technology for storage of information such as computer readable instructions, data structures, program modules or other data.
• Computer storage media includes, but is not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disks (DVD) or other optical disk storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices (in the singular or the plural), or any other medium which can be used to store the desired information and which can accessed by computer 510.
• Communication media typically embodies computer readable instructions, data structures, program modules or other data in a modulated data signal such as a carrier wave or other transport mechanism and includes any information delivery media.
• modulated data signal means a signal that has one or more of its characteristics set or changed in such a manner as to encode information in the signal.
• communication media includes wired media such as a wired network or direct-wired connection, and wireless media such as acoustic, RF, infrared and other wireless media. Combinations of the any of the above should also be included within the scope of computer readable media.
• the system memory 530 includes computer storage media in the form of volatile and/or nonvolatile memory such as read only memory (ROM) 531 and random access memory (RAM) 532.
• ROM read only memory
• RAM random access memory
• BIOS basic input/output system 533
• RAM 532 typically contains data and/or program modules that are immediately accessible to and/or presently being operated on by processing unit 520.
• Figure 5A illustrates operating system 534, application programs 535, other program modules 536, and program data 537.
• the computer 510 may also include other removable/non-removable, volatile/nonvolatile computer storage media.
• Figure 5 illustrates a hard disk drive 541 that reads from or writes to non-removable, nonvolatile magnetic media, a magnetic disk drive 551 that reads from or writes to a removable, nonvolatile magnetic disk 552, and an optical disk drive 555 that reads from or writes to a removable, nonvolatile optical disk 556 such as a CD ROM or other optical media.
• removable/non-removable, volatile/nonvolatile computer storage media that can be used in the exemplary operating environment include, but are not limited to, magnetic tape' cassettes, flash memory cards, digital versatile disks, digital video tape, solid state RAM, solid state ROM, and the like.
• the hard disk drive 541 is typically connected to the system bus 521 through a non-removable memory interface such as interface 540, and magnetic disk drive 551 and optical disk drive 555 are typically connected to the system bus 521 by a removable memory interface, such as interface 550.
• the drives and their associated computer ⁇ storage media discussed above and illustrated in Figure 5 A, provide storage of computer readable instructions, data structures, program modules and other data for the computer 510.
• hard disk drive 541 is illustrated as storing operating system 544, application programs 545, other program modules 546, and program data 547. Note that these components can either be the same as or different from operating system 534, application programs 535, other program modules 536, and program data 537. Operating system 544, application programs 545, other program modules 546, and program data 547 are given different numbers here to illustrate that, at a minimum, they are different copies.
• a user may enter commands and information into the computer through input devices such as a keyboard 562 and pointing device 561, commonly referred to as a mouse, trackball or touch pad.
• Other input devices may include a microphone, joystick, game pad, satellite dish, scanner, or the like.
• a user input interface 560 that is coupled to the system bus, but may be connected by other interface and bus structures, such as a parallel port, game port or a universal serial bus (USB).
• a monitor 591 or other type of display device is also connected to the system bus 521 via an interface, such as a video interface 590.
• computers may also include other peripheral output devices such as speakers 597 and printer 596, which may be connected through an output peripheral interface 595.
• the computer 510 may operate in a networked environment using logical connections to one or more remote computers, such as a remote computer 580.
• the remote computer 580 may be a personal computer, a server, a router, a network PC, a peer device or other common network node, and typically includes many or all of the elements described above relative to the computer 510, although only a memory storage device 581 has been illustrated in Figure 5.
• the logical connections depicted in Figure 5 include a local area network (LAN) 571 and a wide area network (WAN) 573, but may also include other networks.
• LAN local area network
• WAN wide area network
• Such networking environments are commonplace in offices, enterprise-wide computer networks, intranets and the Internet.
• the computer 510 When used in a LAN networking environment, the computer 510 is connected to the LAN 571 through a network interface or adapter 570. When used in a WAN networking environment, the computer 510 typically includes a modem 572 or other means for establishing communications over the WAN 573, such as the Internet.
• the modem 572 which may be internal or external, may be connected to the system bus 521 via the user input interface 560, or other appropriate mechanism.
• program modules depicted relative to the computer 510, or portions thereof may be stored in the remote memory storage device.
• Figure 5 illustrates remote application programs 585 as residing on memory device 581. It will be appreciated that the network connections shown are exemplary and other means of establishing a communications link between the computers may be used.
• a programming interface may be viewed as any mechanism, process, protocol for enabling one or more segment(s) of code to communicate with or access the functionality provided by one or more other segment(s) of code.
• a programming interface may be viewed as one or more mechanism(s), method(s), function call(s), module(s), object(s), etc. of a component of a system capable of communicative coupling to one or more mechanism(s), method(s), function call(s), module(s), etc. of other component s).
• segment of code in the preceding sentence is intended to include one or more instructions or lines of code, and includes, e.g., code modules, objects, subroutines, functions, and so on, regardless of the terminology applied or whether the code segments are separately compiled, or whether the code segments are provided as source, intermediate, or object code, whether the code segments are utilized in a runtime system or process, or whether they are located on the same or different machines or distributed across multiple machines, or whether the functionality represented by the segments of code are implemented wholly in software, wholly in hardware, or a combination of hardware and software.
• a programming interface may be viewed generically, as shown in Figure 5B or Figure 5C.
• Figure 5B illustrates an interface Interfacel as a conduit through which first and second code segments communicate.
• Figure 5C illustrates an interface as comprising interface objects Il and 12 (which may or may not be part of the first and second code segments), which enable first and second code segments of a system to communicate via medium M.
• interface objects Il and 12 are separate interfaces of the same system and one may also consider that objects Il and 12 plus medium M comprise the interface.
• Figures 5B and 5C show bidirectional flow and interfaces on each side of the flow, certain implementations may only have information flow in one direction (or no information flow as described below) or may only have an interface object on one side.
• terms such as application programming interface (API) 5 entry point, method, function, subroutine, remote procedure call, and component object model (COM) interface are encompassed within the definition of programming interface.
• aspects of such a programming interface may include the method whereby the first code segment transmits information (where "information" is used in its broadest sense and includes data, commands, requests, etc.) to the second code segment; the method whereby the second code segment receives the information; and the structure, sequence, syntax, organization, schema, timing and content of the information.
• the underlying transport medium itself may be unimportant to the operation of the interface, whether the medium be wired or wireless, or a combination of both, as long as the information is transported in the manner defined by the interface.
• information may not be passed in one or both directions in the conventional sense, as the information transfer may be either via another mechanism (e.g. information placed in a buffer, file, etc.
• a communication from one code segment to another may be accomplished indirectly by breaking the communication into multiple discrete communications.
• This is depicted schematically in Figures 5D and 5E.
• some interfaces can be described in terms of divisible sets of functionality.
• the interface functionality of Figures 5B and 5C may be factored to achieve the same result, just as one may mathematically provide 24, or 2 times 2 times 3 times 2.
• the function provided by interface Interface 1 may be subdivided to convert the communications of the interface into multiple interfaces InterfacelA, InterfacelB, InterfacelC, etc. while achieving the same result.
• the function provided by interface Il may be subdivided into multiple interfaces Ha, lib, Hc, etc.
• interface 12 of the second code segment which receives information from the first code segment may be factored into multiple interfaces I2a, I2b, I2c, etc.
• the number of interfaces included with the 1st code segment need not match the number of interfaces included with the 2nd code segment.
• the functional spirit of interfaces Interface 1 and Il remain the same as with Figures 5B and 5C, respectively.
• the factoring of interfaces may also follow associative, commutative, and other mathematical properties such that the factoring may be difficult to recognize.
• ordering of operations may be unimportant, and consequently, a function carried out by an interface may be carried out well in advance of reaching the interface, by another piece of code or interface, or performed by a separate component of the system.
• a function carried out by an interface may be carried out well in advance of reaching the interface, by another piece of code or interface, or performed by a separate component of the system.
• one of ordinary skill in the programming arts can appreciate that there are a variety of ways of making different function calls that achieve the same result.
• the functionality of square can be achieved, so long as output is returned after input is squared by the second code segment.
• Precision may very well be a meaningful parameter to some downstream or other portion of the computing system; however, once it is recognized that precision is not necessary for the narrow purpose of calculating the square, it may be replaced or ignored. For example, instead of passing a valid precision value, a meaningless value such as a birth date could be passed without adversely affecting the result.
• interface Il is replaced by interface 11 % redefined to ignore or add parameters to the interface.
• Interface 12 may similarly be redefined as interface 12', redefined to ignore unnecessary parameters, or parameters that may be processed elsewhere.
• a programming interface may include aspects, such, as parameters, which are not needed for some purpose, and so they may be ignored or redefined, or processed elsewhere for other purposes.
• interface 12 from Figure 1C may be written inline into interface Il to form interface H".
• interface 12 is divided into I2a and I2b, and interface portion I2a has been coded in-line with interface Il to form interface H".
• the interface Il from Figure 5C performs a function call square (input, output), which is received by interface 12, which after processing the value passed with input (to square it) by the second code segment, passes back the squared result with output.
• the processing performed by the second code segment (squaring input) can be performed by the first code segment without a call to the interface.
• a communication from one code segment to another may be accomplished indirectly by breaking the communication into multiple discrete communications.
• This is depicted schematically in Figures 5J and 5K.
• one or more piece(s) of middleware Divorce Interface(s), since they divorce functionality and/or interface functions from the original interface
• Interface2A, Interface2B and Interface2C This might be done, e.g., where there is an installed base of applications designed to communicate with, say, an operating system in accordance with an Interfacel protocol, but then the operating system is changed to use a different interface, in this case interfaces Interface2A, Interface2B and Interface2C.
• a third code segment can be introduced with divorce interface DIl to receive the communications from interface Il and with divorce interface DI2 to transmit the interface functionality to, for example, interfaces I2a and I2b, redesigned to work with DI2, but to provide the same functional result.
• DIl and DI2 may work together to translate the functionality of interfaces Il and 12 of Figure 5C to a new operating system, while providing the same or similar functional result.
• Yet another possible variant is to dynamically rewrite the code to replace the interface functionality with something else but which achieves the same overall result.
• a code segment presented in an intermediate language e.g. Microsoft IL, Java ByteCode, etc.
• JIT Just-in-Time
• the JIT compiler may be written so as to dynamically convert the communications from the 1st Code Segment to the 2nd Code Segment, i.e., to conform them to a different interface as may be required by the 2nd Code Segment (either the original or a different 2nd Code Segment).
• Various features provide for the automation of providing debugging feedback information to a server by dumping portions of memory and automatically sending the dumped memory to a server when certain debugging events occur.
• FIG. 6 illustrates an example overall process by which a tournament may be conducted in an online multiplayer gaming environment.
• a tournament administrator may take steps to log in to a secure server, such as tournament server 434, to begin the creation of an online tournament.
• the administrator may be a game developer, player, or anyone having the right to create new tournament types on the system.
• the log in process may involve any desired mode of access, such as accessing a secure Internet site using a password and a computer terminal 510, or accessing an online location using a video game user interface from a console 402.
• the tournament administrator may define the various parameters for the tournament being created. This entry may be accomplished using a displayed interface, such as an Internet page or a video game user interface, where the administrator may be prompted to enter (or select from a list) the various parameters for the tournament being defined. Example parameters are discussed further below.
• the process may then proceed to step 603, where the system (e.g., the tournament server 434, or title server 432, depending on which server is designated for the task) awaits a trigger for instantiating a tournament.
• the trigger may be of any type of predetermined event, such as the passage of a predetermined amount of time (e.g., an hour, 30 minutes, etc.), or the registration by a predetermined number of players (e.g., 10, 50, 100 players, etc.).
• the process may proceed with instantiation of a tournament in step 604.
• Instantiation may involve the execution of one or more processing threads that will carry out the tournament as specified in the parameters. These threads may be executed by the tournament server 434, title server 432, individual consoles 402, or any other computing component in the system, and may be distributed across components (e.g., across multiple consoles 402) if desired.
• An instance of a tournament may be assigned its own unique tournament ID to help coordinate communications with clients participating in the tournament instance.
• the tournament may be assigned ' a leaderboard ID.
• the underlying online service e.g., XBOX LIVETM
• the leaderboard data structures may be a custom structure created to support each tournament instance by, for example, holding the qualification scores for the given tournament instance.
• These structures may be a defined database object storing identifications for various players, and one or more data values for a player's performance in a game (e.g., a player's race time, favorite car, score, win/loss record, total scores, opponents played, etc.), and game clients on consoles 402, tournament servers, and other devices may run SQL queries to the leaderboard data structure to obtain game session and tournament results.
• the leaderboard may be managed as a software process by a title server 432, a statistics server 424, or any other desired device in the system.
• different leaderboard structures may be used for different aspects of a tournament.
• a title server 432 may manage a qualification leaderboard, which accepts and process the qualification data for various tournament entrants (explained below), while a statistics server 424 may manage an overall scores leaderboard data structure to track player progress through the tournament.
• the process conducts the tournament in step 605.
• the actual execution of the tournament code to manage the tournament can occur in any server, such as on the Tournament Server 434, Title Server 432, and/or game consoles 402, as different tournaments will be conducted differently depending on the parameters chosen by the tournament administrator.
• Example tournaments are described further below with respect to Figures 8-9.
• the process may move to step 606, where the various game clients report their results to the server managing the tournament.
• Clients may be game code running on individual consoles 402, and each console may be responsible for reporting results to the tournament's server.
• Those results may include information regarding that particular console 402's player's performance, and may also include information regarding the performance of some or all of the other players that participated in the game session (e.g., a player's console may report not only that player's score, but the scores of all the other players in the game session as well — this multiple reported information can be compared against each other to confirm that no cheating has occurred, as further discussed below).
• this reporting may be coordinated among the consoles 402 such that one of the consoles participating in the session may be designated to report the results for everyone who played in the session, and the other consoles in the session may avoid duplicating that reporting.
• These results may also be reported to the server running the leaderboard, such as Statistics Server 424, using the secure communications required by that server.
• the separate reporting of the results to the leaderboard may help resolve anomalies in data that is reported to the tournament server, as will be addressed in greater detail below.
• the actual results may be in any form, depending on the type of game being played, and may generally report on accomplishments made by the players in the game session. For example, a first-person shooter type game may report the player's hit ratio, favorite weapon, etc., while a football game may report the win/loss outcome of the game, the score, and other player and/or game statistics. Games may use their own criteria in evaluating a player's performance and awarding points, rank, or other rewards, and such awards may be reported as the result.
• the tournament's server will be receiving tournament results from a variety of clients, and may receive multiple reports of each player's performance, inconsistencies and anomalies may occur.
• two consoles 402 may report inconsistent game outcomes for a single game, or for a single player in the game (e.g., each reporting a different winner, score, statistic, etc.).
• host migration e.g., games where one of the consoles participating in the session is designated as a local server host for the game, but where that console experiences a dropout or failure during the session and a different participating console takes over as host
• different consoles may report incomplete or otherwise inconsistent results.
• the tournament's server may compare results reported from different clients, and look for inconsistencies in the reported results. Additionally, the server may compare the results with a predefined data structure identifying normal or acceptable results to see if any reported results are beyond the bounds of what is considered normal or acceptable for the game session that was played. For example, in a typical football game, the game designer may decide that a score exceeding a predefined point total (e.g., more than 100 points) may be abnormal.
• a predefined point total e.g., more than 100 points
• step 608 an arbitration process analyzes the reported results to address and/or correct the anomaly.
• This arbitration process may involve querying the leaderboard server to retrieve individual player results, and performing the comparison. Or, the arbitration may involve reporting the apparent conflict to the server managing the leaderboard to which the tournament is assigned, and that server (e.g., the Statistics Server 424) may make its own comparison of- the results it received, and may run additional security and/or integrity checks to confirm which set of results is the genuine set.
• the arbitration process may access stored data identifying the relative credibility of the players involved.
• the process in step 609 may update the leaderboard data and correct the error.
• step 610 If no anomalies were detected, or after anomalies are corrected, the process may proceed to step 610 and check to see whether' the tournament should be concluded. Different tournaments may have different parameters defining how the tournament will end. For example, a Tournament Winner parameter may be used as described further below. In this step, the tournament process may compare the reported results, or the total results, with the parameter(s) defining a tournament winner, and decide whether a winner has been found and the tournament should conclude.
• step 605 may entail processing the next round in the tournament.
• step 611 the process may move to step 611 and conclude the tournament.
• This conclusion may involve the final tallying of scores and results from the leaderboard data object to determine player rankings and a tournament winner. Concluding a tournament will often involve the awarding of a prize to the winner and those finishing in predefined places (e.g., 2 nd , 3 rd , top ten, etc.).
• the prizes may be physical items provided by a tournament sponsor, or in-game virtual items such as a race car with particular design, special equipment or weapon, etc.
• Concluding the tournament may also include releasing the leaderboard ID to allow the tournament's leaderboard data object to be used for another tournament or another game, recording results in an archival database for future access, recording the high scores, etc.
• the process may then return to step 603 to await the next triggering event.
• the tournament trigger parameter may be defined to automatically create the tournament instance if one does not already exist, or immediately after a tournament concludes, such that the tournament may be continuously available for players.
• multiple instances of a tournament may exist simultaneously, if desired, so the instantiation of a second tournament need not depend on the conclusion of a prior instance. For example, the conclusion of a tournament instance may simply end the process, with separate processes occurring for each independent instance.
• FIG. 6 above referred to a step of defining tournament parameters, and to elaborate on that step, the following discussion addresses several example tournament ⁇ parameters that may be used:
• tournament Name a text string given by the administrator to identify the tournament to participants (e.g., the "Halo 2TM Slayfest Sponsored by Microsoft").
• tournament Owner an identification of an administrator for the tournament.
• the owner of a tournament may be the game developer, or a sponsor for the tournament.
• tournament Type an identification of a predefined type of tournament.
• the Tournament Server 434 may offer a number of predefined types of tournaments (e.g., single elimination, double elimination, others as described below, etc.) that may be accessed and customized by the administrator.
• Number of Tournament Entrants one or more values identifying a minimum, maximum, range, and/or preferred number of total player participants supported in the tournament. Some tournaments may be better suited for smaller-scales, while other formats may be more ideal for larger numbers of players.
• Number of Game Session Entrants one or more values identifying a minimum, maximum, range, and/or preferred number of players participating in each game session of the tournament.
• a game session may be defined by each game differently, and may refer to the basic unit of play in the game. This may differ depending on the game type. For example, a game of chess involves two entrants per session (e.g., a board), but a game of poker might involve five entrants per session (e.g., a table).
• Number of Rounds - one or more values identifying a minimum, maximum, range, and/or preferred number of rounds for the tournament.
• a round of a tournament may be defined to occur when each tournament entrant plays in one game session.
• Window Factor in some tournaments, players for a particular game session (e.g., a single "death match" involving a group of players) are grouped together based, at least in part, on how long it has been since the last time the players played against one another.
• the window factor may identify a time, which may be measured in terms of game sessions, rounds and/or tournaments, as well as seconds, minutes, hours, days, weeks, etc., that is required to pass before the players may play together again in the same game session of the tournament.
• a tournament might specify a window factor of two game sessions, which means before two players will be grouped together for a game, they must not have played against one another for at least two games.
• the use of a window factor may be particularly desirable for tournaments that have unlimited duration, or very large numbers of matches and players.
• the tournament instance may store a data table identifying the last time each pair of players in the tournament played against one another in the tournament.
• Rank Gap - in some tournaments players may be grouped together according to their score, rank, skill level, etc., and a rank gap may identify a range of ranks within which players are permitted to be grouped together. For example, a tournament might wish to only group players together if they are within 20 points of one another, or if their overall rankings are within a number of ranks (e.g., players no more than 10 ranks higher or lower than one another) or percentage (e.g., percentage of the total number of entrants in the tournament) of one another.
• a number of ranks e.g., players no more than 10 ranks higher or lower than one another
• percentage e.g., percentage of the total number of entrants in the tournament
• Scheduling Options identify the schedule in which the tournament will be played.
• a tournament may be continuous, in which a new round is begun automatically upon completion of a prior round, or according to a schedule.
• the ' schedule may indicate certain time frames in which rounds and game sessions may be conducted, such as a weekend-only tournament, a daily tournament, a specific date and/or time-of day, every 30 minutes, etc.
• New player factor one or more values identifying how new players' scores will be used in rankings. Point rankings are addressed in greater detail below, but for some tournaments, players are ranked according to data values that might not make a lot of statistical sense in the very beginning of the player's participation.
• a tournament that simply ranks players based on win/loss record might rank an undefeated 30-0 player the same as a new player with a 1-0 record (both are 100% winners), even though that new player might not truly deserve such a lofty rank.
• the tournament may use a new player factor, in which new player's scores are adjusted before used in ranking. So, for example, a new player's score might be reduced by 75% when only one game session's score is available, 50% when two game sessions' scores are available, 25% when three game sessions' scores are available, and not discounted at all if four or more game session's scores are available.
• the new player factor may identify a duration for the effect (e.g., number of rounds or game session), and an adjustment value for the effect (e.g., score discounting, point value addition/subtraction, etc.).
• Trigger event an identification of one or more events that will cause an instance of a tournament to be created. This may relate to the scheduling parameter described above, in which case a trigger event could simply be the time of day matching the schedule. Other types of triggers may also be used. For example, a tournament might automatically begin when a predetermined number of players have registered for the tournament, or upon entry of a command by one or more players already registered for the tournament (e.g., all registered players pressing a controller button to signal their readiness).
• tournament winner one or more values identifying the manner in which a tournament winner is determined. This may be a predetermined point total (e.g., the first player to reach 1000 points; or the person with the lowest total time in a race), a predetermined game event (e.g., the first player to accomplish a given objective within the game) or a ranking following a number of rounds (e.g., the player with the top ranking after the last round), etc.
• a predetermined point total e.g., the first player to reach 1000 points; or the person with the lowest total time in a race
• a predetermined game event e.g., the first player to accomplish a given objective within the game
• a ranking following a number of rounds e.g., the player with the top ranking after the last round
• Game-specific Options a number of other options that may be specific to particular games. These may include the identification of race tracks, weather conditions, car types, and point scoring for a racing game tournament, or the identification of map type, weapon loadout, and scoring for a first-person shooter tournament.
• the various tournament parameters may be stored in a tournament data package data structure 701, as shown in Figure 7.
• This data structure may include one or more round listings 702, where each round listing includes data for a segmemVstage/subset of rounds in a tournament.
• the example tournament 701 is a tournament including thirteen rounds, divided into three segments or stages.
• the round list may include a header portion 703 containing information for the particular list, such as an identification of the number of rounds in the list, and common settings, parameters, or themes for the rounds in the list (e.g., all races in list 1 will be on the "New York" race track, or all races in list 1 will occur with the weather set to "rainy")-
• the list may also include a plurality of individual round settings 704, containing parameters that will be used for each corresponding game session. For example, a first round setting might indicate that only low-power cars may be used for the first race, while the second round setting might indicate that only four-wheel drive cars may be used for the second race.
• the following pseudocode provides an example of a tournament data package:
• a tournament settings file may include multiple packages, each package may include multiple lists, and each list may include data values for the list's internal handle, a text value to be displayed, and one or more game codes for settings in the game.
• the game codes may be numeric values that correspond to entries in a table used by the game program for configuring the game. For example, a racing game may be provided with sixteen different race tracks, and the code '1011 ' may be a binary index into a table listing these tracks, identifying the 1 1 th track for use. Other codes may similarly be indices into other settings tables, such as tables for the weather, the car transmission, the direction on the track, type of car, etc. The following example illustrates how such a table may be configured:
• the values need not all be index codes into tables.
• a value for the maximum horsepower may simply include a numeric value for that maximum horsepower.
• Other data may also be included, such as the schedule data for the tournament instance (e.g., how frequently the tournament may instance, conditions, etc.), and for individual rounds within an instance (e.g., how often rounds occur).
• the schedule data for the tournament instance e.g., how frequently the tournament may instance, conditions, etc.
• individual rounds within an instance e.g., how often rounds occur.
• FIG 8 illustrates an example of another type of tournament that can be used. In the Figure 8 tournament, players begin in step 801 by registering to participate in the tournament. Registration may be done in a variety of ways.
• the player may log onto a server, such as Title Server 432 or Tournament Server 434, and query the server to obtain a list of available tournaments that are open for registration.
• the queried server may return a list of available tournaments, displaying the relevant tournament parameters (e.g., tournament name, number of rounds, number of entrants already registered, start time, prize, etc.), and the user may register for one by pressing a button on a controller with a particular tournament highlighted.
• players may join a tournament as a result of receiving an invitation sent by another player who has already registered for the tournament.
• Player registration 801 may continue until a predetermined time (e.g., elapsed time since tournament instance was created, time of day for scheduled tournament, elapsed time since first registrant, etc.) passes, or until a predetermined number of registrants have joined (e.g., the tournament parameter defining a maximum number of entrants).
• a predetermined time e.g., elapsed time since tournament instance was created, time of day for scheduled tournament, elapsed time since first registrant, etc.
• a predetermined number of registrants e.g., the tournament parameter defining a maximum number of entrants.
• the tournament may begin by initially placing the entrants in a random, or pseudo-random, order in step 802. This initial placement of ranking can be done in any desired way, such as alphabetically, or in order of registration, because the order will soon be rearranged.
• the process may determine the number of players to use in the game sessions for the next round. This may be done by consulting the Number of Game Session Entrants parameter described above, but may also involve calculations and adjustments based on the total number of entrants. For example, the process may perform calculations (e.g., dividing the total number of entrants by the various values in the Number of Game Session Entrants parameter) to find an ideal session size.
• An ideal session size may be a size that allows all sessions to have the same number of players, or for all sessions to differ in size by no more than one player (or any other predetermined value).
• the determination of a session size may also give preference to using larger (or smaller) numbers of players per game session, or by having a number that is closest to a preferred number specified in the parameter.
• the process may proceed to step 804, and begin filling a new group for the next game session.
• the highest ranking player who has not yet been assigned to a group is assigned to the new group.
• data for the next highest unassigned player e.g., a potential player
• step 807 a check is made to see if the potential player has recently played with any of the other players already assigned in the current group. This may be done, for example, by consulting a stored table keeping track of the last time each pair of entrants played together in a game session.
• step 808 If the potential player has not played too recently with one of the other players in the group, then the potential player is added to the group in step 808. On the other hand, if the potential player has played too recently, then the process skips the potential player and moves on to step 809, where a check is made to see if the current group is full. If the group is not full, the process returns to step 806 to retrieve information for the next unassigned player. If the group is full, the process moves to step 810 to see if there are remaining unassigned players. If there are, the process returns to step 804 to begin filling a new group. One optional step, not shown, may be taken if the last few unassigned players all played too recently with one another.
• the process may simply waive the Window Factor criteria for these players, and group them into one or more final groups.
• the system may adjust the window factor by a predetermined amount (e.g., reducing it by 1), and begin the process anew.
• step 81 1 If all players have been assigned to groups, then the process moves to step 81 1, where the players will then play a game session.
• the game session is completed (e.g., the players finish running a race, complete a football game, finish a deathmatch, etc.)
• the process moves to step 812 in which players are assigned points based on their performance in the game session. These points may vary depending on game type, with different points being awarded for different game accomplishments. Various types of scoring mechanisms may be used.
• the tournament server may record game scores for accomplishments made by each player during the most recent game session, cumulative game scores to tally the points accumulated by each player thus far in the tournament, match scores that take into account the number and/or ranking of other players played against (e.g., a point for each player beaten in a given session), and an available cumulative score indicating the maximum number of points the player could have accumulated thus far in the tournament.
• the server or console performing the point assignment may also perform calculations for ranking purposes.
• the tournament process may calculate a scoring percentage indicating the percentage of the maximum possible score that the player has attained (e.g., by dividing the player's cumulative game score by the available cumulative score).
• the process may apply the New Player Factor parameter to adjust a new player's score before it is used to re-rank the player (in the following step).
• step 813 the process may reorder, or re-rank, the various players based on their total scores and/or their scoring percentage as discussed above.
• the process may check in step 814 to see if more rounds are to be played. This determination may be based on whether the players have played the requisite number of rounds, or if a player has achieved some other condition for winning, as specified in the tournament parameters. If more rounds are to be played, the process may return to step 804 to regroup the players. If no more rounds need to be played, the process may move to step 815 and end the tournament, as described above with respect to Figure 6.
• Figure 8c illustrates an example progression of player rankings, groupings and reranking that may occur in the tournament process of Figures 8a and 8b.
• the players may be ranked for round 1 as shown on the left, and grouped into three groups (four players per group), and then reranked as shown on the right based on their performance in round 1.
• the four highest reranked players are Players A, E I and B, but since B had just played with Player A in the previous round, the process may skip Player B and add the next highest player, Player F, to Group 1.
• Player B may then be placed in Group 2 for the second round.
• FIG 8c shows the final player, Player L, being relegated to a new group because that player had played too recently with Player K of the second round's Group 3.
• the process may allow one or more groups at the bottom of the list to play one another regardless of Window Factor restrictions. For example, Player L may simply be matched into Group 3, despite having played recently with Player K. Alternatively, the players at the bottom who cannot be matched may be dropped from the tournament.
• one or more groups appearing at the bottom of the rankings may simply be dropped from the tournament, thereby narrowing the field with passing rounds.
• the dropping may begin after the passage of a predetermined number of rounds (e.g., two rounds), to allow for at least some preliminary ranking so that the dropped groups are more likely to contain the weakest players anyway.
• the Rank Gap parameter may be used as a second check in steps 807 and 808 to add a player to a group only if the new player is close enough in rank to the other players in the group.
• the tournament server may also place different priorities on how strict the Rank Gap and Window Factor parameters are to be used, such as requiring the waiver of one or both requirements if the resulting number of required groups would exceed a predetermined threshold, or if there are not enough players to fill groups that meet the parameter's requirements.
• the server priorities may waive one priority before waiving another.
• the process may allow for the additional registration of new players after the tournament has started, and the dropping out (e.g., quitting) of players that originally registered.
• a newly-registered player may simply be added to the pool of available players for the next round, such as before step 803.
• there may be limitations on when new players are permitted to join e.g., only after the first predetermined number of rounds, or prohibited in the final predetermined number of rounds, etc.).
• the new player may be given a random rank at the outset (as with the initial placement in step 802), or alternatively the player may automatically be ranked in the middle, or at the bottom, of the list.
• the New Player Factor parameter may be used to adjust a new player's score to ensure that the new player does not quickly get in over his/her head in the rankings after playing a few rounds. For example, if the scoring percentages are used and a new player wins his/her first round, a New Player Factor might multiply the player's scoring percentage by 0.25 when the player has only played one round, so that a new player will not ascend too quickly after winning one round. Similarly, the New Player Factor may vary depending on how many rounds the player has played (e.g., using 0.5 after two rounds, and 0.75 after three, and 1.0 after four rounds), so that the player's full score is credited after a predetermined number of rounds.
• the Figure 8 tournament process may be used to accommodate large numbers of players, and can be used to run a continuous tournament (e.g., one in which there is no defined number of rounds).
• Figure 9 illustrates another tournament process that may be used in addition to that of Figure 8.
• a leaderboard qualification period may be used to initially qualify and seed the tournament entrants.
• the process begins at step 901 , where a tournament creator or administrator (which may be a game developer, player, etc., as discussed above) initially defines the parameters of the tournament.
• the parameters may be similar to those discussed above, but other parameters may also be used.
• the tournament may use an elimination bracket structure in which winners advance and losers drop out, and such tournaments may include a separate parameter identifying the number of participants to appear in the final, championship, game, and the number of winners that advance from earlier-round games.
• the tournament parameters may also identify the number of tournament levels that will be used.
• a tournament may be defined as having three levels (e.g., "Gold,” “Silver” and “Bronze") to allow the highest, second highest, and third highest ranking group of players compete with one another. Each of these levels may be operated as individual instances of the tournament, allowing players of different caliber to compete in their own tournaments.
• the separate instances may be initiated, for example, after qualification is completed and the entrants are divided into ranked groups based on their qualification.
• the tournament may also include scheduling information for the qualification round(s), such as the opening time/date and duration.
• the tournament may also include a Challenge Definition parameter that sets forth the type of challenge that will be used to qualify participants.
• a Challenge Definition data structure may generally indicate a type of feat that a player must accomplish in order to qualify for the tournament, and may vary depending on the game.
• the Challenge Definition may specify one or more game settings for the qualifying challenge, such as a location setting (e.g., race track for a racing game, a battlefield map for a war game, a game level or stage, etc.), difficulty setting (e.g., easy, medium, hard, etc.), game condition (e.g., type of car for a race, available weapons on a map, weather setting), etc.
• the Challenge Definition is not limited to just one event. Instead, the definition may specify a number of qualifying events in an ordered list, such as a sequence of different races or stages, with different conditions.
• the Challenge Definition may include a data file that can be downloaded to a game console 402 to automatically configure a game title program on the console to participate in the challenge.
• a race game's Challenge Definition parameter requires that a 4-lap race be run on the Website Seca racetrack on a sunny day, using rear-wheel drive cars having no more than 200 horsepower, and against 5 computer- controlled (AI) opponents set on a race game's "medium" difficulty setting
• the tournament's server may include a tournament challenge download file that will, when downloaded to the player's console, automatically configure the game running on the console to run the type of race specified in the download file.
• the download file may also be used by the game, running on the console 402, to restrict the player's choice of cars to those permitted by the Challenge Definition.
• the tournament's server may then begin to execute a process that will handle the tournament.
• the process may allocate (or otherwise reserve) storage for a leaderboard data structure that will be used to hold players' qualification results, and the leaderboard's ID may be one of the parameters defined in step 901.
• the leaderboard ID may include a name or handle for the data structure, and a memory address location indicating where it is stored and how it can be retrieved.
• the leaderboard IDs may be used for scoring arbitration.
• a computer process may then announce the tournament to players in step 902.
• the announcement may occur via electronic communication, such as e-mail, SMS, etc., and may include sending electronic messages to game consoles 402. Announcements may also be made using other forms of communication, such as television advertising, radio, telephone, magazines, etc.
• the announcement informs players of the parameters of the tournament, the type of challenge that must be accomplished to qualify for the tournament (e.g., the Challenge Definition), and the time period for the qualification period (e.g., start time and end time).
• the process opens the qualification period at step 903. During this period, players may download a Challenge Definition configuration file, if available, and play the requisite challenge (e.g., run the specified race).
• the game console 402 may record a player's progress and accomplishment (e.g., race time), and may report a score through secure transmission back to the tournament's server, such as Tournament Server 434, for inclusion on the tournament's leaderboard. In addition to the secure transmission checking discussed above, this reported score may also undergo a verification process to help further avoid having fraudulent scores posted.
• the verification process may include a comparison of a reported score with a predetermined score limit or maximum expected score (which may be additional tournament parameters defined above), or with results reported by a different game console.
• the server may query the leaderboard to determine a tournament ranking based on the player's result and other players' qualification scores.
• the server may send a message to the player informing the player of how well he/she performed (e.g., "You have logged the 75 th fastest time for this challenge”).
• the message may also inform the player as to what the player has qualified for (e.g., "Your score qualifies you for the gold level tournament," or "Your score qualifies you for the 10 th seed”). If the player desires, the player may try the qualification event again and post another score, hoping to improve his/her position.
• the server may obtain an identity (e.g., login identity) of the player posting a score (e.g., transmitted with the score), and check to see if the player has previously posted a qualification score. If the player has, the server process may automatically replace the prior score with the newer one, or it may do so only if the newer score would result in a higher rank than the old one, or if the user requested to replace an old score with a newer one when he/she submitted the score. Alternatively, players need not be given unlimited opportunity to post qualifying scores. For example, the tournament may restrict each user to just one qualification entry, or a limited predetermined number of qualification entries.
• the player may be given an opportunity to have a game session score ignored (e.g., treating it as a practice round) instead of being posted. Additionally, the system may display an option to users to purchase additional qualification attempts, and users may have a predetermined account (e.g., a credit card account, or a subscription, account) debited for the cost of having another try at posting a higher qualification score.
• a predetermined account e.g., a credit card account, or a subscription, account
• the tournament server process may automatically notify such players when their ranking is changed, or if their ranking changes by a predetermined amount (e.g., a number of places, a percentage of participants, etc.), or if their ranking drops them out of qualification for a particular tournament instance (e.g., if their prior qualification used to qualify for the "Gold" tournament, but now only qualifies for the "Silver” tournament).
• the notification may be in any communication, similar to the announcement, and may be an electronic message sent to the player's console 402. The message may appear as an in-game communication on the player's console, displayed using a game program's user interface. Other notifications, such as e-mail to a computer, may also be used.
• the actual type of notification, and conditions on which they are sent, may be specified as additional tournament parameters.
• the tournament server may then consult the leaderboard data structure in step 904, and determine how many players have actually qualified for the tournament by comparing the posted results with the requirements for qualification.
• the requirements for qualification may be specified in, or derived from, the tournament parameters.
• An example of such a derivation may use a calculation based on entered tournament parameters, such as the desired number of players per game (P), the number of players to be in the final game (P F ) 5 the number of winners who should advance from each game (W) (e.g., 2, 3, 4, etc. players advance from each game), and the number of rounds desired (R), to calculate the total number of players (P T ) that can participate in one instance of a tournament:
• the tournament process may perform the above calculation, and then consult the leaderboard to accept the top PT number of players as qualified for the tournament. Of course, this calculation may have been performed earlier, such as in the tournament definition step 901 and/or qualification period 903. If multiple tournament instances are supported (e.g., as indicated by the tournament parameters), then the tournament process may accept the next PT entries in the leaderboard as qualifying for the next tournament, and so on until the total number of tournament instances has been filled, or until there are no more unassigned entries in the leaderboard. In this manner, the tournament process divides the qualifiers (or entrants) into the various tournament levels.
• the example calculation above is not limited to determining a total number of players per tournament. Instead, any one of the variables may be calculated based on other provided variables. So, for example, if a tournament administrator decided to leave the number of rounds (R) open, the equation may be rearranged to calculate that value based on the other values (e.g., conduct as many rounds as it takes to have a tournament for all players and meeting the specified player-per-game and winner-per-game values). Additionally, a tournament fill ratio may be defined in the parameters (e.g., 20%) to require that a certain number or percentage of posted scores will qualify for a tournament.
• the tournament process may then schedule the various tournament(s) and tournament round(s), based on the calculated values (if any) and any schedule parameters set in the tournament parameters.
• the process may also perform seeding in step 906 to fill tournament brackets in elimination tournaments. This seeding may be done dynamically using the grouping approach described above to keep players of close skill playing one another each round (e.g., the top X players play in one game, the next X players play in a second game, etc., with seeding occurring after each round and as late as possible), or the seeding may be done to try and ensure that the higher-seeded players do not face other high-seed players until the later or final rounds.
• the seeding process may then step from opening match to opening match, placing the top seeded players in numbers sufficient to fill the expected winners, and then filling out the rest of the matches with the lower seed players.
• This kind of seeding may be statically done, in which case players carry their seed with them throughout the tournament, and are not reseeded in between rounds.
• this seeding may be conducted anew after each round of play, where only those players that are present and ready to play (e.g., have checked in with the server handling the tournament instance). So, for example, if a number of players quit or drop out after the first round, the tournament may be re-seeded for the second round to minimize idle players (e.g., players whose opponents, according to the original seeding, are no longer playing).
• Figure 10a illustrates an example of a statically-seeded bracket that may be generated when the tournament server follows the process shown in Figure 10b.
• the end result of the Figure 10b process is to identify the opening round bracket matchups, the overall number of rounds, and the arrangement of the matches (e.g., which earlier matches supply a later match with its competitors).
• the process begins in step 1001 by considering the final round. The process may consult the tournament parameters to determine how many competitors are to be in the final round, and may fill the final round. In step 1002, the final round may be filled with the top seeds.
• the final round has been defined to have eight competitors, so the top eight seeded players are presumed to appear in the final round. Again, this is just a presumption for purposes of seeding the opening rounds, as the top seeded players are not required to actually survive to the final round.
• step 1003 the system may check to see how many prior feeder matches are needed in the prior round (e.g., the final round) to fill the current round (e.g., the final round). For example, if the final round needs eight players, and the tournament parameters indicate that four players advance from each match, then the earlier round (therion round) would need two matches to provide those eight players.
• step 1004 the players from the current round are distributed across the various matches needed in the earlier round.
• step 1005 the remainder of the matches in the earlier round are filled with the next highest available seeded players.
• step 1006 a check may be made to determine whether all entrants in the tournament have been placed. If they have not, then another earlier round will be needed in the tournament.
• the process may, in step 1007, then shift the focus to the next earliest round, and return to step 1003 to perform the same steps to fill the matches of the earlier round. So for example, the system may set the "current round" in step 1007 to be the nominee round, and may return to step 1003 and begin to fill the brackets for the next earlier round (e.g., the quarterfinal round).
• the process may continue until all entrants have been placed, and the last round addressed in the process provides the opening round seedings.
• Figure 11 illustrates another example of a tournament in which six players appear in the final round, nine players play in the prior rounds' matches, and three players advance from each prior match. The earliest rounds indicate the end result of the seeding process.
• FIG. 12 illustrates an example user interface map that may be used, for example, in a game to access tournaments of the type shown in Figures 8a-8b and 9.
• the main menu 1201 of the console may offer a number of tournament options, including a tournaments page option.
• the tournaments page 1202, displayed in response to selecting that option, may include a menu of tournament options.
• the tournaments menu 1202 may display a list of tournaments for which the player has already registered, the player's qualification rank, the number of entrants, the tournament's current status (e.g., registration, qualifying, round X, etc.).
• the tournaments menu 1202 may also include selectable options for entering one of the listed tournaments, finding a tournament and for creating a tournament. Upon choosing one of the listed tournaments, the user may be presented with a tournament lobby screen 1203 for the selected tournament.
• the tournament lobby screen 1203 may display additional information for the selected tournament, such as current status, the player's next opponent, status of opponents, etc.
• the tournament lobby screen 1203 may include additional menu options for playing a game in the tournament, viewing a game history for prior matches in the tournament, etc.
• the game console may display a play game screen 1204 to begin playing a round or match in the tournament, or a game history screen 1205 to display information regarding a player's prior performance in the tournament. This information may include statistics for players, opponents, teams, etc.
• the history screen 1205 may also display overall player online performance across multiple tournaments and game types, such as by querying data from a leaderboard on Statistic Server 426.
• the tournament lobby screen 1203 may also include an entrant list option, selection of which may display entrant list 1206.
• the entrant list screen 1206 may display identification and statistical information regarding entrants in the tournament, entrants who are scheduled to play in the next round, entrants who played in the previous round, etc.
• the system may display a report results screen 1207 to display the outcome of the match. This may include statistics regarding players' performance in the match that was just played.
• players may also be given the option of searching for tournaments.
• the player may view a find tournaments screen, which may include prompts for the user to enter, or select, search criteria that may be used to locate tournaments on the online system, such as those running on one or more Tournament Servers 434, or those using the leaderboards.
• the criteria may include game title, tournament name, game type, tournament type, tournament host, or any other desired search criteria.
• the system may display a list of tournaments for this user, indicating qualification details (e.g., whether the user qualified, the entrant qualifier scores, etc.) and a schedule of when the tournaments are set to occur.
• the tournament menu 1202 may also include an option to allow players to create new tournaments.
• the user may be shown a create tournament screen 1209, which may prompt the user for criteria to define a new tournament.
• the criteria may include any of the features described above, such as the tournament parameters, game title, etc.
• One or more additional game settings screens 1210 may also be used for this purpose.
• the tournament menu 1202 may also include a leaderboard qualified tournament option, and the selection of this option may display a leaderboard screen 1211.
• the leaderboard screen 121 1 may list leaderboard tournaments, and contain additional data regarding leaderboard qualified tournaments, such as the name, ID, current state, current challenge, challenge/qualification period, etc.
• the leaderboard screen 1211 may include an option to display additional explanation and detail on the qualification for a particular displayed tournament.
• the qualification details screen 1212 may include additional description to explain how the player may qualify (e.g., "Race the Website Seca race track using a 4WD car with less than 301 Hp, and post one of the top 150 times to qualify for the Gold level tournament!).
• the user may choose to make a qualifying attempt, resulting in the game screen 1213, and after the attempt the user may view a report results screen 1214 displaying information regarding the player's qualification attempt.
• the results screen 1214 may also display information retrieved from a leaderboard showing how the player's resulting score ranks among others, and information identifying whether the player qualified for the tournament
• the console may display an elimination details screen 1215 for the tournament.
• the elimination details screen 1215 may list the tournament status, the player's standing/ranking, and if the player is still in the tournament, the next scheduled game for the tournament.
• the player may select a corresponding option from the details screen 1215 and enter the tournament lobby 1216, where the player may await the entry of his/her opponents for the next round. From the lobby 1216, the player may choose to view the bracket 1217 for the tournament, the game settings and parameters 1218, or statistics 1219 regarding the player, his/her teammates, friends, other competitors in the tournament, and upcoming opponents.
• references to a player above may refer to a single person, or it may refer to a team of people playing their games together.
• Some tournaments may support teams, or clans, by allowing the various players to participate together (e.g., in a single race) as a team. Scores for team members may be aggregated for ranking comparison.
• Another possible modification deals with dropouts and no-shows for tournament participants. If a player enters a tournament by registering and/or qualifying, but fails to complete the tournament (e.g., dropping out after starting, or never showing up at the scheduled time, etc.), that player can be treated as if the player had accumulated a zero score, or a loss.
• the various screens shown in Figure 12 and features described herein may be used for local, non-networked play as well.
• a multiplayer tournament may be hosted by a single console, and the various features implemented by the console.
• the features described above are preferably encoded in computer software as executable instructions that can be executed on a computing device, such as a personal computer or video game console, to result in the display of the screens shown in the figures.
• the executable instructions may be stored on a computer-readable medium, such as one or more computer disks, RAMs, CD-ROMs, DVDs, game cartridges, etc.
• a computer-readable medium such as one or more computer disks, RAMs, CD-ROMs, DVDs, game cartridges, etc.

Applications Claiming Priority (2)

Publications (2)

Family

ID=38369333

Family Applications (1)

Country Status (7)

Families Citing this family (90)

Citations (10)

Family Cites Families (38)

• 2006
  • 2006-02-16 US US11/354,982 patent/US20070191101A1/en not_active Abandoned
• 2007
  • 2007-01-20 KR KR1020087019387A patent/KR20080094031A/ko not_active IP Right Cessation
  • 2007-01-20 AU AU2007218066A patent/AU2007218066B2/en not_active Ceased
  • 2007-01-20 WO PCT/US2007/001612 patent/WO2007097850A2/en active Application Filing
  • 2007-01-20 JP JP2008555239A patent/JP2009526603A/ja not_active Withdrawn
  • 2007-01-20 EP EP07716874A patent/EP1989673A4/de not_active Withdrawn
  • 2007-01-20 CA CA002637169A patent/CA2637169A1/en not_active Withdrawn

Patent Citations (10)

Non-Patent Citations (1)

Also Published As

Similar Documents

Legal Events