WO2007044908A2

WO2007044908A2 - Method and apparatus for finding desirable multi-player games for players

Info

Publication number: WO2007044908A2
Application number: PCT/US2006/040096
Authority: WO
Inventors: Paul Abbassi; Robert Riley
Original assignee: Thq Wireless Inc.
Priority date: 2005-10-11
Filing date: 2006-10-11
Publication date: 2007-04-19
Also published as: JP2009511200A; WO2007044908A3; EP1948335A2; EP1948335A4

Abstract

A method and system for finding desirable multi-player games for players are described. In one embodiment, the method includes finding, based on business rules, one or more multi-player game sessions that match preferences of a potential player, and notifying the potential player of the matching multi-player game sessions.

Description

METHOD AND APPARATUS FOR FINDING DESIRABLE MULTI-PLAYER

GAMES FOR PLAYERS

FIELD OF THE INVENTION

[0001] The present invention relates to wireless games; more particularly, the present invention relates to finding desirable multi-player game sessions and games for players.

BACKGROUND OF THE INVENTION

[0002] Electronic games have become a major part of the entertainment industry in today's modern world. The playing of electronic games on stand-alone terminals has long been popular. However, in recent years these games have migrated into a network environment, including a wireless network environment.

[0003] As networked games become more popular, the number of users seeking the right game server for online multi-player games increases. Currently, the users have to scroll down long lists of game servers to find the desired mix of gameplay. Often the users end up jumping into games that are not enjoyable to play because player skill levels are too lopsided or gameplay references are mismatched.

[0004] Traditional search engines are unable to solve the above problems because they lack a robust model to deal with complex criteria, hierarchical relationships and multiplicity of user preferences.

SUMMARY OF THE INVENTION

[0005] A method and system for finding desirable multi-player game sessions for players are described. According to one aspect, the method includes finding, based on business rules, one or more multi-player game sessions that match preferences of a potential player, and notifying the potential player of the matching multi-player game sessions.

[0006] Other features of the present invention will be apparent from the accompanying drawings and from the detailed description that follows.

BRIEF DESCRIPTION OF THE DRAWINGS

[0007] The present invention will be understood more fully from the detailed description given below and from the accompanying drawings of various embodiments of the invention, which, however, should not be taken to limit the invention to the specific embodiments, but are for explanation and understanding only.

[0008] Figure 1 is a block diagram of one embodiment of a system in which embodiments of the present invention may operate.

[0009] Figure 2A is a block diagram of one embodiment of a game management system.

[0010] Figure 2B is a block diagram of one embodiment of a gaming data module.

[0011] Figure 3 is a block diagram of one embodiment of a game matching engine.

[0012] Figure 4 is a flow diagram of one embodiment of a process for finding a desirable multi-player game session for a user.

[0013] Figure 5 is a flow diagram of one embodiment of a process for inferring gaming preferences of a user.

[0014] Figure 6 is a flow diagram of one embodiment of a process for maintaining attributes of multi-player games.

[0015] Figure 7 A is a flow diagram of one embodiment of a process for inviting new players to participate in active multi-player game sessions.

[0016] Figure 7B is a flow diagram of one embodiment of a process for seeking players for a multi-player game lobby.

[0017] Figure 8 is a flow diagram of one embodiment of a process for supporting revenge games.

[0018] Figure 9 is a flow diagram of one embodiment of a process for providing alerts to users.

[0019] Figure 10 is a flow diagram of one embodiment of a process for facilitating multi-player game tournaments.

[0020] Figure 11 is a block diagram of an exemplary computer system.

DETAILED DESCRIPTION OF THE PRESENT INVENTION

[0021] A method and apparatus for finding desirable multi-player games for players are described, hi the following description, numerous details are set forth. It will be apparent, however, to one skilled in the art, that the present invention may be practiced without these specific details. In other instances, well-known structures and devices are shown in block diagram form, rather than in detail, in order to avoid obscuring the present invention.

[0022] Some portions of the detailed descriptions which follow are presented in terms of algorithms and symbolic representations of operations on data bits within a computer memory. These algorithmic descriptions and representations are the means used by those skilled in the data processing arts to most effectively convey the substance of their work to others skilled in the art. An algorithm is here, and generally, conceived to be a self-consistent sequence of steps leading to a desired result. The steps are those requiring physical manipulations of physical quantities. Usually, though not necessarily, these quantities take the form of electrical or magnetic signals capable of being stored, transferred, combined, compared, and otherwise manipulated. It has proven convenient at times, principally for reasons of common usage, to refer to these signals as bits, values, elements, symbols, characters, terms, numbers, or the like.

[0023] It should be borne in mind, however, that all of these and similar terms are to be associated with the appropriate physical quantities and are merely convenient labels applied to these quantities. Unless specifically stated otherwise as apparent from the following discussion, it is appreciated that throughout the description, discussions utilizing terms such as "processing" or "computing" or "calculating" or "determining" or "displaying" or the like, refer to the action and processes of a computer system, or similar electronic computing device, that manipulates and transforms data represented as physical (electronic) quantities within the computer system's registers and memories into other data similarly represented as physical quantities within the computer system memories or registers or other such information storage, transmission or display devices.

[0024] The present invention also relates to apparatus for performing the operations herein. This apparatus may be specially constructed for the required purposes, or it may comprise a general purpose computer selectively activated or reconfigured by a computer program stored in the computer. Such a computer program may be stored in a computer readable storage medium, such as, but is not limited to, any type of disk including floppy disks, optical disks, CD-ROMs, and magnetic-optical disks, read-only memories (ROMs), random access memories (RAMs), EPROMs, EEPROMs, magnetic or optical cards, or any type of media suitable for storing electronic instructions, and each coupled to a computer system bus.

[0025] The algorithms and displays presented herein are not inherently related to any particular computer or other apparatus. Various general purpose systems may be used with programs in accordance with the teachings herein, or it may prove convenient to construct more specialized apparatus to perform the required method steps. The required structure for a variety of these systems will appear from the description below. In addition, the present invention is not described with reference to any particular programming language. It will be appreciated that a variety of programming languages may be used to implement the teachings of the invention as described herein.

[0026] A machine-readable medium includes any mechanism for storing or transmitting information in a form readable by a machine (e.g., a computer). For example, a machine-readable medium includes read only memory ("ROM"); random access memory ("RAM"); magnetic disk storage media; optical storage media; flash memory devices; electrical, optical, acoustical or other form of propagated signals (e.g., carrier waves, infrared signals, digital signals, etc.); etc.

Overview

[0027] Embodiments of the present invention enable users to quickly and easily find multi-player games that they want to play. Figure 1 is a block diagram of one embodiment of a system 100, in which embodiments of the present invention may operate. The system 100 includes a wide area network (e.g., Internet) 104, a wireless network 106, client devices 108 and 110, and a game management system 102.

[0028] The client devices 108 are mobile devices coupled to the game management system 102 via the wireless network 106. Mobile devices 108 are interactive two-way communication devices that allow their users to play wireless games. For example, the mobile devices 108 may be wireless telephones, palm-sized computing devices, personal digital assistants (PDAs), etc. Such two-way communication devices may communicate wirelessly with the game management system 102 via the wireless network 106. Communication between the game management system 102 and the mobile devices 108 is provided by corresponding wireless carriers (e.g., Cingular®, Sprint PCS®, Verizon®, etc.).

[0029] The client devices 110 are coupled to the game management system 102 via the wide area network 104 (e.g., Internet). The client devices 108 are interactive two-way communication devices that allow their users to play console games, web games or personal computer (PC) games. For example, the client devices 110 may be PC systems, personal digital assistants (PD A)s, play stations, consumer electronic devices, etc.

[0030] In one embodiment, client devices 108 and 110 host client-based applications such as gaming data modules 112 that collect data associated with games played on relevant client devices 108 and 110, and provide this data to the game management system 120. In one embodiment, the gaming data module 112 is configured based on the platform of a relevant client device 108 or 110. In one embodiment, the gaming data module 112 is integrated into a game played on a relevant client device 108 or 110. In another embodiment, the gaming data module 112 is an independent application residing on a relevant client device 108 or 110.

[0031] The game management system 102 provides services to deploy, manage and support games on the client devices 108 and 110, thus providing game services across different device platforms (e.g., PC platforms, wireless device platforms, web-based hand-held device platforms, game console platforms, etc.). The game management system 102 may be maintained by a game manufacturer, a game publisher, a network communication carrier, or any other provider of game services (any other entity controlling user access to electronic games).

[0032] In one embodiment, the game management system 102 cooperates with the gaming data modules 112 to enable two-way messaging with applications on the client devices 108 and 110. In one embodiment, the gaming data modules 112 forward messages (and store messages when the client device is disconnected from the network) to the game management system 102 and support real-time in-game features (e.g., in- game advertisement, multi-player gameplay, user registration, game metrics collection, etc.) facilitated by the game management system 102.

[0033] In one embodiment, scalability of the game management system 102 is provided by utilizing multiple servers. For example, each type of client application may be associated with one or more designated servers. Ih addition, for wireless client applications, each wireless carrier may be associated with one or more designated servers. For example, each carrier may be associated with a designated database server (e.g., a 4-CPU database server) and accompanying application servers (e.g., six application servers). Alternatively, some wireless carriers may share servers. If any server or group of servers performs inadequately, the system is reconfigured to provide services for users of an associated carrier by another group of servers.

[0034] The gaming data modules 112 and the game management system 102 may operate in a similar manner for applications other than games. Examples of such applications may include data services (e.g., providing live statistics on sports events), ring tones, screensavers, etc.

Game Management System

[0035] Figure 2A is a block diagram of one embodiment of a game management system 200. In one embodiment, the game management system 200 supports mobile or wireless games. Li another embodiment, the game management system 200 also supports games of other types such as PC games, web games and console games.

[0036] The game management system 200 may include a user registration module 202, a game usage controller 204, a game metrics collector 206, a multi-player gameplay supporter 208, an advertising module 210, a billing module 212, a game download module 214, a versioning module 222, a user account manager 224, a game matching engine 226, a user database 216, a game metrics database 218, a billing database 220, and/or various other modules not shown in Figure 2A.

[0037] The user registration module 202 is responsible for registering new users, storing identifying information of new users in the user database 216, and facilitating login of existing users. A user registration process may be invoked upon a user activation of a registration link on a web site associated with the game management system 200, upon a user request to download a game to the user's client device 108 or 110, upon a user attempt to begin playing a new game, or upon any other event initiated by the user. The user identifying information may include, for example, a user ID, a password, an email address, a unique code associated with a game product selected by the user, a handset ID (for wireless devices, etc.). It should be noted that the term "game product" refers to a specific game product (e.g., Red Faction or Halo) available to various users, and the term "game" refers to a game product's instance owned by a specific user.

[0038] The game usage controller 204 is responsible for receiving information associated with a user purchase of a new game, storing this information in the user database 216, and controlling the usage of this game on various user devices. The game usage controller 204 may receive information associated with the purchase of a new game from the billing module 210 when a purchase is facilitated by the game management system 200, from the user registration module 202 when the user registers a game with the game management system, or from an external system facilitating the purchase of a new game. In one embodiment, if the user purchases a new game for a specific mobile device 106, the game usage controller 204 records the purchase in the user database 216. Subsequently, when the user selects this game for a different mobile device, the game usage controller 204 finds the record associated with the selected game in the user database 216 and causes this game to be available to the user for playing on the other mobile device. The game usage controller 204 may also cause, in one embodiment, a game purchased for a mobile device 106 to be available to the user for playing on a PC, a hand-held computer, a game console or any other device 108. Similarly, the game usage controller 204 may cause, in one embodiment, a game purchased for a non-mobile device 108 to be available to the user for playing on mobile devices 106. In addition, the game usage controller 204 may allow the user to re- download the game to the same client device if the user has previously erased the game from the client device (e.g., due to space considerations).

[0039] In one embodiment, the game usage controller 204 causes a game to be available to a user if the user satisfies one or more game unlocking criteria (e.g., the number of game unlocks does not exceed a predefined threshold). In one embodiment, the game usage controller 204 can also cause a game to be unavailable or no longer available to the user upon determining that the user satisfies one or more game locking criteria (e.g., the user is delinquent).

[0040] The game metrics collector 206 is responsible for receiving game metrics from players of various games (e.g., various single and multi-player games) and storing the game metrics in the game metrics database 218. The game metrics may specify, for example, the version of a played game product, the score of the game, how long the game was played, etc. The game metrics may be used by game producers and publishers to analyze gameplay and conduct data mining. The game metrics controller 206 may also be responsible for producing reports based on game metrics (e.g., reports by title and carrier to evaluate the performance of game products by titles and genre).

[0041] The multi-player gameplay supporter 208 is responsible for providing multi-player features across different device platforms (e.g., PC platforms, wireless device platforms, web-based hand-held device platforms, game console platforms, etc.). The multi-player features may include, for example, managing player turns in a multi- player game session, supporting exchange of in-game chat messages, maintaining lobbies for different game products to allow game players to exchange information, search for available players/teams and times, set up head-to-head games, etc. A multi-player game session is a session currently active for a multi-player game product that allows a simultaneous participation of players who previously registered as users of this multi- player game product. In one embodiment, the multi-player gameplay supporter 208 is also responsible for comparing the scores of different users, returning a list of top scores to the client devices, and notifying a user if he or she earned a high score. In addition, the multi-player gameplay supporter 208 may rank game players (e.g., based on losses, wins and difficulty of multi-player games), provide player rankings to the users upon their requests, initiate (or allow users to initiate) tournaments and define (or allow users to define) criteria for participation in tournaments.

[0042] In one embodiment, the multi-player gameplay supporter 208 is further responsible for periodically checking whether each player is still connected to the network. In addition, a threshold can be set to mark a game- validation point at which the multi-player game will be treated differently if any player is dropped from the network. This feature allows differentiating between players that are attempting to prematurely disconnect when their scores are unfavorable and players that are disconnected due to network problems.

[0043] The advertising module 210 is responsible for maintaining advertisements (both text and graphics) and facilitating in-game delivery of advertisements to client devices (e.g., using client-based modules as described above). In one embodiment, advertisements are selected for delivery to a client device based on the user's profile data captured by the client-based module, game metrics associated with the user, and/or a set of criteria (e.g., a user that played game A 10 times in the last 10 days should receive ads for a new version of game product A), hi one embodiment, the advertisements are assigned to a carousel and are rotated by title, impression count or time schedule, and a client device type. Title-based advertising may be overridden by a carrier-specific promotion, hi one embodiment, advertisements are retrieved upon the start of the game (e.g., the client-based module sends a start game message, and the advertising module 210 responds by sending a text and/or graphic ad). In one embodiment, the advertising module 210 issues a new version alert message if a newer version of the game product played by the user exists (e.g., the client-based module sends a start game message with the current version of the game product, and the advertising module 210 responds by sending a new version alert message).

[0044] In one embodiment, the advertising module 210 allows a user to browse a list of game products and displays a description and one or more screen shots for a game product selected by the user from the list. Li another embodiment, the advertising module 210 facilitates a download of a demo version of the game product selected from the list. A demo version is a version providing only partial (restricted) game functionality. For example, the demo version may only allow the user to play the game for a limited time period (e.g., 5 minutes) or at a basic level (i.e., the demo stops once the user reaches an advanced level in the game)

[0045] In one embodiment, the advertising module 210 is responsible for selecting recipients of specific advertisements based on data stored in the databases 216 and 218 and facilitating in-game delivery of advertisements to the selected client devices. In one embodiment, the advertising module 210 is also responsible for identifying potential customers of a game product, sending an invitation to try a new game product to a potential customer, and upon receiving consent from a potential customer, facilitating a download of a demo version of the new game product to his or her mobile device.

[0046] hi one embodiment, the advertising module 210 is linked into the demo mode of the platform such that a demo version may operate in several modes. For example, a demo version may operate in a time limited mode, a score limited mode or an advertisement-enabled mode. In an advertisement-enabled mode, a user playing a demo version will see advertisements targeted based on data mining at game milestones (e.g., at game start, between game levels, etc.).

[0047] The billing module 212 is responsible for performing billing transactions pertaining to billable events, such as purchases and lease of content, and storing information on billing transactions in the billing database 220. In one embodiment, when the billing module 212 receives a user request to purchase a game, it sends an acknowledgment to the relevant client device (e.g., "Game A has been billed to your accounts for $3.95) and instructs the game usage controller 204 to "unlock" game A

(i.e., cause game A to be available to the user) on the relevant client device, rn addition, the billing module 212 may request the user to provide billing information (e.g., an identifier of a user account maintained by the game management system, a credit card number, etc.) to complete the billing transaction or to send the billing request to a corresponding network communication carrier (e.g., to be charged against the user's phone bill), a corresponding billing aggregator (e.g., to be charged against a user account maintained by the billing aggregator such as PayPal®), or any other billing entity capable of supporting a debit transaction. In one embodiment, the billing module 212 allows the users to request and pay separately for various game related features (e.g., high score submission, multi-player messaging, chat messaging, game content upgrade, content refresh such as refresh of pictures and sound files, etc.) and non-application data (e.g., Musical Instrument Digital Interface (MIDI) files, graphics files, etc.).

[0048] In one embodiment, the billing module 212 identifies delinquent users and passes this information to the game usage controller 204, which can then "lock" the game (i.e., cause the user access to the game to be discontinued). In one embodiment, the billing module 212 is also responsible for receiving requests for billing data from carriers and importing requested data from the billing database 220 to billing systems of the carriers.

[0049] The game download module 214 is responsible for facilitating downloads of games to relevant client devices. Li one embodiment, the game download module 214 stores downloadable game code. Alternatively, the game download module 214 stores information on the external location of downloadable game code (e.g., URLs of the game code available for downloading). In one embodiment, the game download module 214 also facilitates downloads of non-application data such as MIDI files, Portable Network Graphics (PNG) files, etc.

[0050] The versioning module 222 is responsible for receiving data identifying versions of games possessed by the users, and determining whether new versions of corresponding game products are available, hi one embodiment, the versioning module 222 sends messages to client devices to inform the users of the new game product versions and to indicate the location of the corresponding downloadable game code. Alternatively, the versioning module 222 may download game subcomponents (e.g., roster data, new graphics, modified levels, etc.) automatically, without involving the user in the download process (e.g., without specifying the location of the corresponding downloadable game code, etc.). [0051] The user account manager 224 is responsible for collecting user account information from client devices, storing this information in the user database 216, and allowing web-based user login to their accounts. The user account information may include, for example, a list of games owned, user rankings, ladders, message boards, system information, user gaming preferences, etc.

[0052] The game matching engine 226 is responsible for finding multi-player game sessions that may be of interest to a user and providing user access to these multi- player game sessions. Multi-player game sessions referred to herein are also known as game lobbies where players are waiting to play relevant multi-player games. The game matching engine 226 finds attractive multi-player game sessions for a user based on game metrics and preferences of the user. In one embodiment, the user preferences are specified by the user. Alternatively, the user preferences are inferred from the prior behavior of the user.

[0053] In one embodiment, the game management system 200 may also contain an administration module (not shown) that is responsible for allowing various levels of user access to the different services and data. For example, a game publisher administrator may be granted the highest access level to all data and services provided by the game management system 200 while a carrier administrator may be granted a lower access level allowing only access to services and data provided to the users of this carrier. In one embodiment, the administration module is also responsible for providing default settings and permissions for individual carriers and allowing customization of the default settings and permissions on a carrier basis. In one embodiment, the administration module is responsible for reconfiguring the game management system 200 in real time to add a new carrier with default setting and permissions.

[0054] Because the game management system 200 provides services to users of various network communication carriers, game player communities are no longer limited to users of a specific carrier or a specific device platform. In addition, the game management system 200 allows manufactures and publishers of electronic games to develop direct relationships with players of mobile games, PC games, web-based games and console games, collect detailed information about these game players, and facilitate targeted advertisements of electronic games. Furthermore, the game management system 200 provides quick access to the most attractive multi-player game sessions based on gamers' expressed and learned gameplay preferences. Client-Based Module

[0055] As discussed above, each client device serviced by the game management system hosts a client-based module (referred to herein as a gaming data module) that may be integrated with a game application (e.g., a mobile game application, a PC game application, a web-based game application, a console game application, etc.) or operate as an independent application. In one embodiment, the gaming data module is an application programming interface (API) that may vary depending on the game type. For example, a client API for a PC game may retrieve system information about the PC (e.g., disk and memory sizes, operating system information, video card type, etc.) and send this system information to the game management system 102. In addition, client API features may vary for different games. For example, a client API for a specific game may not support in-game advertising or game metric collection.

[0056] The gaming data module is responsible for forwarding messages (and storing messages when the client device is disconnected from the network) to the game management system and supporting real-time in-game features (e.g., in-game advertisement, multi-player gameplay, user registration, game metric collection, etc.) facilitated by the game management system.

[0057] Figure 2B is a block diagram of one embodiment of a gaming data module 240. The gaming data module 240 includes a billing component 242, a game access component 244, a high score component 246, a versioning alert component 248, an advertisement component 250, a marketing component 252, a user profile component 254, a game browser component 256, a game download component 258, and a user database 260.

[0058] The billing component 242 is responsible for sending billing data (e.g., the title of the game, the device ID, the user ID, user billing information, etc.) to the game management system, receiving a purchase acknowledgment from the game management system, and displaying the purchase acknowledgement to the user.

[0059] The game access component 244 is responsible for sending game keys (e.g., the game title, the device ID, and the user ID) to the game management system and unlocking the game upon receiving an unlock instruction from the game management system. In one embodiment, the game access component 244 checks with the game management system each time the user starts a game to determine whether the game should be re-locked (e.g., if subscription expires, game is pirated, etc.). In one embodiment, the game access component 244 flags high priority messages (e.g., game purchase messages) to send to the game management system immediately or store in a record file for resending if service is out (e.g., if a user wants to buy the game while in the out-of-service area).

[0060] The high score component 246 is responsible for submitting the user's score to the game management system when the user finished playing the game, receiving a current list of high scores for a game product, and displaying the current list to the user.

[0061] The versioning alert component 248 is responsible for sending game version information to the game management system when the user launches the game, receiving information on a newer version of this game product from the game management system, and displaying this information to the user before the game start.

[0062] The user profile component 254 is responsible for capturing user profile data and storing the user profile data in the user database 260. The user profile data may be captured based on information of interest defined by the game management system. The user profile data may specify, for example, which games the user plays on this client device, when the games are played, user scores earned in the games, user device information (e.g., device type, CPU, etc), etc. In addition, the user profile data may specify preferences of the user with respect to online multi-player games. These preferences may include, for example, a preferred average experience of the user's team members, a preferred maximum number of members in the user's team, a preferred opponent team-member experience, etc. In one embodiment, the user preferences are maintained for each game product that is of interest to the user.

[0063] The advertisement component 250 is responsible for sending new user profile data to the game management system, receiving ads selected by the game management system based on the user profile data and a set of rules, and displaying the ads to the user.

[0064] The marketing component 252 is responsible for collecting game metrics and sending them to the game management system. The game metrics may specify, for example, the version of a played game, the score of the game, how long the game was played, etc.

[0065] The game browser component 256 allows users to log in at game launch, view their preferences, and browse current game products available at the game management system. In one embodiment, the game browser component 256 also allows users to view game products' screenshots, descriptions and price.

[0066] The game download component 258 allows users to download new games.

Game Matching

[0067] Figure 3 is a block diagram of one embodiment of a game matching engine 302. The game matching engine 302 includes a behavior analyzer 304, a game monitor 306, a matching request receiver 308, a search engine 310, a user notifier 312, a user profile database 314, a game metrics database 316, and a game attributes database 318.

[0068] The behavior analyzer 304 is responsible for receiving game metrics from various client devices and game servers facilitating gameplay for multi-player online games, and storing the game metrics in the game metrics database 316. The game metrics may include, for example, titles of played games, versions of played games, the duration of played games, names of game players, scores of game players, experience levels of game players, playing patterns of game players, etc. hi one embodiment, the behavior analyzer 304 periodically analyzes the game metrics associated with individual users to infer their preferences, and then updates user preferences in the user profile database 314. hi another embodiment, the user preferences are maintained in the user profile database 314 based on data specified by the users. In yet another embodiment, the user preferences are maintained using a combination of user-specified data and analyses performed by the behavior analyzer 304 (e.g., some user preferences are specified by the users while other user preferences are inferred by the behavior analyzer 304). In one embodiment, the user preferences are applicable to multi-player game sessions played by a user on various client devices (e.g., mobile phones, a PC, a hand-held computer, a video game console, etc.).

[0069] The game monitor 306 is responsible for periodically analyzing game metrics in the game metrics database 316 to identify currently active multi-player game sessions, and determining attributes of each multi-player game session based on the game metrics. The multi-player game attributes may include, for example, an average player experience level in each team, the number of players in each team, multi-player game session duration, gameplay patterns of each team, etc. The game monitor 306 stores the multi-player game attributes in the game attributes database 318. The matching request initiator 308 is responsible for initiating requests for matching multi-player games. In one embodiment, the matching request initiator 308 initiates a request for matching multi-player game sessions upon receiving a request from a user who already owns the game (an instance of a game product) and wants to participate in a multi-player session of this game.

[0070] In another embodiment, the matching request initiator 308 initiates a request for a matching multi-player game product based on marketing-based provisions, which make it possible for a user to play a multi-player game the user does not own or lease. Once the search engine 310 finds a matching multi-player game product, an instance of this game product may be offered to the user for purchase, lease or demo with the intent to expose the user to the game he or she does not own.

[0071] The search engine 310 is responsible for executing matching requests. In one embodiment, in which the request is for matching multi-player game sessions, the search engine 310 searches for multi-player sessions of a specified game that match preferences of a user. The search engine 310 finds the matching multi-player game sessions based on predefined business rules. The business rules define the scope of the search and may differ depending on a game title. For example, the business rules may specify how closely the multi-player game session should match the user preferences to qualify as a match. In one embodiment, the search engine 310 finds the matching multi- player game sessions in response to a matching request received from a user. Alternatively, the search engine 310 does not wait for a request but instead periodically searches for active multi-player game sessions that accept players, finds users with preferences matching these active multi-player game sessions, and invites these users to join the relevant multi-player game sessions.

[0072] In another embodiment, in which the request is for a matching multi- player game product, the search engine 310 searches for a multi-player game product based on marketing metrics and user profile data mining. For example, the marketing metrics may specify that a specific game product should be offered to every user who has previously played games of a certain category.

[0073] The user notifier 312 is responsible for notifying the users about the found match or matches. In one embodiment, the user notifier 312 presents to the user the multi-player game sessions for a specified game product that satisfy the user preferences. In another embodiment, in which the matching game product is found based on marketing provisions, the user notifier 312 may invite the user to download an instance of the matching game product (e.g., via an advertisement at the start of some other game owned by the user). The user may then be permitted to play this game only in a limited manner (e.g., as a demo, by paying a per-play fee, etc.).

[0074] In another embodiment, in which periodic searches are performed by the search engine 310 to invite users, the user notifier 312 sends a message to the user with an invitation to join the matching multi-player game session. In one embodiment, the invitation may be sent via an external notification event (e.g., an email message, an SMS message, an BVI message, etc.). Alternatively, the invitation may be sent via an in- game notification event (e.g., using a chat engine) that may, for example, interrupt a single-player game or overlay some displayed text with the invitation.

[0075] In one embodiment, the search engine 310 performs periodic searches for a multi-player game lobby associated with a specific game product. As will be discussed in more detail below, in one embodiment, the search engine 310 defines a "personality" of the game lobby and then searches for users with preferences matching the personality of the game lobby. When such users are found, the user notifier 312 sends them an invitation to join the game lobby. The personality of the game lobby may be defined by randomly selecting values for the attributes associated with the game product. Alternatively, the personality of the game lobby may be inherited from the personalities of the players in the lobby. That is, the values assigned to the attributes associated with the game product are selected based on user preferences of the players in the game lobby. As new players are added to the game lobby, the personality of the game lobby may change. Accordingly, the game matching engine 302 enables a game lobby to evolve a personality and then seek users with preferences matching the personality of the game lobby, regardless of whether these users have met or played against each other before. The user preferences may be inferred by the behavior analyzer 304 and/or specified by the users for the relevant game product.

[0076] Figure 4 is a flow diagram of one embodiment of a process for finding a desirable multi-player game session for a user. The process may be performed by processing logic that may comprise hardware (e.g., dedicated logic, programmable logic, microcode, etc.), software (such as run on a general purpose computer system or a dedicated machine), or a combination of both. In one embodiment, the process is performed by a game matching engine 302.

[0077] Referring to Figure 4, process 400 begins with processing logic receiving a request to find matching multi-player game sessions for a user (processing block 402). hi one embodiment, the request is submitted by the user (e.g., by clicking a "Find a matching game" button). Alternatively, the request may be generated automatically upon detecting a certain action performed by a user (e.g., upon detecting that the user is browsing a list of active multi-player sessions of a specific game product), hi one embodiment, the user request specifies a game product for which matching active multi-player game sessions or lobbies should be found.

[0078] At processing block 404, processing logic analyzes the user profile to determine gaming preferences of the user, hi one embodiment, the gaming preferences are specified by the user, hi another embodiment, processing logic infers gaming preferences of the user based on the user's prior behavior. The user preferences may include, for example, a preferred average experience of the user's team members, a preferred maximum number of members in the user's team, a preferred opponent team- member experience, etc. hi one embodiment, the user preferences are maintained for each game product that is of interest to the user. In one embodiment, the user preferences are maintained for all devices used by the user for playing games (e.g., a PC, a hand-held computer, a wireless phone, a game console, etc.). For example, for a game product having a wireless phone version and a game console version, the user preferences specified for the wireless phone version are applicable to the game console version unless the user wants to maintain separate preferences for each device.

[0079] At processing block 406, processing logic compares the gaming preferences of the user with attributes of currently active multi-player game sessions using business rules, hi one embodiment, the attributes of each game session or game lobby are maintained based on profiles of participating players and gaming metrics received from relevant game servers. The business rules define the scope of the search and may specify which attributes need to be compared, how similar user preferences and game attributes should be, etc.

[0080] Next, processing logic finds multi-player game sessions matching the user preferences (processing block 408) and presents a list of matching multi-player game sessions to the user (processing block 410). hi one embodiment, the list of matching multi-player game sessions includes multi-player games and/or lobbies currently active for a game product specified by the user. Alternatively, the list of matching multi-player game sessions includes multi-player games and/or lobbies currently active for various game products.

[0081] In one embodiment, the matching multi-player game sessions are presented in ranked (or weighted) order indicating how closely each game session matches the user preferences. In one embodiment, each multi-payer game session in the list is presented as a link to the relevant multi-player game session.

[0082] At processing block 412, processing logic provides access to a multi- player game session selected by the user from the list (e.g., by clicking a link representing the multi-player game session).

[0083] Figure 5 is a flow diagram of one embodiment of a process 500 for inferring gaming preferences of a user. The process may be performed by processing logic that may comprise hardware (e.g., dedicated logic, programmable logic, microcode, etc.), software (such as run on a general purpose computer system or a dedicated machine), or a combination of both. In one embodiment, the process is performed by a game matching engine 302.

[0084] Referring to Figure 5, process 500 begins with processing logic collecting gaming data associated with a user (processing block 402). The gaming data is collected from client devices used by the user and game servers supporting games played by the user. The gaming data may include, for example, titles of games played by the user, the user's gameplay attributes (e.g., scores, skill level, gameplay type (e.g., strategic, action), etc.), gameplay attributes of members of the user's team, gameplay attributes of the user's opponents, game environment, game duration, etc.

[0085] Next, processing logic analyzes the user behavior using the collected gaming data (processing block 504) and creates user preferences based on this analysis (processing block 506).

[0086] Subsequently, processing logic receives new gaming data from the game servers and the user's client devices, repeats behavior analysis using the new gaming data (processing block 508), and determines whether the user preferences need to be changed (processing block 510). If so, processing logic updates the user preferences (processing block 512) and returns to processing block 508. If not, processing logic proceeds directly to processing block 508. [0087] Accordingly, process 500 provides a heuristic approach for determining user preferences that achieves more accurate results with time and eliminates the need to enter user preferences on a client device, which may be especially burdensome for users of wireless phones.

[0088] Figure 6 is a flow diagram of one embodiment of a process 600 for maintaining attributes of multi-player game sesions. The process may be performed by processing logic that may comprise hardware (e.g., dedicated logic, programmable logic, microcode, etc.), software (such as run on a general purpose computer system or a dedicated machine), or a combination of both. In one embodiment, the process is performed by a game matching engine 302.

[0089] Referring to Figure 6, process 600 begins with processing logic identifying currently active multi-player game sessions using gaming data collected from game servers (processing block 602). In one embodiment, processing logic identifies currently active multi-player game sessions based on game start and end events received from APIs of game applications.

[0090] At processing logic 604, processing logic composes a list of currently active multi-player game sessions.

[0091] At processing block 606, processing logic collects attributes for each active multi-player game session. In one embodiment, processing logic receives a set of game attributes from APIs of relevant game applications.

[0092] At processing block 608, processing logic stores the collected game attributes in the game attributes database.

[0093] Figure 7A is a flow diagram of one embodiment of a process 700 for inviting new players to participate in active multi-player game sessions. The process may be performed by processing logic that may comprise hardware (e.g., dedicated logic, programmable logic, microcode, etc.), software (such as run on a general purpose computer system or a dedicated machine), or a combination of both. In one embodiment, the process is performed by a game matching engine 302.

[0094] Referring to Figure 7A, process 700 begins with processing logic receiving an indication that a player is needed for an active multi-player game session or game lobby (processing block 702). hi one embodiment, this indication is received from a corresponding game server informing the game matching engine that one or more additional players are needed to start a specific game. [0095] At processing block 704, processing logic compares attributes of the above multi-player game session with preferences of various users to find a user who may be interested in joining the multi-player game session. The user preferences may be specified by the user or inferred from his or her gaming history. In one embodiment, the game attributes are compared with the user preferences using predefined business rules (e.g., a rule requiring that only users previously agreed to invitations be considered).

[0096] Next, processing logic finds a user with preferences matching the attributes of the multi-player game session (processing block 706) and invites the user to join this multi-player game session or multi-player game lobby (processing block 708). Processing logic may send the invitation via email SMS, IM or any other means. In one embodiment, the invitation includes a link allowing immediate access to the multi-player game.

[0097] Figure 7B is a flow diagram of one embodiment of a process for seeking players for a multi-player game session. The process may be performed by processing logic that may comprise hardware (e.g., dedicated logic, programmable logic, microcode, etc.), software (such as run on a general purpose computer system or a dedicated machine), or a combination of both. In one embodiment, the process is performed by a game matching engine 302.

[0098] Referring to Figure 7B, process 720 begins with processing logic identifying a multi-player game lobby (processing block 702). The game lobby may be an existing multi-player game lobby that is currently active for a specific game product. Alternatively, the game lobby may be a multi-player game lobby newly created for a specific game product (e.g., to conduct a game tournament).

[0099] At processing block 724, processing logic defines a personality of the game lobby. In one embodiment, processing logic defines the personality of the game lobby by assigning certain values to the attributes associated with the relevant game product. In one embodiment, the assigned values are determined based on preferences of the players in the game lobby. As discussed above, these preferences may be specified by the players and/or inferred from the prior behavior of the players. As new players are added to the game lobby, the personality of the game lobby may change.

[00100] In another embodiment, the assigned values are selected randomly. In yet another embodiment, the assigned values are selected based on criteria associated with an intended usage of the created game lobby. For example, the game lobby may be used in a tournament, and the assigned values may be selected based on a skill level required for the tournament, user criteria such as age and gender, hardware capability (e.g., phone model/speed), physical locale, etc. In still another embodiment, the assigned values may be selected based on gameplay history (e.g., hours played, type of gameplay (aggressive, passive), etc.) associated with the relevant game product.

[00101] Next, processing logic searches preferences of various users to find users who would likely prefer the game lobby (processing block 726). In one embodiment, processing logic finds such users by comparing gaming preferences of various users with the attributes of the game lobby.

[00102] At processing logic 728, processing logic invites users with matching preferences to join the game lobby. In one embodiment, processing logic invites a user via an external notification event (e.g., an email message, an SMS message, an IM message, etc.). Alternatively, processing logic invites a user via an in-game notification event (e.g., using a chat engine) that may, for example, interrupt a single-player game or overlay some displayed text with the invitation.

[00103] Figure 8 is a flow diagram of one embodiment of a process 800 for supporting revenge games. The process may be performed by processing logic that may comprise hardware (e.g., dedicated logic, programmable logic, microcode, etc.), software (such as run on a general purpose computer system or a dedicated machine), or a combination of both, hi one embodiment, the process is performed by a game matching engine 302.

[00104] Referring to Figure 8, process 800 begins with processing logic detecting that a first player lost to a second player (processing block 802). This detection may be made based on gaming data received from a game server or a client device of the first or second player.

[00105] At processing block 804, processing logic examines preferences of the first player. If the preferences of the first player specify that the first player desires a revenge game (processing block 806), processing logic starts monitoring the online activity of the second player. Upon detecting that the second player appears online and is about to start a new multi-player game session (processing block 808), processing logic invites the first player to join the multi-player game session selected by the second player (processing block 810). In one embodiment, processing logic invites the first player only if the second player selects a session for the multi-player game that was played by the both players before.

[00106] In another embodiment, processing logic invites the first player to a session of any multi-player game selected by the second player. In one embodiment, processing logic invites the first player only if the first player owns the game selected by the second player. Processing logic may then send the invitation to the first player using an external notification event (e.g., email, SMS, or IM message) or using an in-game notification event (e.g., via a chat engine). In one embodiment, the invitation includes a link allowing immediate access to the game.

[00107] In another embodiment, processing logic invites the first player even if the first player does not own the game selected by the second player. In particular, if the second player selects a multi-player session of a game not owned by the first player, processing logic invites the first player to download this game to play a revenge match. The downloaded game version may include limited functionality to, for example, allow the first player to play only a revenge match. In another embodiment, processing logic allows any player to receive a challenge or initiate a challenge in a game not owned by the player if the player pays a per-play fee. As a result, any user can challenge any other user, regardless of game ownership. In addition, as users become exposed to games they do not own, they may enjoy the game and decide to purchase or lease it.

[00108] Process 800 may be performed in a similar manner for a scenario in which the first player is in a game session (single or multiplier) and receives an in-game notification that his or her enemy just logged in. In this scenario, the first player will send a challenge for the second player to join the current game session invoked by the first player.

[00109] Figure 9 is a flow diagram of one embodiment of a process 900 for providing alerts to users. The process may be performed by processing logic that may comprise hardware (e.g., dedicated logic, programmable logic, microcode, etc.), software (such as run on a general purpose computer system or a dedicated machine), or a combination of both. In one embodiment, the process is performed by a game matching engine 302.

[00110] Referring to Figure 9, process 900 begins with processing logic detecting that a user has requested an alert (processing block 902). An alert may be requested to receive notifications when a desired player or team is online in an active multi-player game session or multi-player game lobby, a desired multi-player game session accepts new players, etc. The user may request an alert by, for example, enabling an "Alert Me" feature in a user profile.

[00111] At processing block 904, processing logic monitors gameplay data received from game servers or a single game server (if the target is a specific game) to determine whether an alert condition is satisfied (processing block 906).

If an alert condition is satisfied, processing logic sends an alert to the user (processing block 908). Processing logic may send the alert using an external notification event (e.g., email, SMS, or IM message) or using an in-game notification event (e.g., via a chat engine). In one embodiment, the message containing the alert includes a link allowing immediate access to the game that satisfies the alert condition.

[00112] Figure 10 is a flow diagram of one embodiment of a process 1000 for facilitating multi-player game tournaments. The process may be performed by processing logic that may comprise hardware (e.g., dedicated logic, programmable logic, microcode, etc.), software (such as run on a general purpose computer system or a dedicated machine), or a combination of both. In one embodiment, the process is performed by a game matching engine 302.

[00113] Referring to Figure 10, process 1000 begins with processing logic scheduling a multi-player game tournament (processing block 1002).

[00114] At processing block 1004, processing logic finds users that may be interested in the tournament using the process discussed above in conjunction with Figure 7B.

[00115] At processing block 1006, processing logic invites the found users to participate in the tournament. Processing logic may send the invitation to the users using an external notification event (e.g., email, SMS, or IM message) or using an in- game notification event (e.g., via a chat engine).. In one embodiment, the invitation includes a link allowing the user to register for the tournament.

An Exemplary Computer System

[00116] Figure 11 is a block diagram of an exemplary computer system 1100 that may be used to perform one or more of the operations described herein. In alternative embodiments, the machine may comprise a network router, a network switch, a network bridge, Personal Digital Assistant (PDA), a cellular telephone, a web appliance or any machine capable of executing a sequence of instructions that specify actions to be taken by that machine.

[00117] The computer system 1100 includes a processor 1102, a main memory 1104 and a static memory 1106, which communicate with each other via a bus 1108. The computer system 1100 may further include a video display unit 1110 (e.g., a liquid crystal display (LCD) or a cathode ray tube (CRT)). The computer system 1100 also includes an alpha-numeric input device 1112 (e.g., a keyboard), a cursor control device 1114 (e.g., a mouse), a disk drive unit 1116, a signal generation device 1120 (e.g., a speaker) and a network interface device 1122.

[00118] The disk drive unit 1116 includes a computer-readable medium 1124 on which is stored a set of instructions (i.e., software) 1126 embodying any one, or all, of the methodologies described above. The software 1126 is also shown to reside, completely or at least partially, within the main memory 1104 and/or within the processor 1102. The software 1126 may further be transmitted or received via the network interface device 1122. For the purposes of this specification, the term " computer- readable medium" shall be taken to include any medium that is capable of storing or encoding a sequence of instructions for execution by the computer and that cause the computer to perform any one of the methodologies of the present invention. The term "computer-readable medium" shall accordingly be taken to included, but not be limited to, solid-state memories, optical and magnetic disks, and carrier wave signals.

[00119] Whereas many alterations and modifications of the present invention will no doubt become apparent to a person of ordinary skill in the art after having read the foregoing description, it is to be understood that any particular embodiment shown and described by way of illustration is in no way intended to be considered limiting. Therefore, references to details of various embodiments are not intended to limit the scope of the claims which in themselves recite only those features regarded as essential to the invention.

Claims

CLAIMSWe claim:

1. A method comprising: finding, based on business rules, one or more multi-player game sessions that match preferences of a potential player; and notifying the potential player of the one or more matching multi-player game sessions.

2. The method of claim 1 wherein the preferences of the potential player are specified by the potential player or are inferred from a prior behavior of the potential player.

3. The method of claim 1 further comprising: receiving a request of the potential player for matching multi-player game sessions.

4. The method of claim 3 wherein notifying the potential player of the one or more matching multi-player game sessions comprises: displaying a list of the one or more matching multi-player game sessions to the potential player.

5. The method of claim 1 further comprising: maintaining a list of active multi-player game sessions.

6. The method of claim 1 further comprising: maintaining a set of preferences for each player, the set of preferences comprising subsets of preference attributes specific to individual game products.

7. The method of claim 6 wherein the set of preferences of each player is applicable to multi-player games played by said each player on a plurality of client devices, the plurality of client devices being selected from the group consisting of a mobile phone, a personal computer, a hand-held computer, and a video game console.

8. The method of claim 1 further comprising: maintaining a set of attributes for each game product; and finding the one or more matching multi-player game sessions using the set of attributes.

9. The method of claim 1 wherein notifying the potential player of the one or more matching multi-player game sessions comprises: sending an alert to the potential player upon finding the one or more matching multi-player game sessions, the alert being sent via any one of an external notification mechanism and an in-game notification mechanism.

10. The method of claim 1 further comprising: providing access to the one or more matching multi-player game sessions for the potential player.

11. . A method comprising: identifying game attributes associated with a multi-player game session; determining that a new player is likely to have interest in the multi-player game session based on the game attributes and preferences of the new player; and inviting the new player to join the multi-player game session.

12. The method of claim 11 wherein the preferences of the new player are specified by the new player or are inferred from a prior behavior of the new player.

13. The method of claim 11 wherein inviting the new player comprises sending a message to the new player using an external notification mechanism or an in-game notification mechanism.

14. The method of claim 11 further comprising: providing access to the matching multi-player game session for the new player.

15. The method of claim 11 wherein identifying game attributes associated with the multi-player game session comprises: creating a game lobby; assigning values to the game attributes; and selecting the values based on one or more criteria.

16. A method comprising: finding, based on marketing provisions, a multi-player game product that matches user preferences; and offering a demo of the multi-player game product to a user to raise user interest in the multi-player game product.

17. A system comprising: a search engine to find, based on business rules, one or more multi-player game sessions that match preferences of a potential player; and a user notifier to notify the potential player of the one or more matching multi-player game sessions.

18. A system comprising: a search engine to identify game attributes associated with a multi-player game session, and to determine that a new player is likely to have interest in the multi-player game session based on the game attributes and preferences of the new player; and a user notifier to invite the new player to join the multi-player game sessions.

19. A computer readable medium comprising executable instructions which when executed on a processing system cause said processing system to perform a method comprising: finding, based on business rules, one or more multi-player game sessions that match preferences of a potential player; and notifying the potential player of the one or more matching multi-player game sessions.

20. A computer readable medium comprising executable instructions which when executed on a processing system cause said processing system to perform a method comprising: identifying game attributes associated with a multi-player game session; determining that a new player is likely to have interest in the multi-player game session based on the game attributes and preferences of the new player; and inviting the new player to join the multi-player game session.