CN118103118A

CN118103118A - System and method for matching users of client applications

Info

Publication number: CN118103118A
Application number: CN202280049598.6A
Authority: CN
Inventors: A·R·梅克尔; M·帕尔默; S·Y·贝克; S·M·哈尔丁; K·芭布; S·L·格雷瓜尔
Original assignee: Schiritz Platform Co ltd
Current assignee: Schiritz Platform Co ltd
Priority date: 2021-05-13
Filing date: 2022-05-13
Publication date: 2024-05-28

Abstract

In an aspect, a request may be received from a first user of the plurality of users of an application client executing on respective mobile devices of the plurality of users to interact with one or more other users of the plurality of users in the application client based on a first plurality of interaction templates selected by the first user. The second user associated with the second interaction template may be determined from a plurality of users, and the determination may be based on an identification of a match between the second interaction template and the first interaction template from the first plurality of interaction templates. Interactions in the application client between the first user and the second user may be initiated in response to a determination by the second user. Related systems, devices, techniques, and articles are also described.

Description

System and method for matching users of client applications

Cross Reference to Related Applications

The present application claims the benefits and priority according to 35u.s.c. ≡119 of U.S. provisional application No. 63/188,004 filed on day 2021, 5 and 13 and U.S. provisional application No. 63/269,843 filed on day 2022, 3, the contents of each of which are hereby incorporated by reference in their entirety.

Background

The users of the client applications may contact or otherwise interact with other users of those client applications in a variety of ways. For example, a user may compete with other users in a client application (e.g., a mobile game or other computer game) to win a prize or other achievement. One of the factors that may affect the user's experience in a client application is the quality of an adversary with which the user competes or otherwise interacts. A large difference between opponents, for example, in their respective abilities or skill levels, may adversely affect each user's experience in a client application. For example, if a beginner pairs with an expert in a game, neither the beginner nor the expert may find the game interesting or even fair, because the beginner may be frustrated by having little chance to win, while the expert may be frustrated by competing with little challenging opponents. Another factor that may affect the user's experience in a client application is the time required to find an adversary. The longer waiting time may be frustrating to the user and may lead to user chunking.

Disclosure of Invention

Systems and methods for matching users of client applications are provided. Related apparatus, techniques, and articles are also described.

In an aspect, a request may be received from a first user of a plurality of users of an application client executing on respective mobile devices of the plurality of users to interact with one or more other users of the plurality of users in the application client based on a first plurality of interaction templates selected by the first user. The second user associated with the second interaction template may be determined from the plurality of users, and the determination may be based on an identification of a match between the second interaction template and the first interaction template from the first plurality of interaction templates. Interactions in the application client between the first user and the second user may be initiated in response to a determination by the second user.

One or more of the following features may be included in any feasible combination. For example, the second user may be searched until a match between another interaction template from the first plurality of interaction templates and the second interaction template is identified. For example, each of the second interaction template and the first plurality of interaction templates may characterize a synchronized electronic tournament for the first user and the second user to sign up. For example, the determination of the second user may further include selecting a first interaction template from the first plurality of interaction templates based on operating parameters of the synchronous electronic tournament. For example, the determining of the second user may further include selecting the first interaction template from the first plurality of interaction templates based on the determined priority of the first interaction template. For example, a third user associated with a fourth interaction template may be determined from the plurality of users, the fourth interaction template matching a third interaction template from the first plurality of interaction templates, and the determination of the third user may be made when a determined duration for the second user exceeds a predetermined threshold. For example, a graphical prompt for display on a mobile device of a first user may be determined, and the graphical prompt may characterize instructions to select a fifth interaction template from the first plurality of interaction templates when a determined duration for a second user exceeds a predetermined threshold. For example, in response to selection of the fifth interaction template, a fourth user associated with a sixth interaction template may be determined from the plurality of users, the sixth interaction template matching the fifth interaction template. For example, the first plurality of interaction templates may be selected by the first user from a set of available interaction templates, and the set of available interaction templates may be determined based on characteristics of the first user. For example, the determination of the second user may be based on characteristics of the first user. For example, the determination of the second user may be based on characteristics of one or more of the first plurality of interaction templates.

In another aspect, a system is provided and may include at least one data processor and a memory storing instructions configured to cause the at least one data processor to perform operations described herein. The operations may include receiving, from a first user of a plurality of users of an application client executing on respective mobile devices of the plurality of users, a request to interact with one or more other users of the plurality of users in the application client based on a first plurality of interaction templates selected by the first user; determining a second user from the plurality of users, the second user being associated with a second interaction template, the determining being based on an identification of a match between the second interaction template and a first interaction template from the first plurality of interaction templates; and in response to the determination of the second user, initiating an interaction between the first user and the second user in the application client.

One or more of the following features may be included in any feasible combination. For example, the operations may further include searching the second user until a match between another interaction template from the first plurality of interaction templates and the second interaction template is identified. For example, each of the second interaction template and the first plurality of interaction templates may characterize a synchronized electronic tournament for the first user and the second user to sign up. For example, determining may further include selecting a first interaction template from the first plurality of interaction templates based on operating parameters of the synchronous electronic tournament. For example, the determining may further include selecting a first interaction template from the first plurality of interaction templates based on the determined priority of the first interaction template. For example, the operations may further include determining a third user from the plurality of users that is associated with a fourth interaction template that matches the third interaction template from the first plurality of interaction templates, the determination of the third user being made when a determined duration for the second user exceeds a predetermined threshold. For example, the operations may further include determining a graphical prompt for display on the mobile device of the first user that characterizes instructions for selecting a fifth interaction template from the first plurality of interaction templates when the determined duration for the second user exceeds a predetermined threshold; and determining a fourth user associated with a sixth interaction template from the plurality of users in response to selection of the fifth interaction template, the sixth interaction template matching the fifth interaction template. For example, the first plurality of interaction templates may be selected by the first user from a set of available interaction templates, and the set of available interaction templates may be determined based on characteristics of the first user. For example, the determination of the second user may be based on characteristics of the first user.

Also described is a non-volatile computer program product (i.e., a physically embodied computer program product) storing instructions that, when executed by one or more data processors of one or more computing systems, cause at least one data processor to perform operations herein. Similarly, computer systems are also described that may include one or more data processors and memory coupled to the one or more data processors. The memory may store instructions that cause the at least one processor to perform one or more of the operations described herein, either temporarily or permanently. In addition, the method may be implemented by one or more data processors within a single computing system or distributed among two or more computing systems. Such computing systems may be connected and may exchange data and/or commands or other instructions, etc., via one or more connections, including connections through a network (e.g., the internet, a wireless wide area network, a local area network, a wide area network, a wired network, etc.), via direct connections between one or more of the plurality of computing systems, etc.

Drawings

The foregoing embodiments will be more fully understood from the following detailed description taken together with the accompanying drawings. The figures are not intended to be drawn to scale. For purposes of clarity, not every component may be labeled in every drawing. In the drawings:

FIG. 1 is a block diagram illustrating an exemplary system for automatically determining an appropriate match for a user of a mobile game;

FIGS. 2A and 2B are block diagrams illustrating an exemplary computer-implemented method of automatically determining an appropriate match for a user of a mobile game;

FIG. 3 is an illustration of a first user interface for entering a queue of multiple templates having multiple game modes;

FIG. 4 is an illustration of a second user interface for entering a queue of multiple templates having multiple game modes;

FIG. 5 is an illustration of a third user interface for entering a queue of multiple templates with a single play mode;

FIG. 6 is a block diagram illustrating an exemplary computer-implemented method of automatically determining a proper match for a user of a client application based on a plurality of interaction templates selected by the user; and

FIG. 7 is a block diagram of an exemplary computing device that may perform one or more of the operations described herein, according to an embodiment of the invention.

Detailed Description

Certain exemplary embodiments will now be described to provide an overall understanding of the principles of the structure, function, manufacture, and use of the devices and methods disclosed herein. One or more examples of these embodiments are illustrated in the accompanying drawings. Those skilled in the art will understand that the devices and methods specifically described herein and illustrated in the accompanying drawings are non-limiting exemplary embodiments and that the scope of the present invention is defined solely by the claims. The features illustrated or described in connection with one exemplary embodiment may be combined with the features of other embodiments. Such modifications and variations are intended to be included within the scope of the present invention. Moreover, in this disclosure similarly-named components of an embodiment typically have similar features, and thus, within a particular embodiment, each feature of each similarly-named component is not necessarily fully described in detail.

Some embodiments of the systems and methods of the present invention relate to automatically matching users in a client application with other users in the client application. The present invention may use one or more of a variety of user matching modules to automatically select the most appropriate match for each user based on the characteristics of the user. For example, the present invention may automatically match an individual user of a client application with another individual user of the client application based on one or more characteristics that are similar between the two users. Additionally or alternatively, some embodiments of the invention may match a first user or a first group of users that share one or more characteristics in common with a second group of users that share one or more characteristics similar to the first user or the first group of users. Some embodiments of the present invention may also more quickly match users by allowing users to enter a queue of multiple templates of multiple patterns for a client application. Some embodiments of the present invention may more quickly match users by allowing users to enter a queue of multiple templates of multiple patterns for a client application. Additionally, some embodiments of the present invention may improve the efficiency and processing power of computer hardware resources (e.g., computer processing and memory) to identify matches by supporting substantially faster matching times, and in particular providing substantially faster matching times for client applications having a larger number of users (e.g., hundreds of thousands, millions, tens of millions, etc. of users). For example, some embodiments of the invention may more efficiently handle a larger number of users queuing and identifying matches in multiple templates at the same time. By increasing the matching speed and efficiency of client applications with a greater number of users, computer hardware resources can be released more quickly and used for other tasks and processes, thereby significantly increasing computer resource utilization.

For purposes of discussion only and not limitation, the present disclosure will refer to mobile games as exemplary client applications to illustrate various aspects of the present invention. However, some embodiments of the invention may be used in and with any suitable type of client application in which one or more users are automatically matched with one or more other users with whom they are engaged or otherwise interacting to achieve a certain goal or result within the client application. For example, the present invention may produce matches for games or tournaments or other suitable activities, or otherwise match users with certain characteristics with other users of the client application with similar characteristics (e.g., establish conversations or social connections within the client application).

FIG. 1 is a block diagram illustrating an exemplary system 100 for automatically determining a proper match for a user of a mobile game. The server system 114 may provide functionality for collecting data associated with characteristics of players in the mobile game. Server system 114 may include software components and databases that may be deployed, for example, at one or more data centers 112 in one or more geographic locations. The software components of server system 112 may include a plurality of player matching modules including a first player matching module 116, a second player matching module 118, … …, an nth player matching module 120, where N may be any suitable natural number. The software components may include sub-components that may execute on the same or different individual data processing devices. Databases of server system 114 may include, for example, player data database 122 and game data database 124, although other databases are possible. The database may reside in one or more physical storage systems or may be cloud-based. The software components and data are further described below.

As shown in FIG. 1, first player matching module 116, second player matching modules 118, … …, and Nth player matching module 120 may be in communication with player database 122 and game database 124. The player data database 120 may include, for example, any suitable information related to the characteristics of one or more players of the mobile game and interactions between those players and the mobile game, such as player game history (e.g., which mobile games have been played, the number of plays won per mobile game, the number of plays lost per mobile game, the number of plays played per mobile game, the score of each mobile game, the time played per mobile game, the percentage of winnings, etc.), player identification information (e.g., user name), player connection history with the system 100, player purchases, player achievement, player tasks, player interactions (e.g., conversations) with other users, player purchases, player credits/withdrawals, player virtual item acquisition or use, other conditions in the mobile game, and other like player characteristics and/or information. The game data database 124 may include, for example, information related to mobile games implemented using the system 100. The game data database 124 may include information related to each mobile game, such as a virtual environment of each mobile game, images, video and/or audio data of each mobile game, event data corresponding to previous, current, or future events, game state data defining a current state of each mobile game, and so forth.

A software application, such as a mobile game or other web-based or suitable client application, may be provided as an end-user client application to allow a user to interact with server system 114. Software applications may relate to and/or provide a variety of functions and information including, for example, entertainment (e.g., games, music, video, etc.), commerce (e.g., word processing, accounting, spreadsheets, etc.), news, weather, financial, sports, and the like. In some embodiments, the software application may provide a mobile game. The mobile game may be or include, for example, a sports game, a adventure game, a virtual card game, a virtual table game, a jigsaw game, a racing game, or any other suitable type of mobile game. In one embodiment, the mobile game may be an asynchronous competitive skill based game in which players may compete with each other in the mobile game, but do not have to play the mobile game at the same time. In an alternative embodiment, the mobile game may be a synchronous competitive skill based game in which players may play the mobile game simultaneously and may compete with each other in real-time in the mobile game. Other suitable mobile games are also possible.

The software application or components thereof may be accessed by a user of a client device, such as client device a 102, client device B104, client devices C106, … …, client device M108, where M may be any suitable natural number, over a network 110 (e.g., the internet). Each of the client devices may be any suitable type of electronic device capable of executing software applications and communicating with the server system 114 over the network 110, such as a smart phone, tablet computer, laptop computer, desktop or personal computer, and the like. Other client devices are possible (e.g., game consoles and other similar computing devices). In an alternative embodiment, player data database 122, game data database 124, or any portion thereof, may be stored on one or more client devices. Additionally or alternatively, software components of the system 100 (e.g., the first player matching module 116, the second player matching module 118, … …, the nth player matching module 120), or any portion thereof, may be present on or available to perform operations on one or more client devices.

Fig. 2A and 2B are block diagrams illustrating an exemplary computer-implemented method 200 of automatically determining a proper match of a user of a mobile game according to embodiments of the present disclosure. In general, method 200 may be performed by processing logic (e.g., of server system 114) that may comprise hardware (e.g., a processing device, circuitry, dedicated logic, programmable logic, microcode, the hardware of the device, an integrated circuit, etc.), software (e.g., instructions run or executed on a processing device), or a combination thereof. In an embodiment, method 200 may be performed by processing logic in conjunction with any or all of first player matching module 116, second player matching modules 118, … …, nth player matching module 120 shown and discussed with respect to fig. 1. Method 200 may begin at block 204, where processing logic may monitor one or more characteristics of each player in a mobile game played on a respective client device (e.g., client device a 102, client device B104, client devices C106, … …, client device M108). The monitored player characteristics may depend on factors such as the type of mobile game and the manner in which the user interacts with the game, and may include, for example, the skill level or rating of the player within the game, the number of plays won or lost, whether the player is novice or experienced, and other similar characteristics, which may be stored in, for example, the player database 122 and retrieved from the player database 122. At block 206, processing logic may receive a request from a player to play in a tournament or otherwise participate in an interaction in a mobile game, which may initiate the matching process of the present invention. In an embodiment, the matching process may be comprised of one or more matching criteria for determining which player matching module (also referred to as a "matcher") best suits the player to make the best or most appropriate match with the player based on the monitored characteristics of the player. For purposes of illustration only and not limitation, fig. 2A and 2B show five matching criteria and six player matching modules. However, some embodiments of the invention may support any suitable number of different matching criteria and player matching modules, which may depend on the type of client application, the type of activity that will perform the matching, the characteristics of the user of the client application, and other similar factors.

At block 210, processing logic may determine whether the player meets a first match criterion. For example, the first matching criteria may be whether the player is novice or experienced. If processing logic determines that the player meets the first matching criteria (e.g., the player is a novice), processing logic may execute first player matching module 214. In one embodiment, the first player matching module 214 may be a novice player matcher. A novice player matcher may be used to match the novice player. In an embodiment, novice player matchers may take precedence over all or any other matchers, although matchers may be prioritized in any suitable manner or not prioritized at all. When a novice player requests to join a tournament or tournament, the novice player matcher may identify matches with another novice player or with senior players who are ranked low enough. For example, a player may be considered a "novice" based on the time that the player first began playing the mobile game or the time that the player first created an account or profile within or otherwise associated with the mobile game. Accordingly, older players that begin playing a new mobile game (e.g., a mobile game that they have not previously played) may be matched by the new player matcher. Additionally or alternatively, players who become experienced in competition in one type of tournament in the mobile game (e.g., a paid-up tournament) and begin to participate in a different type of tournament in the mobile game (e.g., a non-paid-up tournament) may match the new type of tournament via the novice player matcher.

In some embodiments, the first player matching module 214 may be configured by changing one or more parameters that may govern the operation of the module. For example, the novice player matcher may have a first parameter that determines whether to enable the novice player matcher (e.g., the matcher may be enabled by default). If the novice player matcher is disabled, then the same logic can be used to match the novice player as all other players, even the senior players. The second parameter may define who is considered a "novice" player. For example, if the player has played less than a first predetermined number of games (which may be any suitable number of games), the player may be matched by a novice player matcher. For purposes of illustration and not limitation, if the second parameter is set to 15, the player may consider his first 15 plays or tournaments as novice. Other values of the second parameter are possible. The third parameter may define that the player must play too many less games or tournaments before being considered a "senior" player. For example, if the third parameter is set to 50, the player may be considered "senior" or "experienced" after playing 50 games or tournaments (whether in the current mobile game or as a game aggregation across multiple other mobile games or games). Other values of the third parameter are possible. In an embodiment, if the senior players rank at a predetermined minimum percentage (e.g., minimum 5%, 10%, 15%, etc. of all players), the new hand player matcher may match the senior players with the new hand players using a third parameter. Other configurations of the first player matching module 214 are possible. For example, the novice player matcher may be configured such that a player who is entirely novice (e.g., first attended to a tournament or tournament) for a mobile game will not match a more experienced player, regardless of the experienced player's ratings.

In some embodiments, the first player matching module 214 may also affect or otherwise change the characteristics of the player in any suitable manner. For example, when a novice player is matched, the skill rating of the novice player may be adjusted based on the result of the matching. Thus, the rating of the senior citizen player will neither rise nor fall when the senior citizen player is in a battle with the novice player. If two novice players match each other, the ratings of the two players may be adjusted by a predetermined percentage (e.g., 50% or other suitable percentage) of the given amount. According to an alternative embodiment, this feature may be part of the k-factor (kFactor) functionality rather than the actual matcher. kFactor functionality will be discussed in more detail below. The novice player may have a higher kFactor than the senior player such that the rating of the novice player may be adjusted substantially faster than the rating of the senior player. In addition, for mobile games with different categories of games or tournaments (e.g., paid versus non-paid) novice players may rate losses in one category of games faster than losses in another category of games. For example, in a non-pay-for-entry race, the frequency of novice and low-skill senior players matching may be higher, and in such a race, there may also be a large rating difference between novice and low-skill senior players. In one embodiment, the wagering contest may be appropriately adjusted to limit how much the novice player may be rated differently from the low-skill senior player. In view of the fact that novice players may have a lower odds with older players, such matches may occur more frequently in non-pay-for-play matches and may be subject to more "punishment" due to the greater difference in ratings. This may result in faster rate variation for non-paid-up competition losses than for paid-up competition losses.

If, at block 210, processing logic determines that the player does not meet the first matching criteria (e.g., the player is too experienced or elderly), processing logic may proceed to block 218. At block 218, processing logic may determine whether the player meets a second match criterion. For example, the second match criterion may be whether the player meets a match with a skill or high or low opponent (e.g., depending on the player's win or loss rate). If processing logic determines that the player meets the second match criteria, processing logic may execute second player matching module 222. In one embodiment, the second player matching module 222 may be a game skill level matcher. The game skill level matcher may be used to match a player with an opponent of skill or high or low to the player. Such matching may occur, for example, when the player's win or lose ratio is high or otherwise "out of range" and the player is in an extended tie or continuous loss and should match an opponent that may provide the player with a greater or lesser challenge to enhance the athletic experience. Thus, the game skill level matcher may be used when the player's winnings rate in his previous predetermined number of games (e.g., the last 15, 20, or other number of games) is out of range. The game skill level matcher may search for opponents with different skill ratings in the appropriate direction based on whether the player should have a greater or lesser challenge, such as searching for a higher rating if the player requires a higher skill opponent, or searching for a lower rating if the player requires a lower skill opponent. According to one embodiment, depending on the extreme extent of the player's win or loss record and the player's win or loss rate, the player may match the opponent using an ELO difference that is below a predetermined lower limit (e.g., below 50, etc.) or above a predetermined upper limit (e.g., above 800, etc.).

In some embodiments, the second player matching module 222 may be configured by changing one or more parameters that may govern the operation of the module. For example, if the player's winning or continuous loss is greater than or equal to the first parameter, the game skill level matcher may optionally attempt to find a match for the player with a high or low skill opponent. According to the second parameter, if the number of plays played by the player is less than the predetermined number of games set by the second parameter, the game skill level matcher will not attempt to identify matches with skills or high or low opponents. For example, if the second parameter is set to 20, then in the event that the player plays less than 20 games (e.g., for a pay-for-play game, a non-pay-for-play game, or an appropriate combination thereof), the game skill level matcher will not match the player with a high or low skill opponent. Other values of the second parameter are possible. According to the third parameter, the game skill level matcher may attempt to achieve matches with skills or high or low opponents for the player at different difficulty levels based on a predetermined percentage of winnings specified by the third parameter. For purposes of illustration and not limitation, if the third parameter is set to 80%, then the game skill level matcher may attempt to identify a match with a more highly skilled opponent if the player has a win rate of greater than 80%. Alternatively, if the third parameter is set to 20%, then the game skill level matcher may attempt to identify matches with less skilled opponents in the event that the player has a win rate of less than 20%. Other values of the third parameter and associated results are possible.

In accordance with some embodiments of the invention, the game skill level matcher may use a variety of suitable techniques to match players with either high or low skill opponents. For example, if a match with a more highly skilled opponent is desired, then the player's opponent's rating may be given by equation (1):

opponent minimum rating = player rating + offset

Opponent highest rating = player rating + offset + (2 rating scale) (1)

If a match with a less skilled opponent is desired, then the player's opponent's rating can be given by equation (2):

opponent minimum rating = player rating-offset- (2 x rating scale)

Opponent highest rating = player rating-offset (2)

In equation (2), if the adversary minimum rating is below zero, the result may be shifted up or otherwise increased by an appropriate amount such that the minimum rating is equal to zero. In an embodiment, the offsets in equations (1) and (2) may be defined based on the desired difficulty level previously discussed. For example, if a match with an opponent of extremely high skill or extremely low skill is desired, the offset may be set to a first value. Alternatively, if a match is desired with an opponent with a medium high or medium low skill (or medium), the offset may be set to zero. If a match is desired with an adversary whose skill level is between extremely high/low and moderate, the offset may be set to a third value that is less than the extremely high/low offset value but greater than zero. In an embodiment, the rating scale in equations (1) and (2) may be defined in equation (3) as:

Rating scale = min [ ((ELO minimum rating scale) + (ELO time coefficient × hours)),

(ELO highest rating Scale) ] (3)

Where "ELO minimum rating scale" may be the minimum amount that the game skill level matcher may search for matches within a rating scale above and below the offset, "ELO time coefficient" may be the amount multiplied by the time interval (e.g., minutes, hours) over which the game or tournament is to be rated to determine the rating scale, and "ELO maximum rating scale" may be the maximum amount that the game skill level matcher may search for matches within a rating scale above or below the offset. Other values and definitions of the aforementioned parameters are possible.

If, at block 218, processing logic determines that the player does not meet the second match criteria (e.g., the player does not need to match a skill or high or low opponent), processing logic may proceed to block 226. At block 226, processing logic may determine whether the player meets a third match criterion. For example, the third matching criterion may be whether there is template coverage for the player. If processing logic determines that the player meets the third match criteria, processing logic may execute third player matching module 230. In one embodiment, the third player matching module 230 may be a template overlay matcher. The template may be a match or tournament, and the template option may be a characteristic of the match or tournament, such as a type of match (e.g., paid versus non-paid), an amount of paid versus the match (e.g., 5, 10, 20, etc.), an amount of non-paid versus the match (e.g., 5 virtual tokens, 10 virtual tokens, 20 virtual tokens, etc.), and so forth. If there is template coverage for the player, the template coverage matcher may cover one or more of the template options associated with the player. In an embodiment, processing logic may use the overlaid template options to perform subsequent matches for the player. According to an alternative embodiment, the template overlay matcher may overlay the first template option specified by the player (e.g., the 20-fee-based contest) with a second template option (e.g., the 10-fee-based contest) that facilitates matching when the first template option does not produce a successful match. The second template option may be predetermined (e.g., a prioritized list that may be continuously tried by the template overlay matcher to identify matching template overlay options) or dynamically identified by the template overlay matcher (e.g., based on the number of players that may match different template options).

If, at block 226, processing logic determines that the player does not meet the third matching criteria (e.g., there is no template coverage for the player), processing logic may proceed to block 234 in FIG. 2B. At block 234, processing logic may randomly select a player matching module to match the player. In one embodiment, the present invention may assign an appropriate weight to each or any of the player matching modules to determine which of the modules to randomly select. For example, some embodiments of the invention may use a mapping of key-value pairs, where a key may be the name of the player matching module to be used and a value may be a numerator of the likelihood of selecting a given player matching module. The denominator may be the sum of all values. Other techniques for randomly selecting player matching modules are possible, such as assigning each player matching module a predetermined number and then generating a random or pseudo-random number (scaled appropriately) to select the player matching module having the predetermined number closest to the generated random number. In one embodiment, at block 234, processing logic may randomly select any of the available player matching modules for matching players. According to an alternative embodiment, at block 234, processing logic may randomly select any of a subset of available player matching modules for matching players. For example, a subset of the matchers available may be first player matching module 214, second player matching module 222, and third player matching module 230, respectively, and processing logic may randomly select any of those first three player matching modules for use at block 234.

At block 238, processing logic may determine whether a match for the player has been identified using the randomly selected player matching module from block 234. If processing logic is not able to determine a match for a player using the randomly selected player matching module, processing logic may proceed to block 242. At block 242, processing logic may determine whether the player meets a fourth matching criteria. For example, the fourth matching criterion may be whether an appropriate score distribution is enabled for the mobile game. If processing logic determines that the player meets the fourth match criteria, processing logic may execute fourth player matching module 244. In one embodiment, fourth player matching module 244 may be a feedback loop matcher. For example, the feedback loop matcher may not consider player ratings when looking for matches. Specifically, the feedback loop matcher may operate under the assumption that the score follows a lognormal distribution (or other suitable distribution), which may allow the winning probability to be calculated based on the player score. In some embodiments, fourth player matching module 244 may be configured by changing one or more parameters that may govern the operation of the module. For example, the feedback loop matcher may have a first parameter specifying an amount of deviation from a predetermined winning probability (e.g., 25%, 35%, or other suitable winning probability) that the matcher may use in identifying matches for the player. Other values and parameters for use with the feedback loop matcher are possible.

If, at block 242, processing logic determines that the player does not meet the fourth matching criteria (e.g., does not enable proper score distribution), processing logic may proceed to block 248. At block 248, processing logic may determine whether the player meets a fifth match criterion. For example, the fifth matching criteria may be whether player matching with a skill or high or low opponent is enabled. If processing logic determines that the player meets the fifth match criteria, processing logic may execute fifth player matching module 252. In one embodiment, fifth player matching module 252 may be a loose matcher (LENIENT MATCHER). For example, a loose matcher may be used to more loosely match players in a mobile game. In some embodiments, a loose matcher may be used for senior players, wherein a player may be considered senior if more than a predetermined number of games (e.g., 20 games, 30 games, etc.) have been played in their matched tournament or tournament type (e.g., paid-up tournament or non-paid-up tournament) during the player's lifetime. Any suitable logic may be used to more loosely match players using a loose matcher. For purposes of illustration and not limitation, the loose matcher may allow a player of a highest predetermined percentage of players in the mobile game (e.g., highest 1%, 5%, etc.) to match any other player of the highest predetermined percentage of players in the mobile game. The cut-off value for the highest predetermined percentage may be calculated by identifying all players (for either or both of a paid-up contest or a non-paid-up contest) that have been active for at least a predetermined number of games (e.g., 20 games, 30 games, etc.) for a lifetime, for example, in a previous time interval (e.g., the last 10 days, the last 30 days, the last 60 days, etc.). The loose matcher may include a minimum of two players in the highest predetermined percentage, but any suitable minimum number of players may be used. For purposes of illustration and not limitation, the loose matcher may allow a player of a lowest predetermined percentage of players (e.g., lowest 1%, 5%, etc.) in the mobile game to match any other player of the lowest predetermined percentage of players in the mobile game. The cut-off value for the lowest predetermined percentage may be calculated by identifying all players (for either or both of a paid-up contest or a non-paid-up contest) that have been active for at least a predetermined number of games (e.g., 20 games, 30 games, etc.) for a lifetime, for example, in a previous time interval (e.g., the last 10 days, the last 30 days, the last 60 days, etc.). The loose matcher may include a minimum of two players in a minimum predetermined percentage, but any suitable minimum number of players may be used. According to an embodiment, if the loose matcher does not identify matches within a predetermined amount of time (e.g., 1 hour, 2 hours, etc.), the loose matcher may match the player with any other player having the same or similar winning percentages (e.g., the winning percentages of the two players may be greater than 50% or less than or equal to 50%, although any suitable winning percentages may be used).

At block 248, if processing logic determines that the player does not meet the fifth match criteria (e.g., does not enable the player to match a high or low skill opponent), processing logic may execute sixth player matching module 256. In one embodiment, sixth player matching module 256 may be a rating matcher. For example, the rating matcher may search all available games or tournaments to determine whether any of these games/tournaments involve players whose skill ratings are adequately close to those of the joining players. In one embodiment, the longer the match waits, the wider the searchable rating scale. If one or more suitable matches have been identified, the rating matcher may randomly assign the player to one of the existing tournaments/tournaments or assign the player to one of the existing tournaments/tournaments whose skill rating is closest to the player. In some embodiments, sixth player matching module 256 may be configured by changing one or more parameters that may govern the operation of the module. For example, the rating matcher may have a first parameter specifying a rating scale. The first parameter may be a mapping of key-value pairs, where a key may be a time interval (e.g., minutes, hours, etc.) and a value may be a qualified rating scale to match. For example, if the time interval is in hours, then a 1:80 key value pair may match an 80 scale difference in the first hour. In one embodiment, the rating matcher may use the first parameter to search for a match or tournament and evaluate its suitability as a match in the following manner. First, the rating matcher may determine a rating scale for the match/tournament based on the last updated time stamp of the match/tournament. The rating scale of the game/tournament may be based on the keys of key-value pairs that are less than the time interval (e.g., number of hours) that has elapsed since the last update of the game/tournament. For purposes of illustration and not limitation, the first parameter may have the following key-value pairs: {1:40,4:60,8:80,48:100,100:120}. If the time interval is in hours, then in the case where the tournament was last updated 2 hours ago, the rating scale is 60 based on the key value specified in the first parameter. After 4 hours of tournament performance, the rating scale may be extended to 80. The rating matcher may then compare the ratings of the joined players with the ratings of the tournament/tournament (e.g., based on the players creating the tournament/tournament instance). In one embodiment, if the absolute value of the difference between the two ratings is less than or equal to the rating scale, then the players may be matched. Other values and parameters for use with the rating matcher are possible.

Any suitable number and type of player matching modules may be used in any suitable order to automatically identify matches for users of client applications, according to some embodiments of the present invention. For example, a score matcher may be used that is complementary to or an alternative to any of the player matching modules previously discussed. In an embodiment, the score matcher may match two players if the difference between the average score of the first player and the normalized average score of the second player is within a predetermined percentage (e.g., 1%, 5%, 10%, etc.) of the normalized score of the first player (where the first player may be the first player to participate in the tournament). Additionally or alternatively, the win/loss matcher may be used to match players with similar histories (e.g., two players each winning or losing 10 games in succession) without regard to any ratings. In one embodiment, if the absolute value of the difference between the game win/loss length of the first player and the game win/loss length of the second player is less than a predetermined win/loss threshold (e.g., 2, 3, 4, etc.), then the win/loss matcher may match the two players. Additionally or alternatively, the win-loss rate matcher may be used to win or lose at a high rate and should match an opponent with either a high or low challenge to improve the athletic experience. A history of the last predetermined number of games (e.g., 10, 15, 20, etc.) of the player may be saved. If the player has at least a predetermined percentage of the last predetermined number of games wins or loses (e.g., 60%, 80%, etc.) (and the most recently played game is winning or losing as desired), the win-loss rate matcher may assign the next match time to a predetermined time interval (e.g., 1 hour, 4 hours, 6 hours, 8 hours, etc.) in the future, i.e., the least time that the tournament may be first matched. Additionally or alternatively, a robot matcher may be used to match players with robots. In an embodiment, the robot matcher may be used to match players to robots, rather than to match players to humans, which are software applications programmed to perform certain tasks (e.g., playing mobile games). For example, a player may be matched with a robot when the player is a novice for a mobile game and first learns how to play the mobile game (e.g., for training or coaching purposes). Additionally or alternatively, a player may be matched with a robot when no other human matches are found (e.g., in a mobile game with little or no available players in the pool of players). Additionally or alternatively, when a player should match a skill or high or low opponent, the player may match the robot (e.g., the player is in a winning or continuous loss state and may match an opponent based on a robot with a high or low challenge, respectively, to improve the athletic experience). Additionally or alternatively, suitable machine learning/artificial intelligence techniques may be used to match players. For example, a machine learning model may be trained based on data from all players in a mobile game. The machine learning model may then be used to dynamically match players of a tournament or tournament. The machine learning model may be updated or otherwise adjusted as the player's characteristics evolve over time (e.g., changing the win or loss rate and experience level, preferences for certain games over others, etc.). According to some embodiments of the invention, the number, type, and order of matching modules, and the criteria for selecting each of those modules, will depend on, for example, the characteristics of the user and the client application being matched. For example, the number, type, and order of matching modules, and criteria for selecting each of those modules, may be dynamically and automatically updated by the machine learning model as the characteristics of the player evolve over time.

Each of the player matching modules may attempt to match a player with another player according to criteria and methods established for the respective player matching module. In an embodiment, the matching performed by each or any of the player matching modules may be limited to a predetermined time interval (e.g., 1 hour, 1 day, etc.) such that the matching does not continue indefinitely. According to this embodiment, if no match is found within a predetermined time interval, the player may be automatically awarded a winning of the tournament or tournament. Alternatively, if no matches are found within a predetermined time interval, some embodiments of the invention may select a different matching module (e.g., randomly, such as discussed with respect to block 234 of FIG. 2B, or in a prioritized order) to attempt to identify a match. If the selected matching module does not identify a match, another matching module may be selected (e.g., randomly). This process may continue until a match is found or an appropriate amount of time has elapsed since the player initially requested to join the tournament or tournament (and may be declared the winner, for example).

As previously discussed, some embodiments of the invention may be used in and with any suitable type of client application (e.g., asynchronous or synchronous client application). In one embodiment, the client application may be an asynchronous mobile game. In an asynchronous mobile game, players do not need to play at the same time. For example, in an asynchronous mobile game, a first player may request to join a tournament or tournament, which may enable player matching techniques of some embodiments of the present invention. The first player may participate in a tournament or tournament when some embodiments of the invention search for an appropriate match for the first player. Once a match is found, the identified second player may be engaged in a tournament or tournament (if not already done, because the first player may join the tournament or tournament after the second player). In contrast, in synchronous mobile games, players need to play simultaneously with each other because players compete with each other in real-time (e.g., billiard games, etc.). Thus, the synchronous mobile game should not start until after the player matching is completed.

In accordance with some embodiments of the present invention, additional or alternative player matching modules may be used with client applications, such as synchronous mobile games, that require matching to be accomplished before users can interact with each other in the client application-and typically matching is accomplished more quickly. In one embodiment, a quick match matcher may be used to synchronize mobile games. For a quick match matcher, players may enter a quick match queue and select one or more template options that each player is interested in playing. The template options may be characteristics of the tournament or tournament that the player wants to play in the synchronous mobile game, such as the type of tournament (e.g., paid versus non-paid), the amount of paid-in tournament (e.g., 5, 10, 20, etc.), the amount of non-paid-in tournament (e.g., 5 virtual tokens, 10 virtual tokens, 20 virtual tokens, etc.), the pool of credits, rules of tournament patterns (e.g., 58 balls in billiard games versus 5 trick play patterns, etc.), and so forth.

The quick match matcher may allow the player to enter a queue of multiple templates simultaneously, which may allow for significantly faster matching times. The quick match matcher extension technique may determine the speed and order in which players enter the queue (i.e., queue) for each template. When a player selects multiple templates, the player may queue into each template in descending order from, for example, the highest value to the lowest value (e.g., as determined by the points rather than the participation fees). For example, the quick match matcher may begin with the highest value paid-up contest template, then traverse down all paid-up contest templates, then all non-paid-up contest templates in descending order. For purposes of illustration and not limitation, the player may select the following templates: each of the 5-wagered contest, 20-wagered contest, 5-virtual-token non-wagered contest, and 20-virtual-token non-wagered contest, wherein each of the values may represent a value of credit (although in an alternative embodiment, the value may represent a contest fee). In this example, the player may queue in the following order: 20-fee contests, followed by 5-fee contests, followed by 20-virtual-token non-fee contests, and followed by 5-virtual-token non-fee contests. As another example, a player may select a template for two 20-fee contests but with different patterns of comparison (e.g., one template for a stunt shot in a billiard mobile game and another template for an 8-ball). In such embodiments, each comparison pattern may have an associated priority that may be used to break "ties (ties) between templates of equal value. In this illustration of a billiard game, the trick play mode may have a higher priority such as one, while the 8-ball mode may have a lower priority such as two. Other priority values are possible. Thus, the template with the higher priority (e.g., the trick play mode with priority one) may be ranked first, the template with the next highest priority (e.g., the 8-ball mode with priority two) may be ranked second, etc. Such prioritization may also be used to determine the order in which the tournament patterns may be displayed on the screen of the player's client device (e.g., the tournament pattern with the highest priority may be displayed at the top or first, the tournament pattern with the next highest priority may be displayed below the highest priority or second, etc.). When the player does not match the first template for a particular amount of time, the player may then enter a queue of second templates (e.g., while still remaining in the queue of first templates), and so on, until the player matches.

In an embodiment, the quick match matcher (and/or any of the matchers discussed and described herein) may be based on the participant design pattern. For example, each template may have or otherwise be associated with a participant (e.g., one participant per template). The participant design pattern is a model of concurrent computation that treats the participant as a basic computational unit. The participant defines a certain behavior or logic to be performed and instructs the other participants to perform their behavior using a suitable communication method. The defined behavior for the participant is asynchronous, so the participant does not wait for a response. Instead, the participant will continue processing and receive a response at some later point in time. All communications are through messaging, where messages are processed one at a time in the order they were received. In response to the message it receives, the participant may perform appropriate calculations or perform appropriate logic, such as making local decisions, creating more participants, sending more messages, and determining how to respond to the next message received. Participants may modify their own personal status, but may only affect each other indirectly through messaging. Participants are isolated from each other and do not share memory-storage is "shared-nothing," meaning that private data is isolated and only accessible by owning participants. Such properties allow for large scale and efficient expansion. For example, participants may support linear expansion to hundreds or thousands of servers without redesigning the architecture. Participants may also support location transparency to facilitate addressing computing units both locally and non-locally so that the participants may reside on any server without having to redesign the architecture. Participants may also support lock-free data manipulation, eliminating the need for lock-based synchronization. Because of the rules of one message at a time, there is no need to lock the data, thus preventing race conditions. The participant design pattern may more efficiently handle a large number of user queues and attempt to identify matches in multiple templates simultaneously. Other design patterns of the quick-match matcher (and/or any of the other matchers discussed and described herein) are possible.

FIG. 3 illustrates a first user interface 300 for entering a queue of multiple templates having multiple game modes, according to an embodiment of the present disclosure. For purposes of illustration only and not limitation, user interfaces and associated techniques for accessing a queue of multiple templates will be discussed in the context of a synchronous mobile game. However, such user interfaces and associated techniques may be used for synchronous or asynchronous mobile games. As shown in fig. 3, the top bar 305 may display a carousel of available game modes. In one embodiment, the player may select all game modes or a particular game mode to display the corresponding template. In additional embodiments, the player may select a combination of game modes to display the corresponding templates. The type and number of available game modes will depend on, for example, the synchronous mobile game played by the player. For example, the carousel of the top bar 305 may scroll horizontally when more game modes are available than can be displayed within the first user interface 300. For example, in a synchronous billiard mobile game, the top bar 305 may include all play patterns 310, a long target pattern 315, a short target pattern 320, and other similar play patterns. The top bar 305 may default to, for example, all play modes 310 or other suitable play modes. In one embodiment, selecting a game mode from the top bar 305 may filter out other game modes from the top bar 305.

According to an embodiment, the first user interface 300 may include a plurality of templates 325 for each game mode, which may be comprised of paid-up participating templates, non-paid-up participating templates, or a mixture of both. Other templates are possible. In one embodiment, the available templates may be grouped by, for example, gaming mode. According to one embodiment, each game mode may be used as a quick match set in which opponent matches are to be identified. In other words, the quick match matcher may use templates selected by the player for a particular game mode to identify opponent matches for that game mode. For purposes of illustration and not limitation, a player having selected one or more templates in the long target pattern 315 may be matched by a quick match matcher to an opponent having selected one or more corresponding templates in the long target pattern 315. The quick match set may be made up of all templates within or otherwise associated with the game mode (e.g., as determined by tournament parameters defining rules of the game mode). In an alternative embodiment, the quick match group may be made up of templates of different game modes (e.g., each template in a group may enumerate game modes in addition to a pool of credits, participation fees, and the like). When grouped by game mode, the plurality of templates 325 may be identified by a game mode name 330 displayed in a banner over or near the plurality of templates 325. In the exemplary illustration of fig. 3, the plurality of templates 325 for the long target pattern 315 may include at least seven paid-up contest templates (which may vary based on the pool and contest fees) and two non-paid-up contest templates (which may vary based on the pool). The player may access additional templates for the game mode (if they exist) by, for example, scrolling vertically. Other templates, combinations of templates, and any suitable number of templates for each game mode are possible. The plurality of templates 325 may be ordered in any suitable manner, such as by priority, by pool or entry fee (ascending, descending, or random order), and so forth. In one embodiment, the plurality of templates 325 may be ordered in an ascending order of paid-up competition credits, followed by an ascending order of non-paid-up competition credits, and so forth.

According to an embodiment, the first user interface 300 may include a first bottom bar 335 for displaying a carousel of template selections. The template selections may be displayed in the same order as previously discussed for the plurality of templates 325. In an alternative embodiment, the template selections may be displayed in the order selected by the player for a given gaming mode or even randomly. The name 350 of the game mode for which the template was selected (e.g., the long target line mode 315) may be displayed over or near the first bottom bar 335. If the player first selects the first template 340, the first template 340 may be displayed in a first open position 345 (e.g., leftmost position) in the first bottom column 335. As the player makes additional template selections, those template selections may be placed in the next successive open position in the first bottom column 335. Thus, the player may create a prioritized list of templates that the player wishes to participate in, with the highest priority template at one end (e.g., the leftmost position in the first bottom column 335), and subsequently successively lower listed templates. Once the player selects the desired template from the plurality of templates 325 for a given game mode, the player may press the "find opponent" button 355 to match an opponent through the quick match matcher in the manner described herein.

Since there may be multiple game modes supported by the first user interface 300, the player may scroll (e.g., vertically, or in an alternative embodiment, horizontally) to view the remaining game modes and corresponding templates for selection. To select templates from different game modes, an additional bottom bar may be included as a separate row for each game mode. FIG. 4 illustrates a second user interface 400 for entering a queue of multiple templates with multiple game modes, according to an embodiment of the present disclosure. The second user interface 400 may include features similar to those discussed with respect to the first user interface 300 in fig. 3. However, FIG. 4 may include a second bottom bar 405 corresponding to a second game mode (e.g., short target line mode 320). In an embodiment, the user interface may have a minimum of one bottom bar (e.g., first bottom bar 335 in first user interfaces 300 and 400). The additional bottom rail may be a separate rail or an extension of the first bottom rail 335 (e.g., wraparound). The carousel of template selections may be displayed in the same order as previously discussed for the plurality of templates 325. In an alternative embodiment, the template selections may be displayed in the order selected by the player for the second gaming mode or even randomly. The name 410 of the second game mode (e.g., short target line mode 320) for which the template is selected may be displayed above or near the second bottom bar 405. If the player first selects a first template for a second gaming mode, the first template may be displayed in a first open position 415 (e.g., leftmost position) in the second bottom bar 405. When the player makes additional template selections for the second gaming mode, those template selections may be placed in the next successive open position in the second bottom column 405. Thus, a prioritized list of templates that the player for the second gaming mode wishes to participate in may be created and displayed, with the highest priority template at one end (e.g., the leftmost position in the second bottom column 405) and subsequently sequentially enumerating the sequentially lower priority templates. In an embodiment, such prioritization may be created and managed by server system 114 (e.g., by a system administrator, etc.). In an alternative embodiment, the player may create a prioritized list of templates. Any suitable number of bottom bars may be used to display template selections for each game mode, depending on the number of game modes displayed and supported. In this way, both the game patterns and templates may be prioritized (e.g., by a system administrator of server system 114 or by a player) within each game pattern used to find a match. In one embodiment, the player may open the bottom fields to display all selected gaming modes or minimize either or both bottom fields so that, for example, the top gaming mode is displayed while the remaining gaming modes are hidden.

According to one embodiment, once the player presses the "find opponents" button 420, the quick match matcher may begin by analyzing the set of all selected templates and browsing the templates (regardless of the game mode) in descending order of, for example, the wagered-on-play points, followed by descending order of the non-wagered-on-play points. If the integral values between two game patterns with selected templates are equal, then higher priority templates (e.g., templates with priority 1, templates with priority 2 next, templates with priority 3 next, etc.) may be ranked first. For purposes of illustration and not limitation, a player may select the following templates for a billiard game: 208 balls (match mode priority 1); 20 stunt shots (match mode priority 2); 58 balls (match mode priority 1); 5 trick shots (game mode priority 2); 1 virtual token stunt ball (game play priority 1). The order in which matches are queued for searching may be as follows: 208 balls; 20 stunt shots; 58 balls; 5, special stunt batting; 1 virtual token stunt stroke. In an alternative embodiment, the quick match matcher may start with the highest priority template in the first bottom row 335 and browse (progress through) the list of templates in that row to find the appropriate match. If no matches are identified in the first bottom row 335, the quick match matcher may proceed to the second bottom column 405. The quick match matcher may attempt to identify matches starting with the highest priority template in the second bottom column 405 and browse the list of templates in the row for an appropriate match. The quick match matcher may browse each row for each game pattern until a suitable match is found. In either embodiment, the player may remain in a queue of one or more previous templates while queuing into one or more additional templates to maximize the ability of the quick match matcher to identify matches. Other ways of the quick match matcher traversing the templates to identify matches are possible.

In an embodiment, if the quick match matcher is unable to identify matches based on the selected templates, the quick match matcher may prompt the player to play one or more different templates, such as alternative synchronous mobile game templates and/or asynchronous mobile game templates. The quick match matcher may display or cause to be displayed in the user interface an appropriate notification to the player to indicate to the player whether or not they want to match in a different (other) template. This prompt may be made, for example, when the quick-match matcher identifies that the player does not match its selected template (e.g., does not identify a match for a predetermined amount of time) but identifies a second player (in the same game, but in the same or a different game mode) with a different selected template. In an embodiment, the quick match matcher may be configured for allowable rollbacks to prevent certain rollbacks from being provided to one or more players (e.g., disabling robot template rollbacks, disabling asynchronous rollbacks of synchronous templates, and vice versa, etc.). Additionally or alternatively, the quick match matcher may prompt the player to add templates to their selections to increase the chance of a successful match (e.g., by adding popular templates or templates with higher player mobility).

In an embodiment, the quick match matcher may dynamically add templates or remove templates from the plurality of templates 325 when the respective player liquidity threshold is met. For example, a player may be provided with a first plurality of templates 325, such as the set of templates shown in FIG. 3 or FIG. 4. The quick match matcher may obtain and maintain in real-time the number of players available to match each template, average match latency, match success rate, total queue, and other similar information to determine player liquidity in real-time. Each template may have an associated player liquidity threshold associated with each template. For purposes of illustration and not limitation, the player liquidity threshold may indicate, for example, a minimum number of players required by the quick match matcher to produce a successful match for the template, but the player liquidity threshold may be based on other suitable factors or combinations of factors (e.g., found players, average waiting time, etc.). The player liquidity threshold may be the same or different from template to template. For example, templates with less entries (e.g., 1.80) may have a higher player liquidity threshold because more players may generally be found and the average latency for a player to match in a tournament with less entries is lower. However, templates with more entries (e.g., 120) may have lower player liquidity thresholds because fewer players are typically found and the average latency of a player to match in a tournament with more entries is longer. In one set of templates, the quick match matcher may remove a template from the set of templates displayed or otherwise presented to the player when player liquidity falls below a player liquidity threshold for the template. The quick match matcher may add a template to a set of templates displayed or otherwise presented to the player when player liquidity rises above a player liquidity threshold for the template. With such dynamic template scaling, a player may be presented (either continuously or at predetermined time intervals) with an updated set of templates, which may maximize the chance of a successful match. Additionally or alternatively, each template may be associated with one or more times or time ranges such that the quick-match matcher may add certain templates to or remove certain templates from each set of templates for the player at or within a predetermined time.

In an embodiment, the quick match matcher may dynamically modify the player matches for each or any of the templates based on the player liquidity threshold. For example, as player liquidity increases above (or within) a predetermined threshold, the quick match matcher may provide a tighter match for each or any of the templates, as there may be more players available for matching. Conversely, when player liquidity decreases below a predetermined threshold (or outside a predetermined threshold range), the quick match matcher may provide a wider match for each or any template, as fewer players may be available for matching. For example, a quick match matcher may provide a tighter or more extensive match by appropriately updating parameters used for the ELO extension, such that more or less time may be spent expanding a wider or tighter maximum range of ELO differences between two players, where the quick match matcher will allow the two players to match each other. In this way, the quick match matcher may respond to player liquidity in real-time to maximize the probability of successfully matching players. Additionally or alternatively, the quick-match matcher may dynamically modify the player matches for each or any of the templates based on the time of day or other suitable parameters such that the quick-match matcher may modify the player matches at or within a predetermined time range. Additionally or alternatively, the quick match matcher may use suitable machine learning/artificial intelligence techniques to match players. For example, a machine learning model may be trained based on player liquidity data for each or any of the templates to optimize, for example, the time of successful matches. The machine learning model may then be used to dynamically match players for each or any of the templates. The machine learning model may be updated or otherwise adjusted as player mobility changes over time.

In one embodiment, to enhance or otherwise promote player mobility of one or more templates, the quick match matcher may display or cause to be displayed in a user interface an appropriate modality to prompt the player to play certain synchronous mobile games or certain game modes of those synchronous mobile games. Additionally or alternatively, the quick match matcher may display or cause to be displayed a conversation message in the conversation user interface to prompt the player to play certain synchronous mobile games or certain game modes in those synchronous mobile games. The quick match matcher may automatically display such cues when the player liquidity level (typically for a game or for one or more templates) falls below a suitable player liquidity threshold. The player cue may continue until the player liquidity level is greater than or equal to the player liquidity threshold for a predetermined time interval, and so on. Additionally or alternatively, the quick-match matcher may display or cause to be displayed such cues at or within a predetermined time or range.

FIG. 5 illustrates a third user interface 500 for entering a queue of multiple templates with a single gaming mode, according to an embodiment of the present disclosure. In an embodiment in which multiple game modes are not available, third user interface 500 may display a single game mode (e.g., long target line mode 505). The third user interface 500 may include features similar to those discussed with respect to the first user interface 300 in fig. 3 and the second user interface 400 in fig. 4. However, because a single game mode is available, the third user interface 500 does not include a top bar, but may include this feature as desired. The player may scroll vertically through multiple templates 510 associated with a single gaming mode (if such templates cannot all be displayed on the screen). The third user interface 500 may include a bottom bar 515 that may operate in a similar manner as the first bottom bar 335 shown in fig. 3. The third user interface 500 will not support multiple (i.e., second or more) bottom bars because in such embodiments, the third user interface 500 displays a single game mode. In one embodiment, the bottom bar 515 of the third user interface 500 cannot be minimized or hidden because only one game mode is provided. The name of the game mode may be displayed above or near the bottom bar 515, but may be removed from the display as desired. Once the player selects the desired template from the plurality of templates 510 for a single gaming mode, the player may press the "find opponent" button 520 to match an opponent through the quick match matcher in the manner described herein.

The rate at which players are queued into each template may be determined by suitable expansion techniques. In one embodiment, for example in equation (4), the quick match matcher expansion technique may be a linear algorithm:

Y ＝ mX + b (4)

In equation (4), the variable Y may be the total time from entering the first queue, the variable X may be an extension index from 0, the constant b may be a first time interval (e.g., in seconds) that fast matches the length of time the matcher waits before entering the second selected template, and the constant m may be a second time interval (e.g., in seconds) that fast matches the length of time the matcher waits before moving from the second selected template to the third selected template, from the third selected template to the fourth selected template, and so on.

According to an embodiment, the variable X may represent how many additional queues have been entered from the first queue. When x=0, the player is in one queue and waits Y (0) until the next queue is entered. When x=1, the player is in two queues in total, and enters the third queue after waiting Y (1) time. Y (1) -Y (0) time elapses between entering the second queue and entering the third queue. For purposes of illustration and not limitation, with m=1 and b=1 (i.e., y=x+1), the player may select the template discussed above. For purposes of illustration and not limitation, the player may select the following templates: 5-fee, 20-fee, 5-virtual-token non-fee, and 20-virtual-token non-fee contests. In this example, the player may queue in the following order: 20-fee contests, followed by 5-fee contests, followed by 20-virtual-token non-fee contests, and followed by 5-virtual-token non-fee contests. Using equation (4) for the quick match matcher, the player immediately enters a queue of 20-fee contests. After one second (y=1×0+1=1), the player enters a queue of 5-fee entries. After an additional one second (two seconds total, i.e., y=1×1+1=2), the player enters a queue of 20 virtual token non-paid contests. After an additional one second (three seconds total, i.e., y=1×2+1=3), the player enters a queue of 5 virtual token non-paid-up contests. According to an alternative embodiment, m and b may each be set to zero to allow the player to enter all of the queues simultaneously.

In another embodiment, the quick match matcher expansion technique may be a logarithmic algorithm, such as equation (5):

Y ＝ ln(mX + b) + c (5)

In equation (5), the variables and parameters are defined similarly to those discussed with respect to equation (4), where the constant c may be a third time interval (e.g., in seconds) that controls the speed at which the logarithmic algorithm expands to the subsequent templates. Thus, the logarithmic algorithm of equation (5) can be extended slowly to the second template and then extended quickly to all other templates. For purposes of illustration and not limitation, let m=1, b=1, and c=5 (i.e., y=ln (x+1) +5), and the player selects the template discussed above. The player immediately queues into the first template. The player queues into the second template after y=ln (1×0+1) +5=5 seconds. The user then enters the third queue after y=ln (1×1+1) +5= -5.7 seconds. The user enters the fourth queue after y=ln (2×1+1) +5= -6.1 seconds.

In another embodiment, for example in equation (6), the fast matcher expansion technique may be an exponential algorithm:

Y ＝ e^(mX + b) + c (6)

In equation (6), the definitions of variables and parameters are similar to those discussed with respect to equation (5). Thus, the exponential algorithm can be extended quickly to the second template and then slowly to all other templates. For purposes of illustration and not limitation, let m=1, b=1, and c=5 (i.e., y=e++1) +5), and the player selects the template discussed above. The player immediately queues into the first template. The player queues into the second template after y=e++1+1) +5= -7.7 seconds. The user then enters the third queue after y=e++1+1) +5= -12.4 seconds. The user enters the fourth queue after y=e++1+1) +5= -25.1 seconds.

In some embodiments, the constants m, b, and c may be customizable and may vary between each expansion technique. For example, the expansion technique may be set on a per game basis, on a per template group basis, specific to an individual template ID, on a contest type level (e.g., paid-up or non-paid-up contests), and so forth. For example, one expansion technique may be used for a first mobile game, while another expansion technique may be used for a second mobile game, and so on. According to an embodiment, the quick match matcher configuration may apply different extension techniques to the mobile game at different times of the day. For example, a linear expansion algorithm may be used from 6 am to 6 pm, a logarithmic expansion algorithm may be used from 6 pm to 12 am, and an exponential algorithm may be used from 12 am to 6 am. Other expansion techniques are possible in other orders and at other times. Additionally or alternatively, variables and parameters for each of the expansion techniques may be modified based on, for example, the time of day. For example, the quick-match matcher may modify variables and parameters to provide a tighter match during peak hours, while the quick-match matcher may modify variables and parameters to provide a wider match during off-peak hours.

According to an embodiment, the ELO rating matcher may be used to synchronize mobile games. Additionally or alternatively, the ELO rating matcher may be used for asynchronous mobile games. The ELO rating matcher expansion technique may determine a speed of a player's possible rating scale expansion for matching. In one embodiment, for example in equation (7), the ELO rating matcher may use an exponential scaling algorithm:

Y ＝ min(a + b*e^(X/c), d) (7)

In equation (7), variable Y is the rating difference, variable X is the length of time that it waits before matching, constant a is the lowest rating of an immediate match, constants b and c are scaling factors, and constant d is the highest rating difference. In an embodiment, the values of a, b, c, and d may be adjusted based on, for example, a template or template type basis (e.g., a paid versus a non-paid contest). In one embodiment, the ELO rating matcher may be used for event-based expansion. For example, when a player enters a queue, the ELO rating matcher may cycle through all players in the queue and schedule messages to match for a predetermined number of seconds based on the rating differences. If a player already matches another player when his message is processed, no further matches are needed. In such embodiments, because the matches are event-based, the matches performed by the ELO rating matcher should be reciprocal (reciprocal) in the rating difference when the player enters the queue. For purposes of illustration and not limitation, the first player is presented with an ELO of 1200. The first player requests a synchronized tournament and enters a queue. The following three players wait in the queue: a second player having an ELO of 400; a third player having an ELO of 1400; and a fourth player with an ELO of 1500. In this illustration, for equation (7), let a=200, b=2, c=2, and d=800. Thus, the ELO rating matcher may immediately match the first player with any player with a rating below 200, which will extend to 800 points within 10 seconds (and if d=800, the upper limit may be 800, otherwise d will need to be modified). In this illustration, the ELO rating matcher may immediately match the first player with the third player because its rating difference is 200 and a=200, while the ELO rating matcher takes about 7 seconds to match the first player with the fourth player (with a rating difference of 300) and about 12 seconds to match the first player with the second player (with a rating difference of 800).

In one embodiment, the ELO rating matcher may dynamically adjust the expansion algorithm parameters. For example, the expansion algorithm parameters may be dynamically adjusted based on real-time player liquidity. The ELO rating matcher may use a predetermined player liquidity threshold to determine when the extended algorithm parameters may be adjusted. For example, when player liquidity is below a predetermined player liquidity threshold, the ELO rating matcher may adjust the expansion algorithm parameters to provide a wider match (e.g., by increasing the highest rating difference) because fewer players may be available for matching. Alternatively, when player liquidity is above a predetermined player liquidity threshold, the ELO rating matcher may adjust the expansion algorithm parameters to provide a tighter match (e.g., by reducing the highest rating difference) because there may be more players available for matching. Additionally or alternatively, the ELO rating matcher may modify the extended algorithm parameters based on, for example, the time of day. For example, the ELO rating matcher may modify the extended algorithm parameters to provide a tighter match during peak hours, while the ELO rating matcher may modify the extended algorithm parameters to provide a wider match during off-peak hours.

Additionally or alternatively, the ELO rating matcher may adjust the expansion algorithm parameters such that the ELO rating may be asymmetrically expanded. In such embodiments, the ELO rating matcher may use different upward and downward ELO extensions to expand more quickly in one direction than in the other. Thus, the ELO rating matcher may use different expansion algorithm parameters to expand up and down. For purposes of illustration and not limitation, the downward expansion algorithm parameters may provide faster expansion than the upward expansion algorithm parameters. In this illustration, the first available opponent may be 100ELO lower than the player, while the second available opponent may be 75ELO higher than the player. In this illustration, even though the first available opponent is farther from the player, the matching with the first available opponent may be through the ELO rating matcher due to the asymmetric expansion caused by the faster downward expansion. Such asymmetric matches may be bucket-based (pocket) so that players may match opponents of the same bucket or group of players. If no matches are found within the bucket within a predetermined amount of time, the ELO rating matcher may extend the matches to opponents in different buckets.

According to an embodiment, a quick match matcher and an ELO rate matcher may be used in combination to perform matching in, for example, synchronous mobile games and other similar client applications, but the quick match matcher and the ELO rate matcher may be used in asynchronous mobile games and other similar client applications. As previously discussed, the quick match matcher may allow a player to simultaneously enter a queue of multiple templates. When a player selects multiple templates, they may queue into each template, for example, in descending order. As a player enters each queue, a corresponding ELO rating matcher may be used to match the player with other players waiting in the corresponding queue. For purposes of illustration and not limitation, players may be queued by the quick-match matcher in the following order: 20-fee contests, followed by 5-fee contests, followed by 20-virtual-token non-fee contests, and followed by 5-virtual-token non-fee contests. The player will immediately enter a queue of 20-fee entries, which will activate the ELO rating matcher for 20-fee entries. After one second (e.g., using the linear algorithm of equation (4) where m=1 and b=1), the player enters a queue of 5-fee entries, which will activate the ELO rating matcher for the 5-fee entries. After an additional second (2 seconds total), the player enters a queue of 20 virtual token unpaid contests, which will activate the ELO rating matcher for 20 virtual token contests. After an additional second (three seconds total), the player enters a queue of 5 virtual token unpaid entries, which will activate the ELO rating matcher for 5 virtual token entries. However, either or both of the quick match matcher and the ELO rate matcher may be used alone, together, or in any combination with either or all of the player matching modules previously discussed to achieve a preferred match in as short a time as possible.

According to an embodiment, to facilitate matching with either or both of the quick match matcher and the ELO rating matcher, players may be categorized into groups or "buckets" based on any suitable characteristics of those players, such as skill ratings, total number of games played, number of synchronous games played, number of asynchronous games played, and the like, or any combination thereof. Other player characteristics are possible. For example, a "novice" player having played less than a predetermined number of games may be categorized as a first bucket. Other "experienced" players may be categorized into buckets according to, for example, their skill ratings for mobile games, where each bucket may have a corresponding skill range. Additionally or alternatively, the experienced players may be categorized into buckets according to the number of games played (e.g., the total number of synchronous games, asynchronous games, etc.), the number of winning games (e.g., the total number of synchronous games, asynchronous games, etc.), wherein each bucket may have a corresponding number of games played, the number of winning games, etc., or any combination thereof. Other characteristics for the tub are possible. Any suitable number of such buckets may be used, and each bucket may be associated with any suitable characteristic of the client application. Additionally or alternatively, each bucket may be associated with an ELO expansion algorithm. According to an embodiment of the invention, players may be matched with players in the same bucket. However, for some player matching modules, if, for example, the second characteristic is within a predetermined variance or range of the first characteristic, then players in a bucket associated with the first characteristic may be matched with players in another bucket associated with the second characteristic. Additionally or alternatively, matches within a player's bucket may continue for a predetermined amount of time before the matches are expanded to other players' buckets. In other words, in intra-bucket matching, the player's totality of matches may be limited to the player's bucket for a first predetermined amount of time (e.g., seconds). If the players do not match within the amount of time, the match may be expanded to include players from other buckets (i.e., inter-bucket matches), such as players that expand beyond their respective time windows. Additionally or alternatively, different variables and parameters for the various expansion techniques may be assigned to or otherwise associated with each bucket, and each set of variables and parameters may be appropriately modified by the matcher, e.g., dynamically (e.g., based on real-time player liquidity), based on time of day, etc.

Users of the client application (e.g., players in a mobile game) may be rated or otherwise characterized or categorized in any suitable manner. In one embodiment, the novice player may begin at a first predetermined rating level. Once the tournament or tournament is over, ratings may be calculated and adjusted for all players. For example, the ratings of each player may be calculated using various suitable factors (as discussed below), then the ratings of the winners may be calculated, and then the ratings of the losers may be calculated. The new ratings for each player may then be saved to their associated game account or online profile. In one embodiment, if the actual outcome of the tournament is determined by the processing logic (based on the player's ratings) to be highly likely, the participating players may see minimal changes in ratings. However, if processing logic determines that a less likely outcome, such as a low-ranking player defeating a high-ranking player, the outcome may be a larger ranking change.

According to an embodiment of the present invention, when a match or tournament ends, an initial change in the player's rating may be calculated based on, for example, the match result (winning, losing or tie) and the rating difference between the player and its nearest opponent. Such initial changes (e.g., values between-1 and 1) may then be multiplied by a "k factor (kFactor)" to determine the actual rating change. kFactor for a given match may depend on various appropriate parameters. In an embodiment, parameters related to kFactor may be the same for each game and may be based on appropriate game-related behavior. For example, a player playing a first predetermined number (e.g., 5, 10, 15, etc.) or less of games may have a first kFactor (e.g., 100, 110, 120, etc.). A player playing a second predetermined number (e.g., 20, 25, 30, etc.) or less of games may have a second kFactor (e.g., 50, 60, 70, etc.). Players rated greater than a third predetermined number (e.g., 1600, 1700, 1800, etc.) may have a third kFactor (e.g., 10, 20, 30, etc.). Players rated greater than a fourth predetermined number (e.g., 1300, 1400, 1500, etc.) may have a fourth kFactor (e.g., 5, 10, 15, etc.). All other players may have a fifth kFactor (e.g., 20, 25, 30, etc.). Other types and values of kFactor are possible. In some embodiments, kFactor for an old-hand player may be set to zero if the old-hand player matches the new-hand player (e.g., the new-hand player plays less than a certain number of games). If the first new player matches the second new player, kFactor for the first new player may be reduced by a predetermined amount (e.g., 50%, 60%, etc.), which may also reduce kFactor for the second new player by a corresponding amount. For games where there are three or more players, the calculation may proceed as follows. First, players may be categorized by score and then by rating. The winner (e.g., the first player) may be considered to win the game with the highest ranking opponent. A loser (e.g., last player) may be considered to be given an input to the player directly above it. All other players (e.g., in the middle) may be considered winning players immediately below and losing players immediately above. In one embodiment, if a tie occurs in any one game, this result may be considered instead of the win/lose discussed previously. Other techniques for calculating or otherwise determining player rating levels are possible.

In an alternative embodiment, any or all of the predetermined values discussed above may be dynamically determined. According to alternative embodiments, the processing logic and any or all of the first player matching module 116, the second player matching modules 118, … …, the nth player matching module 120 may use suitable machine learning/artificial intelligence techniques to dynamically select or otherwise select appropriate values for any or all of the predetermined values and/or parameters discussed above. For example, one or more machine learning models may be trained based on data from either or both of player data database 120 and game data database 122. One or more machine learning models may then be used to dynamically select an appropriate value for each or any of the foregoing variables based on, for example, the characteristics of the player (e.g., skill level/rating, winning, losing, score, time, etc.), the characteristics of the mobile game (e.g., type of game or contest), and other similar characteristics or data. One or more machine learning models may be updated or otherwise adjusted as characteristics, results, and other similar data associated with players and mobile games evolve over time.

FIG. 6 is a block diagram illustrating an exemplary computer-implemented method 600 of automatically determining a proper match for a user of a client application based on a plurality of interaction templates selected by the user. The method 600 may begin at block 605, where a request may be received from a first user of a plurality of users of an application client executing on respective mobile devices of the plurality of users to interact with one or more other users of the plurality of users in the application client based on a first plurality of interaction templates selected by the user. At block 610, a second user of the plurality of users may be determined. The second user may be associated with a second interaction template, and the determination of the second user may be based on an identification of a match between the second interaction template and a first interaction template from the first plurality of interaction templates. At block 615, interactions between the first user and the second user may be initiated in the application client in response to the determination of the second user.

According to some embodiments of the present invention, systems and/or methods for switch back testing may be used in conjunction with the player matching functionality described herein to allow testing functionality while also accounting for bias measured before and after. In some embodiments, the toggle test method may alternate between the test process and the control process for one or more of the player matching techniques described herein (including, for example, the quick match matcher and ELO rating matcher described above), and the alternating may be performed according to a predetermined toggle test protocol. In some embodiments, the test and control processes may be applied to one or more configuration parameters of player matching techniques including gaming algorithms, monetary algorithms, template algorithms, and bucket level algorithms. In some embodiments, the predetermined toggle test protocol may be a randomized protocol.

For purposes of illustration and not limitation, for example, the predetermined protocol may dictate that one or more of the player matching techniques described above will be used on a first day, then not used on a next second day, and then used again on a next third day, and continue to alternate back and forth between being used and not used daily for the number of days prescribed by the test protocol. The results of the matches by the player on days of using one or more player matching techniques may be compared to the results of the matches by the player on days of not using one or more player matching techniques and further provide a measure of the effectiveness of the one or more player matching techniques. Although the present illustration describes alternating days, embodiments of the invention may alternate using any suitable period of time, such as minutes, hours, days, weeks, etc. By using this toggle test method, optimizations for the player matching techniques described herein may be more effectively tested.

Fig. 7 is a block diagram of an example computing device 700 that may perform one or more operations described herein, according to an embodiment of the invention. Computing device 700 may be connected to other computing devices in a LAN, intranet, extranet, and/or the internet. Computing device 700 may operate in the identity of a server machine in a client-server network environment or as a client in a peer-to-peer network environment. Computing device 700 may be provided by a Personal Computer (PC), a set-top box (STB), a server, a network router, switch or bridge, or any machine capable of executing a set of instructions (sequential or otherwise) that specify actions to be taken by that machine. Furthermore, while only a single computing device 700 is illustrated, the term "computing device" should also be taken to include any collection of computing devices that individually or jointly execute a set (or multiple sets) of instructions to perform the methodologies discussed herein.

The example computing device 700 may include a computer processing device 602 (e.g., a general purpose processor, ASIC, etc.), a main memory 704, a static memory 706 (e.g., flash memory, etc.), and a data storage device 708, which may communicate with each other via a bus 730. The computer processing device 702 may be provided by one or more general purpose processing devices, such as a microprocessor, central processing unit, or the like. In illustrative examples, computer processing device 702 may include a Complex Instruction Set Computing (CISC) microprocessor, a Reduced Instruction Set Computing (RISC) microprocessor, a Very Long Instruction Word (VLIW) microprocessor, or a processor implementing other instruction sets or processors implementing a combination of instruction sets. The computer processing device 702 may also include one or more special purpose processing devices, such as an Application Specific Integrated Circuit (ASIC), a Field Programmable Gate Array (FPGA), a Digital Signal Processor (DSP), a network processor, or the like. According to one or more aspects of the present disclosure, the computer processing device 702 may be configured to perform the operations described herein for performing the operations and steps discussed herein.

Computing device 700 may also include a network interface device 712, which may communicate with a network 714. According to one or more aspects of the present disclosure, the data storage 708 may include a machine-readable storage medium 728 on which one or more sets of instructions, for example, instructions for performing the operations described herein, may be stored. The instructions 718 implementing the core logic instructions 726 may also reside, completely or at least partially, within the main memory 704 and/or within the computer processing device 702 during execution thereof by the computing device 700, the main memory 704 and the computer processing device 702 also constituting computer readable media. The instructions may also be transmitted or received over a network 714 via the network interface device 612.

While the machine-readable storage medium 728 is shown in an illustrative example to be a single medium, the term "computer-readable storage medium" should be taken to include a single medium or multiple media (e.g., a centralized or distributed database, and/or associated caches and servers) that store the one or more sets of instructions. The term "computer-readable storage medium" shall also be taken to include any medium that is capable of storing, encoding or carrying a set of instructions for execution by the machine and that cause the machine to perform the methods described herein. Accordingly, the term "computer readable storage medium" shall include, but not be limited to, solid-state memories, optical media, magnetic media, and the like.

The subject matter described herein provides a number of technical advantages. For example, some embodiments of the invention may increase the efficiency and processing power of computer hardware resources (e.g., computer processing and memory) to identify matches by supporting substantially faster matching times and, in particular, providing substantially faster matching times for client applications having a larger number of users (e.g., hundreds of thousands, millions, tens of millions, etc. of users). For example, some embodiments of the invention may more efficiently handle a larger number of users queuing and identifying matches in multiple templates at the same time. By increasing the matching speed and efficiency of client applications with a greater number of users, computer hardware resources can be released more quickly and used for other tasks and processes, thereby significantly increasing computer resource utilization.

Embodiments of the subject matter and operations described in this disclosure may be implemented in digital electronic circuitry, or in computer software, firmware, or hardware, including the structures disclosed in this disclosure and their structural equivalents, or in combinations of one or more of them. Embodiments of the subject matter described in this disclosure can be implemented as one or more computer programs, i.e., one or more modules of computer program instructions, encoded on a computer storage medium for execution by, or to control the operation of, data processing apparatus. Alternatively or additionally, the program instructions may be encoded on a manually generated propagated signal, e.g., a machine-generated electrical, optical, or electromagnetic signal, that is generated to encode information for transmission to suitable receiver apparatus for execution by data processing apparatus. The computer storage medium may be or be included in the following: a computer readable storage device, a computer readable storage substrate, a random or serial access memory array or device, or a combination of one or more of them. Furthermore, while the computer storage medium is not a propagated signal, the computer storage medium may be a source or destination of computer program instructions encoded in an artificially generated propagated signal. A computer storage medium may also be, or be included in, one or more separate physical components or media (e.g., multiple CDs, disks, or other storage devices).

The operations described in this disclosure may be implemented as operations performed by a data processing apparatus on data stored on one or more computer readable storage devices or received from other sources.

The term "data processing apparatus" includes all types of apparatus, devices, and machines for processing data, including for example a programmable processor, a computer processing device, a computer, a system on a chip, or a plurality or combination of the foregoing. The computer processing means may comprise one or more processors, which may comprise dedicated logic circuits, such as a Field Programmable Gate Array (FPGA) or an Application Specific Integrated Circuit (ASIC), a Central Processing Unit (CPU), a multi-core processor, or the like. In addition to hardware, the device may include code that creates an execution environment for the computer program in question, e.g., code that constitutes processor firmware, a protocol stack, a database management system, an operating system, a cross-platform runtime environment, a virtual machine, or a combination of one or more of them. Devices and execution environments may implement a variety of different computing model infrastructures, such as web services, distributed computing, and grid computing infrastructures.

A computer program (also known as a program, software application, script, or code) can be written in any form of programming language, including compiled or interpreted languages, declarative languages, procedural or functional languages, and it can be deployed in any form, including as a stand-alone program or as a module, component, subroutine, object, or other unit suitable for use in a computing environment. The computer program may, but need not, correspond to a file in a file system. A program can be stored in a portion of a file that holds other programs or data (e.g., one or more scripts stored in a markup language resource), in a single file dedicated to the program in question, or in multiple coordinated files (e.g., files that store one or more modules, sub-programs, or portions of code). A computer program can be deployed to be executed on one computer or on multiple computers at one site or distributed across multiple sites and interconnected by a communication network.

The processes and logic flows described in this disclosure can be performed by one or more programmable processors executing one or more computer programs to perform actions by operating on input data and generating output. The processes and logic flows can also be performed by, and apparatus can also be implemented as, special purpose logic circuitry, e.g., a Field Programmable Gate Array (FPGA) or an application-specific integrated circuit (ASIC).

Processors suitable for the execution of a computer program include, by way of example, both general and special purpose microprocessors, and any one or more processors of any kind of digital computer. Generally, a processor will receive instructions and data from a read-only memory or a random access memory or both. The essential elements of a computer are a processor for performing actions in accordance with instructions and one or more memory devices for storing instructions and data. Typically, a computer will also include, or be operatively connected to receive data from or transfer data to, or both, one or more mass storage devices for storing data, e.g., magnetic, magneto-optical disks, solid-state drives, etc. However, a computer need not have such devices. Furthermore, the computer may be embedded in another device, such as a smart phone, a mobile audio or media player, a game console, a Global Positioning System (GPS) receiver, or a portable storage device (e.g., a Universal Serial Bus (USB) flash drive), to name a few. Means suitable for storing computer program instructions and data include all forms of non-volatile memory, media and memory devices, including by way of example semiconductor memory devices, e.g., EPROM, EEPROM, and flash memory devices; magnetic disks, such as internal hard disks or removable disks; magneto-optical disk; CD ROM and DVD-ROM discs. The processor and the memory may be supplemented by, or incorporated in, special purpose logic circuitry.

To provide for interaction with a user, embodiments of the subject matter described in this specification can be implemented on a computer having a display device, e.g., a Cathode Ray Tube (CRT), liquid Crystal Display (LCD) monitor, etc., for displaying information to the user and a keyboard and a pointing device, e.g., a mouse, a trackball, a touch pad, a stylus, etc., by which the user can provide input to the computer. Other types of devices may also be used to provide for interaction with a user; for example, feedback provided to the user may be any form of sensory feedback, e.g., visual feedback, auditory feedback, or tactile feedback; and input from the user may be received in any form, including acoustic input, speech input, or tactile input. In addition, the computer may interact with the user by sending and receiving resources to and from devices used by the user; for example by sending a Web page to a Web browser on a user's client device in response to a request received from the Web browser.

Embodiments of the subject matter described in this disclosure can be implemented in a computing system that includes a back-end component, e.g., as a data server; or include middleware components, such as application servers; or a client computer including a front-end component, such as a graphical user interface or Web browser through which a user may interact with embodiments of the subject matter described in this disclosure; or any combination of one or more such back-end components, middleware components, or front-end components. The components of the system can be interconnected by any form or medium of digital data communication (e.g., a communication network). Examples of communication networks include local area networks ("LANs") and wide area networks ("WANs"), internetworks (e.g., the internet), peer-to-peer networks (e.g., ad hoc peer-to-peer networks), and the like.

The computing system may include clients and servers. The client and server are typically remote from each other and typically interact through a communication network. The relationship of client and server arises by virtue of computer programs running on the respective computers and having a client-server relationship to each other. In some implementations, the server transmits data (e.g., HTML pages) to the client device (e.g., to display data to and receive user input from a user interacting with the client device). Data generated at the client device (e.g., results of user interactions) may be received at the server from the client device.

A system of one or more computers may be configured to perform particular operations or actions by installing software, firmware, hardware, or a combination thereof on the system that, when operated, cause the system to perform the actions. One or more computer programs may be configured to perform particular operations or actions by including instructions that, when executed by a data processing apparatus, cause the apparatus to perform the actions.

Reference throughout this disclosure to "one embodiment" or "an embodiment" means that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment. Thus, the appearances of the phrases "in one embodiment" or "in an embodiment" in various places throughout this disclosure are not necessarily all referring to the same embodiment. Furthermore, the term "or" is intended to be inclusive, rather than exclusive.

While this disclosure contains many specific implementation details, these should not be construed as limitations on the scope of any invention or of what may be claimed, but rather as descriptions of features specific to particular embodiments of particular inventions. Certain features that are described in this disclosure in the context of separate embodiments can also be implemented in combination in a single embodiment. Conversely, various features that are described in the context of a single embodiment can also be implemented in multiple embodiments separately or in any suitable subcombination. Furthermore, although features may be described above as acting in certain combinations and even initially claimed as such, one or more features from a claimed combination can in some cases be excised from the combination, and the claimed combination may be directed to a subcombination or variation of a subcombination.

Similarly, although operations are depicted in the drawings in a particular order, this should not be understood as requiring that such operations be performed in the particular order shown or in sequential order, or that all illustrated operations be performed, to achieve desirable results. In some cases, multitasking and parallel processing may be advantageous. Moreover, the separation of various system components in the embodiments described above should not be understood as requiring such separation in all embodiments, and it should be understood that the described program components and systems can generally be integrated in a single software product or packaged into multiple software products.

Thus, particular embodiments of the subject matter have been described. Other embodiments are within the scope of the following claims. In some cases, the actions recited in the claims can be performed in a different order and still achieve desirable results. Furthermore, the processes depicted in the accompanying drawings do not necessarily require the particular order shown, or sequential order, to achieve desirable results. In certain embodiments, multitasking and parallel processing may be advantageous.

The foregoing description of illustrated embodiments of the application is not intended to be exhaustive or to limit the application to the precise form disclosed. Although specific embodiments of, and examples for, the application are described herein for illustrative purposes, various equivalent modifications are possible within the scope of the application, as those skilled in the relevant art will recognize. The terms "example" or "exemplary" are used herein to mean serving as an example, instance, or illustration. Any aspect or design described herein as "example" or "exemplary" is not necessarily to be construed as preferred or advantageous over other aspects or designs. Rather, the use of the terms "example" or "exemplary" is intended to present concepts in a concrete fashion. The term "or" as used in this disclosure is intended to mean an inclusive "or" rather than an exclusive "or". That is, unless specified otherwise or clear from context, "X includes a or B" is intended to mean any natural inclusive permutation. That is, if X includes A; x comprises B; or X includes both A and B, then "X includes A or B" is satisfied in any of the above cases. Furthermore, the articles "a" and "an" as used in this disclosure and the appended claims should generally be construed to mean "one or more" unless specified otherwise or clear from context to be directed to a singular form. Furthermore, the use of the terms "embodiment" or "one embodiment" or "an embodiment" or "one embodiment" throughout are not intended to mean the same embodiment or embodiment unless so described. Furthermore, the terms "first," "second," "third," "fourth," and the like as used herein refer to labels that distinguish between different elements and do not necessarily have an ordinal meaning according to their numerical designation.

Claims

1. A method, comprising:

Receiving, from a first user of a plurality of users of an application client executing on respective mobile devices of the plurality of users, a request to interact with one or more other users of the plurality of users in the application client based on a first plurality of interaction templates selected by the first user;

determining a second user from the plurality of users, the second user being associated with a second interaction template, the determining being based on identification of a match between the second interaction template and a first interaction template from the first plurality of interaction templates; and

In response to a determination of the second user, an interaction between the first user and the second user is initiated in the application client.

2. The method as recited in claim 1, further comprising:

The second user is searched until a match between another interaction template from the first plurality of interaction templates and the second interaction template is identified.

3. A method as recited in claim 1, wherein each of the second interaction template and the first plurality of interaction templates characterizes a synchronized electronic tournament for first and second user entries.

4. The method of claim 1, wherein the determining further comprises:

a first interaction template is selected from a first plurality of interaction templates based on operating parameters of the synchronous electronic tournament.

5. The method of claim 1, wherein the determining further comprises:

a first interaction template is selected from the first plurality of interaction templates based on the determined priority of the first interaction template.

6. The method as recited in claim 1, further comprising:

A third user associated with a fourth interaction template is determined from the plurality of users, the fourth interaction template matching a third interaction template from the first plurality of interaction templates, the determination of the third user being made when a determined duration for the second user exceeds a predetermined threshold.

7. The method as recited in claim 6, further comprising:

Determining a graphical prompt for display on a mobile device of a first user, characterizing instructions to select a fifth interaction template from the first plurality of interaction templates when a determined length of time for a second user exceeds a predetermined threshold; and

In response to selection of the fifth interaction template, a fourth user associated with a sixth interaction template is determined from the plurality of users, the sixth interaction template matching the fifth interaction template.

8. The method of claim 1, wherein the first plurality of interaction templates is selected by a first user from a set of available interaction templates, and wherein the set of available interaction templates is determined based on characteristics of the first user.

9. The method of claim 1, wherein the determination of the second user is based on a characteristic of the first user.

10. The method of claim 1, wherein the determination of the second user is based on characteristics of one or more of the first plurality of interaction templates.

11. A system, comprising:

At least one data processor and a memory storing instructions that, when executed by the at least one data processor, cause the at least one data processor to perform operations comprising:

12. The system of claim 11, wherein the operations further comprise:

13. A system as recited in claim 11, wherein each of the second interaction template and the first plurality of interaction templates characterizes a synchronized electronic tournament for first and second user entries.

14. The system of claim 11, wherein the determining further comprises:

15. The system of claim 11, wherein the determining further comprises:

16. The system of claim 11, wherein the operations further comprise:

17. The system of claim 16, wherein the operations further comprise:

18. The system of claim 11, wherein the first plurality of interaction templates is selected by the first user from a set of available interaction templates, and wherein the set of available interaction templates is determined based on characteristics of the first user.

19. The system of claim 11, wherein the determination of the second user is based on a characteristic of the first user.

20. A non-volatile computer program product storing executable instructions that, when executed by at least one data processor forming part of at least one computing system, perform operations comprising: