A system and method for managing user-to-user interactions in client applications.

Abstract

At a minimum, a method for managing user-to-user interactions in a client application is considered. The method includes receiving a first request from a first client device requesting to start an electronically interactive session within the client application with additional client devices; receiving a second request from a second client device to start an electronically interactive session within the client application with one or more additional client devices; and determining an electronically interactive session between the first and second client devices based on the identification of a match between one of a first plurality of interaction templates and one of a second plurality of interaction templates selected on the second client device.

Description

Background Art

[0001] Cross - reference to Related Applications This application claims the benefit of a U.S. provisional patent application having U.S. Provisional Patent Application No. 63 / 490,634, filed Mar. 16, 2023. The content of the U.S. provisional patent application having U.S. Provisional Patent Application No. 63 / 490,634 is hereby incorporated by reference in its entirety.

[0002] Background of the Invention Users of client applications can interact or engage with other users of those client applications in various ways. For example, a user can compete with other users within a client application to win a prize or other outcome. One factor that can affect the user experience within a client application is the quality of the opponents the user is competing or interacting with. A large disparity between opponents in terms of their respective abilities or skill levels, for example, can negatively impact the experience of each user within the client application. For instance, when a beginner is paired with an expert in a competition, the beginner may be dissatisfied with having little or no chance of winning, and the expert may be dissatisfied with competing against an opponent that is little or no challenge, so both the beginner and the expert may not find the competition interesting or even fair. Another factor that can affect the user experience within a client application is the time it takes to find an opponent. A long wait time can cause dissatisfaction among users, which can lead to user churn.

Summary of the Invention

Means for Solving the Problems

[0003] The present invention relates to a system and method for managing user interactions in a client application. According to the present invention, users of a client application can be automatically matched with other users of that client application to, for example, compete with each other, or interact or engage with each other in a different way within the client application. The present invention can promote fair competition and other appropriate interactions within a client application by matching users with similar skills, abilities, and / or other characteristics. The present invention can match users more quickly by allowing users to simultaneously enter queues of multiple templates using multiple interaction modes of the client application.

[0004] In one embodiment, a first request from a first client device running a client application can be received by at least one data processor, requesting to initiate an electronically interactive session within the client application with one or more additional client devices. In one embodiment, the first request can be based on a first set of interaction templates associated with the first client device. In one embodiment, the first set of interaction templates can be associated with each of a set of actors. In one embodiment, each actor in each of the set of actors may be independent of the remaining actors in the set of actors. In one embodiment, a second request from a second client device can be received by at least one data processor, requesting to initiate an electronically interactive session within the client application with one or more additional client devices. In one embodiment, the second request can be based on a second set of interaction templates associated with the second client device. In one embodiment, the second set of interaction templates can be associated with each of a set of additional actors. In one embodiment, each actor in each of the set of additional actors may be independent of the remaining actors in the set of additional actors. In one embodiment, an electronically interactive session between a first client device and a second client device can be determined by at least one data processor based on the identification of a match between one of a first plurality of interaction templates and one of a second plurality of interaction templates selected on the second client device. In another embodiment, the identification of the match is based on a concurrency model that enables scaling to multiple servers independently of any architectural modification of the multiple servers. In yet another embodiment, client application servers from a pool of pre-instantiated client application servers can be allocated by at least one data processor for use with client applications during an electronically interactive session.In another embodiment, an electronically interactive session between a first client device and a second client device within a client application can be provided by at least one data processor.

[0005] In one embodiment, a first client device may be simultaneously enqueued to each of the first multiple interaction templates, and another pre-instantiated client application server may replace a client application server that can be added to and allocated to a pool of pre-instantiated client application servers. In another embodiment, each of the first multiple interaction templates may be associated with each of the multiple matchmaker instances, and a second client device may be simultaneously enqueued to each of the second multiple interaction templates. In another embodiment, each of the multiple actors and each of the multiple additional actors may contain behavior or logic.

[0006] In one embodiment, the first actor among multiple actors may be capable of modifying a state specific to the first actor. In one embodiment, the modification may be independent of the remaining actors among multiple actors. In one embodiment, the second actor among multiple additional actors may be capable of additional modifications to a state specific to the second actor. In one embodiment, the additional modifications may be independent of the remaining actors among multiple additional actors. In one embodiment, a client application server that can be allocated may be deallocated upon completion of an electronically interactive session. In one embodiment, a first set of interaction templates may be selected on a first client device, and a second set of interaction templates may be selected on a second client device.

[0007] In another embodiment, the system may comprise at least one data processor and memory for storing instructions, where an instruction, when executed by at least one data processor, causes the at least one data processor to perform various operations. With respect to operations, in one embodiment, the system may receive a first request from a first client device running a client application, requesting to start an electronically interactive session within the client application with one or more additional client devices. In one embodiment, the first request may be based on a first set of interaction templates associated with the first client device. In one embodiment, the first set of interaction templates may be associated with each of a set of actors. In one embodiment, each actor in each set of actors may be independent of the remaining actors in the set of actors. In one embodiment, the system may receive a second request from a second client device to start an electronically interactive session within the client application with one or more additional client devices. In one embodiment, the second request may be based on a second set of interaction templates associated with the second client device. In one embodiment, the second set of interaction templates may be associated with each of a set of additional actors. In one embodiment, each actor of each of the multiple additional actors may be independent of the remaining actors of the multiple additional actors. In one embodiment, an electronic interaction session between a first client device and a second client device may be determined based on the identification of a match between one of the first multiple interaction templates and one of the second multiple interaction templates selected on the second client device. In one embodiment, the identification of the match is based on a concurrency model that enables scaling to multiple servers independently of any architectural modification of the multiple servers.In another embodiment, client application servers from a pool of pre-instantiated client application servers may be allocated for use with client applications during an electronically interactive session. In yet another embodiment, an electronically interactive session may be provided between a first client device and a second client device within the client application.

[0008] In one embodiment, a first client device may be simultaneously enqueued to each of the first multiple interaction templates, and another pre-instantiated client application server may be added to a pool of pre-instantiated client application servers to replace an allocated client application server. In another embodiment, each of the first multiple interaction templates may be associated with each of the multiple matchmaker instances, and a second client device may be simultaneously enqueued to each of the second multiple interaction templates. In another embodiment, each of the multiple actors and each of the multiple additional actors may contain behavior or logic.

[0009] In one embodiment, a first actor among multiple actors may be able to modify a state specific to the first actor. In one embodiment, the modification may be independent of the remaining actors among multiple actors. In one embodiment, a second actor among multiple additional actors may be able to further modify an additional state specific to the second actor. In one embodiment, the additional modification may be independent of the remaining actors among multiple additional actors. In one embodiment, a first set of interaction templates may be selected on a first client device, and a second set of interaction templates may be selected on a second client device.

[0010] In another embodiment, a non-temporary computer program product can store executable instructions, which, when executed by at least one data processor forming part of at least one computing system, can perform a variety of operations. In one embodiment, with respect to operations, a first request can be received from a first client device running a client application, requesting to initiate an electronically interactive session within the client application with one or more additional client devices. In one embodiment, the first request may be based on a first set of interaction templates associated with the first client device. In one embodiment, the first set of interaction templates may be associated with each of a set of actors. In one embodiment, each actor in each set of actors may be independent of the remaining actors in each set of actors. In one embodiment, a second request can be received from a second client device to initiate an electronically interactive session within the client application with one or more additional client devices. In one embodiment, the second request may be based on a second set of interaction templates associated with the second client device. In one embodiment, the identification of matches is based on a concurrency model that enables scaling to multiple servers independently of any architectural modification of the multiple servers. In one embodiment, the second set of interaction templates can be associated with each of the set of additional actors. In another embodiment, each actor of the set of additional actors may be independent of the remaining actors of the set of additional actors. In one embodiment, an electronic interaction session between a first client device and a second client device can be determined based on the identification of a match between one of the first set of interaction templates and one of the second set of interaction templates selected on the second client device.In another embodiment, a client application server from a pool of pre-instantiated client application servers may be allocated for use with a client application during an electronically interactive session. In yet another embodiment, an electronically interactive session may be provided between a first client device and a second client device within a client application. In one embodiment, the first client device may be simultaneously enqueued to each of a first set of interaction templates, and each of the first set of interaction templates may be associated with each of a set of matchmaker instances. In one embodiment, another pre-instantiated client application server may be added to a pool of pre-instantiated client application servers to replace an allocated client application server.

[0011] In one embodiment, a second client device can be simultaneously enqueued to each of the second set of interaction templates. In another embodiment, an electronic interaction session between the first and second client devices can be determined based on the identification of a match between one of the first set of interaction templates and one of the second set of interaction templates. In another embodiment, each of the set of actors and each of the additional actors can include behavior or logic. In another embodiment, a client application server that can be allocated can be deallocated upon completion of the electronic interaction session. In another embodiment, the first set of interaction templates can be selected on the first client device, and the second set of interaction templates can be selected on the second client device. [Brief explanation of the drawing]

[0012] The embodiments described above will be better understood from the following detailed description in conjunction with the attached drawings. The drawings are not intended to be drawn to exact scale. For clarity, not all components are labeled in all drawings. In the drawings:

[0013] [Figure 1] Figure 1 is a block diagram illustrating an exemplary system for managing user-to-user interactions in a client application.

[0014] [Figure 2] Figure 2 is a block diagram showing actor design patterns used by a matchmaker engine to match users of a client application.

[0015] [Figure 3] Figure 3 is a block diagram illustrating an example of matchmaking for a client application performed by a matchmaker engine using the Actor Design Pattern.

[0016] [Figure 4] Figure 4 is a flowchart illustrating an exemplary method for managing user-to-user interactions in a client application.

[0017] [Figure 5] Figure 5 is a block diagram of an exemplary computing device according to this embodiment that can perform one or more of the operations described herein. [Modes for carrying out the invention]

[0018] Description of the Invention Herein, in order to provide an overall understanding of the structure, function, manufacturing and use principles of the devices and methods disclosed herein, certain exemplary embodiments are described. One or more examples of these embodiments are shown in the accompanying drawings. Those skilled in the art will understand that the devices and methods specifically described herein and shown in the accompanying drawings are non-limiting and exemplary embodiments, and that the scope of the invention is defined solely by the claims. Features illustrated or described in relation to one exemplary embodiment may be combined with features of other embodiments. Such modifications and variations are intended to fall within the scope of the invention. Furthermore, in this disclosure, components with similar names in embodiments generally have similar features, and therefore, within a particular embodiment, each feature of each similarly named component is not necessarily fully described.

[0019] The present invention relates to a system and method for managing user interactions in a client application. According to the present invention, users of a client application (e.g., a mobile application such as a mobile game, a computer game, or any other suitable type of client application) can be automatically matched with other users of that client application to compete with each other, or interact with or engage with each other in a different way within the client application. Embodiments of the present invention can facilitate fair competition and other appropriate interactions within a client application by matching users with similar skills, abilities, and / or other characteristics. Embodiments of the present invention can match users more quickly by allowing users to simultaneously enter queues for multiple templates using multiple interaction modes of the client application. Some implementations of the present invention can improve the efficiency and processing power of computer hardware resources (e.g., computer processing and memory) to enable match identification by supporting and providing substantially faster matching times, particularly for client applications with a large number of users (e.g., hundreds of thousands, millions, tens of millions, etc.). For example, some implementations of the present invention can more efficiently handle a large number of users simultaneously enqueuing to multiple templates and simultaneously identifying matches in multiple templates. By improving the speed and efficiency of matching for client applications with a large number of users, computer hardware resources can be freed up more quickly and used for other tasks and processes, resulting in a significant improvement in the utilization of computer resources.

[0020] For illustrative purposes only and not limiting, this disclosure uses mobile games as an exemplary client application to illustrate various aspects of the Invention. However, some implementations of the Invention can be used within and with any suitable type of client application, in which one or more users are automatically matched with one or more other users to engage or interact for the purpose of achieving some goal or result within the client application. For example, the Invention can generate matches for a competition or tournament or other suitable activity, or it can match users with certain characteristics (e.g., to establish a chat or social connection within the client application) with other users in the client application who have similar characteristics.

[0021] Figure 1 is a block diagram illustrating an exemplary system 100 for managing user-to-user interactions of a client application, according to an implementation of the present disclosure. System 100 may include a server system 102. The server system 102 may provide functions for collecting and processing data associated with managing user-to-user interactions of a client application. The server system 102 may include software components, client application servers, and one or more databases that can be deployed in one or more data centers in one or more geographical locations, for example. The server system 102 may be cloud-based (e.g., Amazon Web Services, Google Cloud, Microsoft Azure, or other suitable cloud-based infrastructure provider) or may consist of dedicated server hardware. The software components of the server system 102 may include a client application activity engine 104, a user details engine 106, a matchmaker engine 108, a gateway module 110, a client application server 112, and a client application server pool 120. The software components may include sub-components that can run on the same or different individual data processing devices. The software components and client application servers are described further below.

[0022] As shown in Figure 1, the server system 102 (and either the software components of the server system 102 or the client application server) can communicate with one or more databases 132. The databases 132 may be cloud-based or reside in one or more physical storage systems. In an alternative embodiment, the server system 102 may include one or more of the databases 132. In some implementations of the present invention, the database 132 may include any appropriate information relating to the management of software components and users for the system 100, any appropriate information including, for example, user client application history (e.g., in the context of mobile games, which mobile games were played, the number of games won in each mobile game, the number of games lost in each mobile game, the number of games played per mobile game, the score in each mobile game, the time played for each mobile game, the win / loss rate, etc.), user identification information (e.g., username, email address, telephone number, client device ID information, client device IP address, etc.), history of user connections to the server system 102, user performance within client applications, user status within client applications, user tasks within client applications, user interactions with other users (e.g., chat, competition, matchmaking results, etc.), user purchases within client applications, user deposits and withdrawals within client applications, user acquisition or use of virtual items within client applications, other conditions within client applications, and other similar user characteristics and / or information, such as the characteristics of users in client applications and their interactions with client applications.The database 132 can also include information about client applications implemented using the system 100, such as, for example, virtual environments for each client application, images, videos, text, and / or audio data for each client application, event data corresponding to past, current, or future events, client application state data defining the current state of each client application, and other similar data and information.

[0023] For example, software applications such as mobile games or other web-based or suitable client applications can be provided as end-user client applications to enable users to interact with the server system 102. The software applications can be related to and / or provide a variety of functions and information including, for example, entertainment (such as games, music, videos, etc.), business (such as word processing, accounting, spreadsheets, etc.), news, weather, finance, sports, etc. In certain implementations, the software application can provide a mobile game. The mobile game can be, for example, a sports game, an adventure game, a virtual playing card game, a virtual board game, a puzzle game, a racing game, or any other suitable type of mobile game, or can include them. In one embodiment, the mobile game can be an asynchronous competitive skill-based game where users can compete with each other within the mobile game but do not necessarily need to play the mobile game simultaneously. In an alternative embodiment, the mobile game can be a synchronous competitive skill-based game where users can play the mobile game simultaneously and compete with each other within the mobile game in real time. Other suitable client applications are possible.

[0024] A software application or its components can be accessed by a user of a client device via a network 144 (e.g., the Internet or other suitable network). The server system 102 can support and communicate with any suitable number of client devices and any suitable number of client applications. Each client device can be any suitable type of electronic device capable of running a software application and communicating with the server system 102 via the network 144, such as, for example, a smartphone, a tablet computer, a laptop computer, a desktop or personal computer, etc. Other client devices (e.g., smart TVs, smart watches, game consoles, and other similar computing devices) are also possible. In an alternative embodiment, the database 132 or any portion thereof can be stored on one or more client devices. Additionally or alternatively, software components for the server system 102 (e.g., the client application activity engine 104, the user details engine 106, the matchmaker engine 108) or any portion thereof can be present on or used to execute operations on one or more client devices.

[0025] In one embodiment, the server system 102 may include a client application activity engine 104. The client application activity engine 104 may be configured to provide services and processes to enable users to participate in or interact with matches within a client application. In other words, the client application activity engine 104 can manage user-to-user interactions within a client application. The client application activity engine 104 may handle creating tournament and tournament user objects and adding those tournament users to the tournament in the database 132, which occurs when it is confirmed that both users have joined the tournament after being matched. The client application activity engine 104 may also handle checks to determine whether a user is allowed to join a tournament, such as determining whether the user is already in a matchmaking queue, whether the user is in a paid-participation location, whether the user has enough currency to participate in a paid-participation competition, etc. The client application activity engine 104 may also pass relevant information to the matchmaker engine 108, such as user ratings and which template to enqueue in.

[0026] In one embodiment, the server system 102 may include a user details engine 106 that communicates with a client application activity engine 104. The user details engine 106 may be configured to provide a service for managing and retrieving user-related information (e.g., from a database 132). The user details engine 106 may fetch client application account information about a user, which may include, for example, user ratings, account balances, etc., and pass it to the client application activity engine 104. Thus, in some implementations of the present invention, user information can be fetched or collected by the user details engine 106 and passed to the client application activity engine 104, and the client application activity engine 104 can pass the user information to the matchmaker engine 108, so that the matchmaker engine 108 does not need to query for any such user information.

[0027] In one embodiment, the server system 102 may include a matchmaker engine 108 that communicates with a client application activity engine 104 and a user details engine 106. The matchmaker engine 108 may be configured to perform a service for matching two or more users to interact electronically with each other within a client application. Several implementations of the present invention can be used within and with any suitable type of asynchronous or synchronous client application. In one embodiment, the client application may be an asynchronous mobile game. In an asynchronous mobile game, users do not need to play simultaneously. For example, in an asynchronous mobile game, a first user may request to join a competition or tournament, which can initiate the user matching technique of several implementations of the present invention. The first user can play the competition or tournament while several implementations of the present invention search for a suitable match for the first user. Once a match is found, the identified second user can play the competition or tournament (if the first user has not yet joined, since the second user may have joined the competition or tournament after the first user). In contrast, in synchronous mobile games, users compete against each other in real time (e.g., pool games), so users need to play against each other simultaneously. Synchronized mobile games should not start until user matching is complete. As a result, synchronous client applications may need to complete matching, and generally more quickly, before users can interact with each other within the client application.

[0028] In one embodiment, the matchmaker engine 108 can be used for matching within a synchronous client application. Matchmaking within any suitable type of synchronous or asynchronous client application can be supported by the matchmaker engine 108, but for illustrative purposes only and not limited to, the matchmaker engine 108 can be used for a synchronous mobile game. In the example of a synchronous mobile game, the matchmaker engine 108 can use fast matchmaking techniques that allow users to queue and select one or more templates that each user is interested in playing. A template can be a competition or a tournament. A template can consist of template options. Template options can be characteristics of a competition or tournament that a user may want to play in a synchronous mobile game, such as the type of competition (e.g., paid vs. free), the amount of the paid competition (e.g., $5, $10, $20, etc.), the amount of the free competition (e.g., 5 virtual tokens, 10 virtual tokens, 20 virtual tokens, etc.), the prize pool, and the rules of the competition mode (e.g., a $5 8-ball vs. $5 trick shot mode in a pool game).

[0029] The matchmaker engine 108 can allow users to enter queues of multiple templates simultaneously or substantially simultaneously, which allows for a significant reduction in matching time. The matchmaker engine 108 can determine the speed and order in which users enter (i.e., are enqueued) each template using appropriate extension techniques, as will be described in more detail below. In one embodiment, once a user has selected multiple templates, the user may enqueue each template in descending order from maximum to minimum value (determined, for example, by prize money instead of entry fees). For example, the matchmaker engine 108 may start with the highest value paid entry template, then refer to all paid entry templates in descending order of value, and then refer to all free entry templates in descending order of value. For illustrative purposes rather than limitation, a user may select the following templates: a $5 paid entry competition, a $20 paid entry competition, a 5 virtual token free entry competition, and a 20 virtual token free entry competition, where each value may represent a prize money value (but in an alternative embodiment, the value may represent an entry fee). In this example, a user can enqueue in the following order: a $20 paid competition, then a $5 paid competition, then a 20 virtual token free competition, and then a 5 virtual token free competition. In another example, a user can select two templates for $20 paid competitions, but each having a different competition mode (for example, in a pool mobile game, one for trick shots and the other for 8-ball). In such embodiments, each competition mode can have an associated priority, which can be used to break "ties" between templates of equal value. In this example of the pool game, the trick shot mode can have a higher priority (e.g., 1), and the 8-ball mode can have a lower priority (e.g., 2). Other priority values ​​are also possible.As a result, templates with higher priority (e.g., Trick Shot Mode with priority 1) may be enqueued first, templates with the next highest priority (e.g., 8-Ball Mode with priority 2) may be enqueued second, and so on. Such prioritization can also be used to determine the order in which the game modes can be displayed on the user's client device screen (e.g., the game mode with the highest priority may be displayed at the top or first, the game mode with the next highest priority may be displayed below the top or second, etc.). If a user is not matched for the first template within a certain time, the user may be queued for the second template until a match is made (e.g., while still in the queue for the first template), and so on.

[0030] In one embodiment, the matchmaking supported by the matchmaker engine 108 can be based on the actor design pattern. For example, each template may have actors (e.g., one actor per template) or may be associated with actors in a different way. The actor design pattern is a model of concurrent computation and / or concurrent processing that treats actors as the basic units of computation. An actor defines some behavior or logic to perform and instructs other actors to perform that behavior using an appropriate method of communication. Since the behavior defined for an actor is asynchronous, the actor does not wait for a response. Rather, the actor continues processing and receives a response at some point later. All communication takes place via message passing, where messages are processed one at a time in the order they are received. Actors can respond to received messages by performing appropriate computations or logic (such as making local decisions, creating more actors, sending more messages, and deciding how to respond to the next received message). Actors can modify their own private state, but can only influence each other indirectly through messaging. Actors are isolated from each other, do not share memory, storage is "shared nothing," and private data is isolated and accessible only by the actor that owns it. Such characteristics enable large-scale and efficient scaling of matchmaking in several implementations of the present invention. For example, actors can support linear scaling to multiple servers (e.g., hundreds and thousands of servers) without requiring architectural redesign. Server architecture refers to various server-specific characteristics (e.g., how one or more sub-components of a server and / or server system are connected, any protocols or processes implemented and initiated to communicate data inside and outside the server and / or server system, how resources (e.g., memory) are allocated and shared within the server and / or server system, etc.).Actors can support linear scaling to multiple servers as described in this disclosure, and they can include at least some of the server-specific characteristics described above without requiring redesign or modification of at least some of these server-specific characteristics. Actors can also support location transparency to facilitate addressing compute units both locally and non-locally, so that actors can reside on any server without requiring architectural redesign. Actors can also support lock-free data operations, eliminating the need for lock-based synchronization. Due to one message rule at a time, there is no need to lock data, and race conditions are prevented. The actor design patterns may be more efficient when handling a large number of user enqueues and attempting to identify matches in multiple templates simultaneously. Other design patterns for the matchmaker engine 108 are also possible.

[0031] Figure 2 is a block diagram showing an actor design pattern 200 for use by the matchmaker engine 108 to match users of a client application, according to an embodiment of the present disclosure. A suitable load balancer 202 in the server system 102 (e.g., in the matchmaker engine 108) can instantiate and manage any suitable number of matchmaker engine instances, but can allocate matchmaking among different instances or processes of the matchmaker engine 108, such as a first matchmaker engine instance 204, a second matchmaker engine instance 206, and a third matchmaker engine instance 208. In some implementations of the present invention, there may be one actor per client application template, which may be called a template actor. In other words, each matchmaker engine instance can interact with each template actor with respect to each client application template of any suitable number of client application templates. In one embodiment, the matchmaking queue may be an ordered dictionary in the template actor memory, and the template actor can look up the queue when the queue has been added with users to be searched. For example, the first matchmaker engine instance 204 can perform matchmaking with three users 218 using the first template actor 210 relating to the first template of the first client application. The second matchmaker engine instance 206 can perform matchmaking with a single user 220 using the second template actor 212 relating to the second template of the first client application. The third matchmaker engine instance 208 can perform matchmaking with three users 222 using the first template actor 214 relating to the first template of the second client application, and can perform matchmaking with three users 224 using the second template actor 216 relating to the second template of the second client application.Users can enter various templates simultaneously, and each template actor can perform matchmaking concurrently or in parallel with each other. Using one client actor per client application template allows for linear scaling and in-memory matching, does not require memory locks or redundant work, and can be event-driven. In other words, by using template actors, the matchmaker engine 108 can scale to support simultaneous matchmaking for a large number of users, such as hundreds of thousands, millions, tens of millions, or even more.

[0032] According to one embodiment, when a user is ready to be matched (for example, by pressing the appropriate virtual button displayed on the graphical interface of a client application running on the user's client device), the matchmaker engine 108 can analyze the entire set of selected templates, regardless of the client application mode, and begin by traversing the templates in descending order of value or other characteristics (for example, in descending order of prize money for paid competitions, followed by in descending order of prize money for free competitions). If there is a tie in values ​​between two competition modes in the selected templates, the template with higher priority (for example, a priority 1 template, then a priority 2 template, then a priority 3 template, etc.) can be queued first. For illustrative purposes only and not limitation, the following templates can be selected by the user for a pool game: $20 8-Ball (Competition Mode Priority 1), $20 Trick Shot (Competition Mode Priority 2), $5 8-Ball (Competition Mode Priority 1), $5 Trick Shot (Competition Mode Priority 2), and 1 Virtual Token Trick Shot (Game Competition Priority 1). The queuing order for finding a match may be as follows: $20 8-ball, $20 trick shot, $5 8-ball, $5 trick shot, and 1 virtual token trick shot. The matchmaker engine 108 can proceed through each selected template until a suitable match is found. In such embodiments, the user can remain in the queue of one or more previous templates while enqueuing for one or more additional templates in order to maximize the matchmaker engine 108's ability to identify matches. Other methods are also possible for the matchmaker engine 108 to traverse templates and identify matches in different orders and priorities.

[0033] In one embodiment, if the matchmaker engine 108 is unable to identify a match based on the selected template, the matchmaker engine 108 may cause the user to be prompted to play one or more different templates, such as alternative synchronous mobile game templates and / or asynchronous mobile game templates. The matchmaker engine 108 may cause the user to be shown appropriate notifications in the user interface prompting the user to match within a different (other) template. For example, such a prompt may occur if the matchmaker engine 108 has not identified a match for a user with those selected templates (e.g., no matches identified within a given time), but has identified a second user with a different selected template (within the same client application, but in either the same or different client application modes). In one embodiment, the matchmaker engine 108 may be configured with respect to acceptable fallbacks to prevent a particular fallback from being provided to one or more users (e.g., no bot template fallback, no asynchronous fallback for synchronous templates, and vice versa). As an addition or alternative, the matchmaker engine 108 can encourage users to add templates to their selection (for example, by adding popular templates or templates with higher user fluidity) to increase the likelihood of a successful match.

[0034] In one embodiment, the matchmaker engine 108 can dynamically add or remove templates when various user fluidity thresholds are met. For example, a user may be provided with a first set of multiple templates. The matchmaker engine 108 can acquire and maintain in real time the number of users available for a match for each template, the average wait time to match, the matching success rate, the total queue, and other similar information in order to determine user fluidity in real time. Each template may have a user fluidity threshold associated with it. For illustrative purposes rather than limitation, the user fluidity threshold may indicate, for example, the minimum number of users that the matchmaker engine 108 needs to generate a successful match for that template, but the user fluidity threshold may be based on other appropriate factors or combinations of factors (e.g., available users, average wait time, etc.). The user fluidity thresholds may be the same or different across templates. For example, a template with a lower paid entry fee (e.g., $1.80) may have a higher user fluidity threshold because it may have more users available in general and a shorter average wait time for matching in tournaments with lower paid entry fees. However, templates with higher entry fees (e.g., $120) may have lower user liquidity thresholds because they are generally available to fewer users and may have longer average wait times for matchmaking in tournaments with higher entry fees. For a set of templates, the matchmaker engine 108 may remove a template from the sets displayed or presented to users if user liquidity falls below the user liquidity threshold for that template. The matchmaker engine 108 may add a template to the sets displayed or presented to users if user liquidity exceeds the user liquidity threshold for that template.Such dynamic template scaling allows users to be presented with an updated set of templates (continuously or at predetermined intervals) that maximizes the likelihood of a successful match. Additionally or alternatively, each template can be associated with one or more times or time ranges, and as a result, the matchmaker engine 108 can add or remove specific templates for the user from each set at a given time or within a given time range.

[0035] In one embodiment, the matchmaker engine 108 can dynamically modify user matching for each template or any template based on a user fluidity threshold. For example, if user fluidity increases above a predetermined threshold (or is within a predetermined threshold range), the matchmaker engine 108 can provide narrower matching for each template or any template, as there may be more users available for matching. Conversely, if user fluidity decreases below a predetermined threshold (or is outside a predetermined threshold range), the matchmaker engine 108 can provide wider matching for each template or any template, as there may be fewer users available for matching. The matchmaker engine 108 can provide narrower or wider matching, for example, by appropriately updating the parameters used on the Elo extension, and as a result, the Elo extension can take more or less time to extend to a wider or narrower maximum range of Elo differences between two users (which the matchmaker engine 108 allows them to match with each other). In this way, the matchmaker engine 108 can respond to user fluidity in real time and maximize the probability of successful user matching. Additionally or alternatively, the matchmaker engine 108 can dynamically modify user matching for each template or any template based on time or other appropriate parameters, thereby enabling the matchmaker engine 108 to modify user matching within a given time or time range. Additionally or alternatively, the matchmaker engine 108 may use appropriate machine learning / artificial intelligence techniques to match users. For example, a machine learning model can be trained based on user fluidity data for each template or any template to optimize the time to successful matching. The machine learning model can then be used to dynamically match users for each template or any template.Machine learning models can be updated or adapted as user mobility changes over time.

[0036] In one embodiment, to improve or enhance user fluidity to one or more templates, the matchmaker engine 108 may cause an appropriate modal or other notification to appear within the user interface of a client application, prompting the user to play a particular synchronous client application or a particular mode within those synchronous client applications. Additionally or alternatively, the matchmaker engine 108 may prompt the user to play a particular synchronous client application or a particular mode within those synchronous client applications by displaying or causing a chat message to appear within the chat user interface. Such prompts may appear automatically at the direction of the matchmaker engine 108 when the user fluidity level (generally for any of the client applications or one or more templates) falls below an appropriate user fluidity threshold. The user prompt may persist for a predetermined period, such as until the user fluidity level becomes greater than or equal to the user fluidity threshold. Additionally or alternatively, the matchmaker engine 108 may cause such prompts to appear within the client application for a predetermined time or within a predetermined time range.

[0037] In some implementations of the present invention, the speed at which users are enqueued to each template can be determined by an appropriate extension technique. In one embodiment, the extension technique used by the matchmaker engine 108 may be a linear algorithm such as equation (1). Y=mX+b (1)

[0038] In equation (1), the variable Y may be the total time since entering the first queue, the variable X may be an extended index starting from 0, the constant b may be a first period (e.g., in seconds) relating to how long the matchmaker engine 108 waits before entering the second selected template, and the constant m may be a second period (e.g., in seconds) relating to how long the matchmaker engine 108 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.

[0039] According to this embodiment, the variable X can represent how many additional queues the user has entered from the first queue. When X=0, the user enters one queue and waits Y(0) time before entering the next queue. When X=1, the user enters a total of two queues and waits Y(1) time to enter the third queue. Y(1)-Y(0) time elapses between entering the second and third queues. For illustrative purposes only, not limitation, when m=1 and b=1 (i.e., Y=x+1), the user can choose from the templates described above. For illustrative purposes only, not limitation, the user can choose from the following templates: a $5 paid competition, a $20 paid competition, a 5 virtual token free competition, and a 20 virtual token free competition. In this example, the user can enqueue in the following order: a $20 paid competition, then a $5 paid competition, then a 20 virtual token free competition, and then a 5 virtual token free competition. Using equation (1) for matchmaker engine 108, the user is immediately placed in the queue for a $20 paid competition. After 1 second (Y=1*0+1=1), the user is placed in the queue for a $5 paid competition. After another 1 second (total 2 seconds, i.e., Y=1*1+1=2), the user is placed in the queue for a free competition costing 20 virtual tokens. After another 1 second (total 3 seconds, i.e., Y=1*2+1=3), the user is placed in the queue for a free competition costing 5 virtual tokens. According to an alternative embodiment, both m and b can be set to zero to allow the user to enter all queues simultaneously.

[0040] In another embodiment, the extension technique used by the matchmaker engine 108 may be a logarithmic algorithm such as equation (2). Y = ln(mX + b) + c (2)

[0041] In equation (2), the definitions of the variables and parameters are the same as those described for equation (1), and the constant c may be a third period (e.g., in seconds) to control how quickly the logarithmic algorithm expands to subsequent templates. Thus, the logarithmic algorithm of equation (2) can expand slowly to the second template and then rapidly to all other templates. For illustrative purposes rather than limitations, let m=1, b=1, and c=5 (i.e., Y=ln(X+1)+5), and the user selects the templates described above. The user is immediately queued to the first template. The user is enqueued to 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=approximately 5.7 seconds. The user enters the fourth queue after Y=ln(2*1+1)+5=approximately 6.1 seconds.

[0042] In another embodiment, the extension technique used by the matchmaker engine 108 may be an exponential algorithm such as equation (3). Y = e^(mX + b) + c (3)

[0043] In equation (3), the definitions of the variables and parameters are the same as those described for equation (2). Thus, the exponential algorithm can be rapidly extended to the second template and then slowly extended to all other templates. For illustrative purposes rather than limitations, let m=1, b=1, and c=5 (i.e., Y=e^(X+1)+5), and the user selects one of the templates described above. The user is immediately queued for the first template. The user is enqueued for the second template after approximately 7.7 seconds (Y=e^(1*0+1)+5). The user then enters the third queue after approximately 12.4 seconds (Y=e^(1*1+1)+5). The user enters the fourth queue after approximately 25.1 seconds (Y=e^(2*1+1)+5).

[0044] In some embodiments, the constants m, b, and c are customizable and may differ between each extension technique. Extension techniques can be configured, for example, on a per-client application basis, per-template group basis, specific to individual template IDs, at the participation type level (e.g., paid participation or free participation). For example, one extension technique may be used for a first client application, another extension technique for a second client application, and so on. According to one embodiment, different extension techniques may be applied to the matchmaker engine 108 for the client application at different times. For example, a linear extension algorithm may be used from 6am to 6pm, a logarithmic extension algorithm from 6pm to midnight, and an exponential algorithm from midnight to 6am. Other extension techniques at other times and in other sequences are also possible. As an addition or alternative, each variable and parameter of an extension technique may be modified, for example, based on time and / or date. For example, the matchmaker engine 108 can modify its variables and parameters to provide narrower matchmaking during peak hours (and / or holidays or weekends when more users may be available for matchmaking), and the matchmaker engine 108 can modify its variables and parameters to provide wider matchmaking during off-peak hours (and / or non-holiday or weekdays when fewer users may be available for matchmaking).

[0045] According to one embodiment, the matchmaker engine 108 may, as an addition or alternative, use Elo rating enhancement technology for synchronous client applications. As an addition or alternative, Elo rating enhancement technology may be used for asynchronous client applications. Such enhancement technology can determine how quickly the possible rating range of users for matching expands. In one embodiment, the matchmaker engine 108 may use an exponential rating enhancement algorithm such as equation (4). Y = min(a + b * e^(X / c), d) (4)

[0046] In equation (4), the variable Y is the rating difference, the variable X is the waiting time until matching, the constant a is the minimum rating for immediate matching, the constants b and c are scaling factors, and the constant d is the maximum rating difference. In one embodiment, the values ​​of a, b, c, and d can be adjusted based on, for example, a template or template type (e.g., paid competition vs. free competition). In one embodiment, such an extension technique can be used by the matchmaker engine 108 for event-based extension. For example, when a user queues, the matchmaker engine 108 can schedule a “message” to loop through all users in the queue and match them in a predetermined number of seconds based on their rating differences. If the user has already been matched with another user by the time those messages are processed, no additional matching is required. In such an embodiment, since the matching is event-based, the matching performed by the matchmaker engine 108 when a user queues must be reciprocal in terms of rating differences. For illustrative purposes rather than limitation, suppose a first user has an Elo rating of 1200. The first user requests a synchronous competition and queues. Three users are waiting in the queue: a second user with an Elo rating of 400, a third user with an Elo rating of 1400, and a fourth user with an Elo rating of 1500. In this example, we set a=200, b=2, c=2, and d=800 for equation (4). Therefore, the matchmaker engine 108 can instantly match the first user with any user with a rating difference of less than 200, and expand to 800 points over 10 seconds (if d=800, it can be capped at 800; otherwise, d needs to be modified).In this example, the matchmaker engine 108 can instantly match the first user with the third user because the rating difference is 200 and a=200. However, it takes the matchmaker engine 108 approximately 7 seconds to match the first user with the fourth user (who has a rating difference of 300), and approximately 12 seconds to match the first user with the second user (who has a rating difference of 800).

[0047] The matchmaker engine 108 may utilize additional or alternative extension techniques. For example, the matchmaker engine 108 may utilize variations of the logarithmic algorithm such as equation (5). Y=c*log((rating_delta-m) / b) (5)

[0048] In equation (5), the definitions of the variables and parameters are the same as those explained for the previous equation, where rating_delta is the rating difference. Other extended algorithms are also possible.

[0049] In one embodiment, the matchmaker engine 108 can dynamically adjust the extended algorithm parameters. For example, the extended algorithm parameters can be dynamically adjusted based on real-time user fluidity. A predetermined user fluidity threshold can be used by the matchmaker engine 108 to determine when the extended algorithm parameters may be adjusted. For example, if user fluidity falls below a predetermined user fluidity threshold, the matchmaker engine 108 may adjust the extended algorithm parameters to provide wider matching (e.g., by increasing the maximum rating difference) because there may be fewer users available for matching. Alternatively, if user fluidity exceeds a predetermined user fluidity threshold, the matchmaker engine 108 may adjust the extended algorithm parameters to provide narrower matching (e.g., by decreasing the maximum rating difference) because there may be more users available for matching. As an addition or alternative, the matchmaker engine 108 may modify the extended algorithm parameters based on, for example, time and / or date. For example, the matchmaker engine 108 can modify its extended algorithm parameters to provide narrower matching during peak hours (and / or holidays or weekends), and the matchmaker engine 108 can modify its extended algorithm parameters to provide wider matching during off-peak hours (and / or non-holiday or weekdays).

[0050] As an addition or alternative, the matchmaker engine 108 can tune its expansion algorithm parameters to allow Elo ratings to expand asymmetrically. In such embodiments, the matchmaker engine 108 can expand more quickly in one direction than in the other by using different Elo expansion parameters for upward and downward expansion. Thus, the matchmaker engine 108 can use different expansion algorithm parameters for upward and downward expansion. For illustrative purposes rather than limitation, downward expansion algorithm parameters can provide faster expansion than upward expansion algorithm parameters. In this example, a first available opponent may be 100 Elo below the user, and a second available opponent may be 75 Elo above the user. In this example, even if the first available opponent is further away from the user, the downward expansion is faster, and due to asymmetric expansion, the matchmaker engine 108 can match the first available opponent. Such asymmetric matching may be bucket-based or cohort-based, resulting in the user being matched with opponents in the same bucket, group, or cohort as the user. If a match is not found within a bucket or cohort within a specified time, the matchmaker engine 108 can extend the matchmaking to opponents in different buckets.

[0051] High-speed matching technology in conjunction with Elo rating extension technology can be used for asynchronous client applications, but in some implementations of the present invention, the matchmaker engine 108 can use high-speed matching technology in conjunction with Elo rating extension technology to perform matching, for example, within a synchronous client application. As previously stated, the matchmaker engine 108 can allow a user to queue multiple templates at once or simultaneously (or nearly simultaneously). Once a user selects multiple templates, the multiple templates can be enqueued with respect to each template (for example, by value), for example, in descending order. Once a user enters each queue, the matchmaker engine 108 can use Elo rating extension technology to match that user with other users waiting in the respective queue. For illustrative purposes only and not limiting, a user may be enqueued by the matchmaker engine 108 in the following order: a $20 paid entry competition, then a $5 paid entry competition, then a 20 virtual token free entry competition, then a 5 virtual token free entry competition. The user is immediately placed in a queue for a $20 paid competition, which initiates the Elo rating enhancement technology for the $20 paid competition. After 1 second (for example, using the linear algorithm of equation (1) with m=1 and b=1), the user can be placed in a queue for a $5 paid competition, which initiates the Elo rating enhancement technology for the $5 paid competition. After another 1 second (total of 2 seconds), the user can be placed in a queue for a 20 virtual token free competition, which initiates the Elo rating enhancement technology for the 20 virtual token competition. After another 1 second (total of 3 seconds), the user can be placed in a queue for a 5 virtual token free competition, which initiates the Elo rating enhancement technology for the 5 virtual token competition. As previously stated, the user may remain in the queue of one or more previous templates while enqueuing for one or more additional templates in order to maximize the matchmaker engine 108's ability to identify matches.However, the matchmaker engine 108 can achieve a favorable match in the shortest possible time by using either or both of the high-speed matching technology and the Elo rating enhancement technology individually or collectively.

[0052] In some implementations of the present invention, the matchmaker engine 108 may classify or otherwise organize users into cohorts, groups, or buckets based on any appropriate user characteristics. For illustrative purposes only, and not limiting, in the context of synchronous mobile games, such user characteristics may include, for example, skill rating, total number of games played, total number of games won, number of synchronous games played, number of synchronous games won, or any combination thereof. Other user characteristics and other types of client applications are also possible. For example, a “new” user who has played fewer games than a predetermined number may be classified into a first bucket. Other “experienced” users may be classified into buckets according to their skill rating for mobile games, for example, and each bucket may have a corresponding skill range. Additionally or alternatively, experienced users may be classified into buckets according to the number of games played, the number of games won, and each bucket may have a corresponding number of games played, the number of games won, or any combination thereof. Other characteristics of buckets are also possible. Any suitable number of such buckets can be used by the matchmaker engine 108, and each bucket can be associated with any suitable characteristic of a client application. According to one embodiment of the present invention, a user can be matched with other users in the same bucket. However, in some implementations of the present invention, for example, if a second characteristic is within a predetermined difference or range of a first characteristic, a user in a bucket associated with a first characteristic can be matched with a user in another bucket associated with a second characteristic. As an addition or alternative, matching within a user's bucket can continue for a predetermined period of time before the matching is extended to other user buckets. In other words, in bucket matching, the matching population for a user can be limited to that user's bucket for a predetermined first period of time (e.g., seconds).If a user is unable to find a match within that time frame, the matching can be extended to include users from other buckets, such as users whose respective time slots have expired (i.e., inter-bucket matching). Additionally or alternatively, each bucket can be associated with different parameters for the Elo rating enhancement technique used by the matchmaker engine 108. In other words, the matchmaker engine 108 can assign or associate different variables and parameters used for the Elo rating enhancement technique for each bucket or any bucket, and each set of variables and parameters can be appropriately modified by the matchmaker engine 108 dynamically (e.g., based on real-time user fluidity), based on time, etc.

[0053] As shown in Figure 1, the server system 102 may include a gateway module 110. The gateway module 110 may be configured to support communication between the server system 102 and one or more client devices 134. The gateway module 110 may support any suitable type of communication protocol for transmitting data and information from the server system 102 to another client device 134 via the network 144, and from the other client device 134 to the server system 102 via the network 144. For example, the gateway module 110 may support the standard Internet Protocol (TCP / IP), have a suitable data and signaling channel such as a gRPC gateway, support OpenGL or other suitable technology, or have any other suitable form of communication channel, whether wired or wireless. In some implementations of the present invention, the gateway module 110 may, as an addition or alternative, include a TURN (Traversal Using Relay NAT) server (e.g., a STUN (Session Traversal Utilities for NAT) server) to support the communication of video / audio data between the server system 102 and the client devices 134. As an addition or alternative, the gateway module 110 may be equipped with a suitable encoder for encoding video, for example, h.264 or VP8 for WebRTC. However, other suitable server communication protocols, encoding techniques, and / or transmission protocols are also possible for use within or with the gateway module 110.

[0054] In one embodiment, system 100 may include one or more client devices 134 that communicate with server system 102 via gateway module 110. According to the embodiment, the client device 134 may be any suitable type of device capable of running a suitable client application that allows a user to interact with other users, such as a smartphone, tablet, laptop, desktop computer, game console, smart TV, smartwatch, or any other suitable device. In the embodiment, server system 102 may support any suitable number of client devices 134.

[0055] In one embodiment, the client device 134 may include a client application engine 136 that communicates with a display module 142. The client application engine 136 can support the execution of a client application 138 installed on the client device 134. The client application 138 may include an SDK (Software Development Kit) module 140 that can be integrated into the client application 138. The SDK module 140 can provide the client application 138 with features, functions, and other capabilities to support interaction with a server system 102, including managing matchmaking, competitions or other interactions between users. For illustrative purposes only and not limiting, if the client application 138 is a skill-based single-player mobile game, the SDK module 140 may enable developers to integrate a tournament-enabled gambling platform into the single-player mobile game to transform the single-player mobile game into a competitive esports mobile game. The display module 142 can support the display of video and / or audio information from the client application 138 to the user. In some implementations of the present invention, the display module 142 can accept user input (e.g., touch input) to enable the user to interact with and control the client application 138.

[0056] In some implementations of the present invention, the matchmaker engine 108 may be, for example, a clustered Elixir application that utilizes the Horde actor library (or other suitable library) to distribute processes around a cluster of client application servers. The matchmaker engine 108 may also use, for example, Mnesia for configuration storage. Elixir is a functional language that sits on top of the Erlang virtual machine and can be used to provide a low-latency, distributed, and fault-tolerant system. Horde is a distributed administrator and registry that can provide an implementation of the actor model across remote matchmaker nodes. Mnesia is a distributed database natively associated with Erlang and is therefore compatible with Elixir. For example, Mnesia can be used to store search configurations (for example, for fast matching techniques and / or Elo rating extension techniques), hash rings (described in more detail below), pending matches, and other similar information.

[0057] In some implementations of the present invention, the server system 102 may include a plurality of client application servers 112 for use by and with client applications running on a user's client device 134. The plurality of client application servers 112 may communicate with one or more of the client application activity engine 104, the user details engine 106, and the matchmaker engine 108. Additionally or alternatively, some or all of the plurality of client application servers 112 may be remote from the server system 102 and may communicate with the server system 102. The plurality of client application servers 112 may include any suitable number of client application servers, such as a first client application server 114, a second client application server 116, ..., and an Nth client application server 118, where N can be any suitable natural number. In one embodiment, each of the plurality of client application servers 112 may be assigned or allocated to support a client application during or when matchmaking is performed by the matchmaker engine 108. In some implementations of the present invention, a plurality of client application servers 112 can be configured, for example, as a hash ring. The hash ring can obtain the leading bit of the hash value of an item (e.g., match identification information (ID)) and use this information to determine which node the item should be assigned to. For example, a node on the hash ring can be divided into fragments, each fragment can be assigned an integer value in the appropriate key space, the integer value can range from 1 to a predetermined number (e.g., 2 32It can be a set of integers up to -1, for example. The distribution of these fragments is random, but can be deterministic. The key can then be mapped to a fragment by converting the key to binary, hashing the binary with a suitable hash algorithm (e.g., SHA-256), converting the hash to an integer in the key space, and then finding the fragment to which the next largest value is assigned. If the next largest value does not exist, the smallest integer can be used, and this is how a "ring" can be formed.

[0058] In some implementations of the present invention, hash rings can be managed and maintained within the internal state of a process maintained, for example, by a matchmaker engine 108. Hash rings can be static or dynamic. A static hash ring is one in which nodes are provided in advance and nodes can be manually added / removed at runtime. A dynamic hash ring can be monitored (for example, by the matchmaker engine 108, by using Erlang node monitoring, etc.) and nodes on the hash ring can be automatically added or removed based on cluster membership (e.g., Erlang cluster membership). Thus, a hash ring can be used to store available client application servers 112 and ensure that two users with the same matching ID can connect to the same client application server 112 while distributing matches evenly across the available client application servers 112. In one embodiment, the matchmaker engine 108 can maintain a list of available client application servers 112 by periodically querying a plurality of client application servers 112 (e.g., every 5 seconds, every 10 seconds, every 30 seconds, etc.). When the SDK module 140 on each user's client device 134 is polling the server system 102 for a match to start, the matchmaker engine 108 can, for example, fetch an IP address and port number (or other appropriate address information) from a hash ring based on the hash of the match ID for the two users, thereby ensuring, for example, that both users are sent to and using the same client application server 112 for a match, competition, or tournament within their client application. The fetched client application server 112 can then be used by both users for the duration of the match in the client application 138 running on their respective client devices 134.

[0059] As an addition or alternative, in some implementations of the present invention, the server system 102 may include a client application server pool 120 for use by and with a client application 138 running on a user's client device 134. The client application server pool 120 may communicate with one or more of the client application activity engine 104, the user details engine 106, and the matchmaker engine 108. As an addition or alternative, some or all of the client application server pool 120 may be remote from the server system 102 and may communicate with the server system. The client application server pool 120 may include a “warm” pool 122 of client application servers. For example, each client application server in the warm pool 122 of client application servers may be pre-allocated and pre-instantiated within the pool. By spinning up client application servers in the pool in the background and maintaining those spun-up client application servers in the warm pool, client application servers can be assigned to matches, competitions, or tournaments on demand immediately (or nearly immediately) with little or no associated delay. The client application server warm pool 122 may contain any suitable number of warm client application servers, such as the first warm client application server 124, the second warm client application server 126, ..., and the Mth warm client application server 128, where M can be any suitable natural number. Note that M (of the client application server warm pool 122) and N (of the client application servers 112) may be the same number or different numbers.

[0060] When a warm client application server is allocated and assigned to a match, competition, or tournament, the allocated warm client application server can be replaced immediately (or nearly immediately) within the client application server's warm pool 122 by another warm client application server spun up from the client application server pool repository 130, which communicates with the client application server's warm pool 122. Such a replacement client application server is then ready for immediate (or nearly immediately) assignment and allocation to another match. In this way, client application servers from the client application server's warm pool 122 can be allocated to users in real time. In this disclosure, “real time” may mean processing that can occur instantaneously or within a short time (e.g., a few seconds) so as to minimize the delay between when a request is received and when the request is processed and a response is provided. Computing resources allocated to a client application server for a match, competition, or tournament can be immediately (or nearly immediately) removed or deallocated when the match, competition, or tournament ends and the client application server is no longer needed for that match, competition, or tournament. In some implementations of the present invention, the computing resources thus released can be reallocated, for example, by the matchmaker engine 108, rather than maintaining resources for the allocated client application server that is no longer needed for the completed match, competition, or tournament, to add and warm up another client application server in the client application server warm pool 122.Therefore, in one embodiment, the matchmaker engine 108 may request the client application server pool 120 to allocate a client application server from the client application server warm pool 122 in response to a user's request to join a match. The client application server pool 120 may return one of the client application servers from the client application server warm pool 122, including the IP address and port number (or other appropriate address information) of the warm client application server, to ensure that both users are sent to the same (warm) client application server for the match, competition, or tournament and use the same client application server. At the same time, the client application server pool 120 may spin up a replacement client application server from the client application server pool repository 130 and add the replacement client application server to the client application server warm pool 122. Client application servers are allocated per match, competition, or tournament and can be discarded or deallocated when the match, competition, or tournament ends. In some implementations of the present invention, the client application server pool 120 can use the Agones open-source platform to deploy, scale, and orchestrate dedicated temporary game servers for large-scale multi-user games. However, other server platforms are also possible.

[0061] The size of the client application server's warm pool 122 may be fixed or dynamic. For example, the size of the client application server's warm pool 122 may be fixed so that a predetermined number of warm client application servers can be maintained within the pool. When a client application server is allocated within the client application server's warm pool 122, the client application server pool 120 may replace the allocated client application server with another warm client application server in order to maintain the size of the client application server's warm pool 122 at (or approximately at) the predetermined number of pool sizes. The predetermined number of pool sizes may be based on, for example, usage trends or other historical matching information. Thus, high usage (and more matches) may have or be associated with a larger predetermined number of pool sizes, while low usage (and fewer matches) may have a smaller predetermined number of pool sizes.

[0062] As an addition or alternative, the size of the client application server warm pool 122 may be dynamic. In some implementations of the present invention, the client application server pool 120 can, for example, work with the matchmaker engine 108 to monitor client application usage trends in real time. For example, as usage trends increase, the client application server pool 120 can, for example, work with the matchmaker engine 108 to increase the size of the client application server warm pool 122 to accommodate more usage, so that client application server allocation can continue in real time without additional delay. Conversely, as usage trends decrease, the client application server pool 120 can, for example, work with the matchmaker engine 108 to decrease the size of the client application server warm pool 122 to accommodate less usage, so that computing resources are not unnecessarily overused and can be allocated wherever needed. In such embodiments, the size of the client application server warm pool 122 can be dynamically modified to accommodate increased usage periods (e.g., usage spikes) and usage pauses in order to maintain real-time allocation of client application servers. In some implementations of the present invention, the matchmaker engine 108 can determine the size of the client application server warm pool 122 by including a suitable predictive model or by using a suitable machine learning / artificial intelligence technique. For example, a machine learning model can be trained on usage trend data about client applications to minimize the amount of time allocated to client application servers and maintain reduced allocation times for real-time client application server allocation. The machine learning model can then be used to dynamically and appropriately adjust the size of the client application server warm pool 122 based on usage at a particular time.The machine learning model may be updated or adapted as client application usage trends change and evolve over time, for example, as monitored by the matchmaker engine 108. In some implementations of the present invention, the size of the client application server warm pool 122 may be fixed at some point and dynamic at other points. For example, the size of the client application server warm pool 122 may be fixed during periods of decreased usage. However, during periods of higher usage (e.g., usage spikes) (e.g., intermittent periods), the size of the client application server warm pool 122 may be dynamic. The matchmaker engine 108 may revert the size of the client application server warm pool 122 to fixed once the period of higher usage has ended. In this way, the client application server pool 120 can adapt to changing usage conditions as needed to maintain reduced allocation times for real-time allocation of client application servers.

[0063] In some implementations of the present invention, the matchmaker engine 108 can use HTTP long polling ("long polling") for the matchmaking process. Long polling is a technique for maintaining a persistent connection with the server system 102. Long polling can be used to push information from the server system 102 to the client device 134 as quickly as possible, and the server system 102 can send or push data to the client device 134 on its own without the client device 134 making a request, so that information is pushed as it becomes available. As a result, the server system 102 does not have to wait for the client device 134 to send a request. When the server system 102 receives a request from the client device 134, it does not close the connection with the client device 134. Instead, the server system 102 responds only if a new message is available or if a timeout threshold is reached. The connection is closed and re-established only when a message is delivered from the server system 102. Therefore, upon receiving a response, client device 134 immediately sends a new request to server system 102 to have a new pending connection for sending data to client device 134, and the operation is repeated. In this manner, server system 102 can emulate real-time server push functionality.The matchmaker engine 108 can use long polling to perform a variety of functions, including enqueuing (e.g., entering the matching process for a template selection), dequeuing (e.g., exiting the matching process for all templates), retrieving matches (e.g., polling the endpoint to ask the matching process if a match has been found), confirming (e.g., selecting a "Confirm" or "Play" button to indicate that the user is ready to start a match), and checking for start (e.g., polling the endpoint to ask the matching process if a tournament has been created, and if so, fetching connection information to the client application server).

[0064] Other functionalities are also possible. As mentioned earlier, the matching itself can be event-based and can be performed in memory (using actors) via a dictionary ordered per template.

[0065] Figure 3 is a block diagram showing an example 300 of matchmaking for a user of a client application executed by a matchmaker engine 108 using an actor design pattern according to an embodiment of the present disclosure. In one embodiment, the matchmaker engine 108 can interact with a client application activity engine 104 and a user detail engine 106 to support a matchmaker enqueue process. To initiate the matchmaker enqueue process, user 302 (for example, the enqueue process also applies to users 304 and 306) can select a list of templates within the user interface of a client application 138 running on user 302's client device 134. The SDK module 140 can send a request to the server system 102. The request may include, for example, a user ID, a list of template IDs, a device ID of the client device 134, and whether the match is a robot match or not. Additional or alternative information may also be included in the request. The gateway module 110 can accept the request and create a request context that can be forwarded to the client application activity engine 104. The client application activity engine 104 can fetch information from the user details engine 106 to verify that user 302 is permitted to participate in each selected template. Such information can be used to determine, for example, whether user 302 is in a paid participation location, whether user 302 is registered, and whether user 302 has sufficient currency (for example, to participate in a paid competition). The client application activity engine 104 can sort the list of template IDs by type and value, for example, from highest to lowest for paid competition templates, followed by from highest to lowest for free competition templates, although other methods of sorting the list of template IDs are also possible.The client application activity engine 104 can write or store enqueue events in the database 132. The client application activity engine 104 can also fetch user quarantine information from the user details engine 106. The client application activity engine 104 can construct an appropriate match data object, which may include, for example, a sorted template list, user ID, user rating, all competitions played (e.g., matches), SDK version, whether it is a robot match, client application ID, client device platform, whether the user is quarantined, a list of blacklisted users, and the client application version. Other information may also be available for the match data object. The match data object can be passed to the matchmaker engine 108. The matchmaker engine 108 may fetch additional details from other services (e.g., user statistics service) as needed, such as the number of synchronous competitions played and the number of synchronous competitions won. At this stage, the matchmaker engine 108 has all the data necessary to find a match. The matchmaker engine 108 can create a player actor 308 and start the matching process asynchronously (for example, using fast matching techniques) and respond with an empty enqueue response. After the client application activity engine 104 receives an empty enqueue response from the matchmaker engine 108, the client application activity engine 104 can request an estimated latency and return the estimated latency to the gateway module 110. The gateway module 110 can respond to the SDK module 140 on the client device 134 with the estimated latency as a response for display to the user 302 via the display module 142.

[0066] Once the matchmaker engine 108 has all the data necessary to find a match, it can check whether a player actor already exists for the user ID and client application ID. If it does, the matchmaker engine 108 can return an appropriate error message (for example, to be displayed to the user via the display module 142 on the client device 134) to ensure that user 302 is in the client application queue only once. If it does not exist, the matchmaker engine 108 can create a player actor 308 that can be addressed by the user ID and client application ID and send it a "Get in Matchmaker" message. Once player actor 308 is created, the initialization function within player actor 308 can start sending heartbeat messages to itself (at configurable intervals) to determine whether user 302 is still in the queue. If user 302 does not reach the "Get Match" polling endpoint within the entire timeout interval, player actor 308 can terminate. The initialization function can also configure the maximum lifespan of player actor 308 and set up appropriate cleanup functions that can be executed when player actor 308 terminates. When player actor 308 puts a message into the matchmaker and processes it, it can log events by sending SQS (Simple Queue Service) messages, etc., send an enqueue message to itself using the first template in the list, and schedule an enqueue message for the next template (e.g., a template associated with template actor 316) with an appropriate delay based on an extension technique (e.g., formula (5) or other extension techniques). When player actor 308 processes an enqueue message, it can send the enqueue message to template actor 314 specified in the message.When processing an extended message, player actor 308 can send an enqueue message to a specified template actor 314, increment an extended index, and schedule another extended message to the next template (e.g., a template associated with template actor 316) based on an extended technique (e.g., expression (5) or other extended techniques).

[0067] In one embodiment, the template actor may be a long-lived actor capable of representing the queue for each template, as described above, and handling most of the matching logic. When processing an enqueue message, the template actor 314 can store users in its in-memory queue (which is an ordered dictionary, as described above). If there are two or more users in the queue, the template actor 314 can filter the ordered dictionary for any match using the maximum rating delta specified by the augmentation algorithm. For each user in the maximum rating delta, the template actor 314 can schedule a match message calculated based on the difference between the users (e.g., Elo difference). Many match messages may be sent, but only the first message processed can represent a match. This allows the matchmaker engine 108 to identify the fairest match at the same speed that the augmentation algorithm enables without polling the queue, and searches are performed on the queue only when a new user enters the queue. When processing a match message, the template actor 314 can first check whether both users are already in the queue. If not, the message can be ignored. This can often happen when many match messages are being processed. If both users are still in the queue, a match ID can be created (e.g., via a randomly generated 128-bit universally unique identifier such as UUID4), a pending match data object can be created and stored in Mnesia, for example, and a match actor 322 can be created that can be addressed by the match ID. The dequeued message can be sent to each template actor 314, 316, 318, and 320 in the enqueued template list. Each player actor (e.g., player actor 308, player actor 310, and player actor 312) can send a termination message indicating that a match was found.When a template actor processes a dequeued message, the user may be removed from the ordered dictionary. When a match actor 322 processes a confirmation message, it may add the user to the list of confirmed users. When a match actor 322 processes a ready-to-start message, it may check whether both users have confirmed. If both users have confirmed, the matchmaker engine 108 may retrieve client application server information for the match. For example, in the case of client application servers from multiple client application servers 112, the matchmaker engine 108 may fetch an IP address / port pair from a hash ring for a given match ID. In the case of client application servers from client application server pool 120, the matchmaker engine 108 may request the allocation of a warm client application server from the warm pool 122 of client application servers for the match.

[0068] Therefore, template expansion performed by the matchmaker engine 108 can be initiated by searching for the highest-rated selected template (e.g., the 10z template associated with template actor 314 shown in Figure 3) within the user 302's specified skill range in a template order (e.g., according to formula (5) or other expansion techniques). Skill range expansion by the matchmaker engine 108 can occur after a calculated number of seconds (determined, for example, by formula (5) or other expansion techniques) and is linked to each template. Alternatively, after the determined number of seconds, the matchmaker engine 108 may add the next highest-rated template (e.g., the 5z template associated with template actor 316 shown in Figure 3) within the user 302's specified skill range. Such expansion processes can continue until a match is identified or the user 302 reaches the maximum skill range for each selected template. In some implementations of the present invention, matching performed by the matchmaker engine 108 can be limited to a predetermined period (e.g., 5 minutes, 1 hour, 1 day, etc.) so that matching does not continue indefinitely. According to such an embodiment, if a match is not found within a predetermined period (for example, encompassing all selected templates), the user may be automatically awarded a win for the competition or tournament.

[0069] In some implementations of the present invention, for matchmaker polling, the matchmaker engine 108 may check for the existence of pending matches for users in Mnesia and return a match ID if any pending matches exist. Otherwise, the matchmaker engine 108 may not return any content if no pending matches are found. To initiate matchmaker confirmation and checking, the matchmaker engine 108 may send a confirmation message to the match actor 322.

[0070] Therefore, in the case of the enqueue function, the message flow can run from the gateway module 110 to the client application activity engine 104 and then to the matchmaker engine 108. In the case of the dequeue function, the message flow can run from the gateway module 110 to the matchmaker engine 108. In the case of polling for a match, the message flow can run from the gateway module 110 to the matchmaker engine 108. When checking for a match, the message flow can run from the gateway module 110 to the client application activity engine 104 and then to the matchmaker engine 108. When checking for a match to start, the message flow can run from the gateway module 110 to the matchmaker engine 108.

[0071] In some implementations of the present invention, to ensure fair competition within a synchronous client application, the server system 102 may be configured to generate one or more pseudorandom number seeds for use by the synchronous client application to generate one or more pseudorandom numbers. Since the random numbers can be used within the client application engine to determine elements and properties of the client application (for example, in the context of a mobile game, which obstacles are present can be determined based on the values ​​returned by the random number generator), the use of common random numbers can provide a common client application experience to a subset of users (e.g., users participating in a particular match, competition, or tournament within the client application). A common client application experience can be used to standardize (or level the playing field) for client applications that still have random elements. For illustrative purposes rather than limitation, Tetris can be considered a game of skill, but the order in which Tetris pieces are presented to the user is usually random. By providing a common stream of pseudorandom number seeds to each client application instance participating in an online competition or tournament, the order in which random elements (e.g., Tetris pieces) appear to each user can be common across all participating client application instances. Therefore, the results of the competitive tournament are based entirely on skill, rather than, for example, a random chance of getting an easier order of presented Tetris pieces. In some implementations of the present invention, the server system 102 can use a match ID (or other information that uniquely identifies a match) as a seed to generate one or more pseudorandom seeds. One or more pseudorandom seeds may be characterized by a unique match ID. For example, a match ID can be used as input to a suitable pseudorandom seed generation algorithm to generate one or more pseudorandom seeds. Alternatively, one or more pseudorandom seeds can be generated and associated with a match ID (for example, in a lookup table or other suitable structure).A pseudorandom seed corresponding to the match ID is read by the server system 102 and can be sent to each user in the competition once the matching process described herein is successfully completed. The client application engine 136 in each user's client device 134 in the match can use one or more pseudorandom seeds (in appropriate pseudorandom generators) to generate the same one or more pseudorandom numbers in the same order, so that each user in the match can interact with the same client application experience (e.g., the same gameplay experience in contextual mobile games). In other words, one or more pseudorandom numbers can be used so that the start of the client application experience for a particular client application instance (e.g., a match, competition, or tournament) is common among users within that client application instance. However, the start of the client application experience may differ between client application instances registered for different matches, competitions, or tournaments. Consequently, client application interactions may differ between different matches, competitions, or tournaments, but not between client application instances involved in a given match, competition, or tournament.

[0072] In some implementations of the present invention, the server system 102 may use a tick-based processing system so that incoming messages are not processed until the next tick, and updates to users are not broadcast or sent until the next tick. A tick-based processing system for the server system 102 can serve several purposes. For example, a tick-based processing system can provide a consistent service SLA. The server system 102 can respond at tick-rate intervals, meaning that each broadcast remains consistent regardless of the load on the server system 102. This is useful for providing a consistent user experience and supporting easier implementations such as client-side interpolation of frames. Furthermore, a tick-based processing system can provide fair processing of client inputs. By setting a reference frame, ticks can allow the server system 102 to define the interval at which inputs are said to have occurred "simultaneously". For example, if the tick rate is set sufficiently high (longer than the latency for both connected users), there may be no benefit of fairness for a user who is physically closer to (or has a faster connection to) the server system 102. One potential problem that may be introduced in a tick-based processing system is that the server system 102 must determine the order in which messages occurring within the same tick are processed. For illustrative purposes only, not limiting, two users in a mobile game pick up an item from the ground with the same tick. Which user should the server system 102 consider to have picked up the item? The server system 102 could assign an ID to each user (e.g., based on an IP address or other identifying information), and the order could remain static throughout the session. However, such a solution could be problematic, as it would allow users to discover the order by observing their interaction with the mobile game, potentially benefiting from it. Alternatively, the server system 102 could periodically shuffle the order randomly.However, such solutions can also have problems, as there may be intervals in which users could discover and exploit those gains / losses, and randomization can be costly from a computational standpoint. To address these and other problems, in some implementations of the present invention, the server system 102 can simply reverse the order with each single tick. Such a solution is fast because it does not rely on a randomization algorithm. Such a solution is also resilient to fraud, as each user's input is shuffled tens of times or more per second, preventing it from being possible to identify when a user has a gain. Even if it were possible to identify when a user has a gain, it would be shuffled many times before the user has time to use the gain.

[0073] In some implementations of the present invention, one or more of the client application servers can be used by the server system 102 as an authoritative client application server. In one embodiment, any or all client application state information can be stored in the authoritative client application server. In such a configuration, client devices 134 are not considered “trusted”. Each client device 134 can send a request to the server system 102 to adjust client application state information (e.g., during a match, competition, or tournament), and the request may be forwarded to and processed by the authoritative client application server. The authoritative client application server can validate the request. If the request is validated, the authoritative client application server may broadcast the updated client application state information in the next tick. Since requests that are not validated by the authoritative client application server or are determined to be invalid are not processed, such a mechanism can ensure that there is no cheating with respect to client devices 134 during a match, competition, or tournament. At the end of a match, competition, or tournament, the client application server may report the client application state information of both users (e.g., scores) directly to the server system 102 (e.g., the matchmaker engine 108). Such inter-server reporting of client application state information can significantly improve the resilience of server system 102 against man-in-the-middle (MITM) or other malicious attacks against system 100, which may negatively impact other less robust client application server architectures (e.g., peer-to-peer, deterministic lockstep, etc.).

[0074] In some embodiments of the present invention, a matchmaker token can be used to prevent MITM and other similar malicious attacks by assuring a client application server that a match, competition, or tournament originated from the matchmaker engine 108. In one embodiment, once a match is created, the matchmaker engine 108 may asymmetrically encrypt the current timestamp (e.g., when the match was identified or created) (e.g., via RSA or another suitable encryption algorithm), and send a matchmaker token with the encrypted timestamp to the client device 134 along with the IP / port of the client application server to which the client device 134 connects (as described above). Upon connecting to the indicated client application server, the client application 138 may return the encrypted token to the client application server (via the SDK module 140). The client application server may attempt to decrypt the encrypted token. The client application server can only successfully decrypt the encrypted token if the encrypted token was encrypted with a key held and used by the matchmaker engine 108. If decryption is successful, the client application server can "see" or access the timestamp of when the match was identified or created, thus confirming that the match, competition, or tournament was provided by or originated from the matchmaker engine 108. In this way, the client application server can reject connections associated with matches, competitions, or tournaments that are not from the matchmaker engine 108. In some implementations of this application, the timestamp may have or be associated with an expiration period or expiration window (e.g., one hour after the match was created, one day after the match was created, etc.).As a result, if the client application server successfully decrypts the timestamp, it can analyze the timestamp to determine whether the token has expired (i.e., whether the timestamp has exceeded its expiration window). If the token has expired, the client application server can reject the connection associated with the given match, competition, or tournament. In this way, the client application server can prevent expired matches, competitions, or tournaments from being potentially used in malicious attacks against the server system 102.

[0075] Figure 4 is a flowchart of an exemplary method 400 for managing user-to-user interactions in a client application. In some implementations of the present invention, method 400 can be performed by a server system 102. In block 405, the server system 102 can receive a first request from a first client device (e.g., one of the client devices 134) among a plurality of client devices running a client application (e.g., client application 138) to initiate an electronically interactive session within the client application with one or more other client devices among the plurality of client devices, based on a first plurality of interaction templates selected on the first client device. In one embodiment, the first client device may be simultaneously enqueued to each of the first plurality of interaction templates. In one embodiment, each of the first plurality of interaction templates may be associated with each different matchmaker instance of a plurality of matchmaker instances. In block 410, the server system 102 can receive a second request from a second client device among a plurality of client devices (e.g., one of the client devices 134) to initiate an electronically interactive session in a client application with one or more other client devices based on a second plurality of interaction templates selected on the second client device. In one embodiment, the second client device may be simultaneously enqueued to each of the second plurality of interaction templates. In block 415, the server system 102 can determine an electronically interactive session between a first client device and a second client device based on the identification of a match between one of the first plurality of interaction templates and one of the second plurality of interaction templates, using one or more matchmaker instances among a plurality of matchmaker instances (e.g., via the matchmaker engine 108 using actor design patterns).In block 420, the server system 102 can allocate a client application server from a pool of pre-instantiated client application servers (e.g., client application server pool 120) for use with a client application during an electronically interactive session, and another pre-instantiated client application server is added to the pool of pre-instantiated client application servers (e.g., from the client application server pool repository) to replace the allocated client application server. In block 425, the server system 102 can provide an electronically interactive session between a first client device and a second client device within the client application. In one embodiment, the allocated client application server can be deallocated upon completion of the electronically interactive session.

[0076] The subject matter described herein offers numerous technical advantages. For example, by using one client actor per client application template, the present invention can support linear scaling and in-memory matching, can be event-driven without requiring memory locks or redundant work, and thereby substantially improves the utilization of computer resources. In other words, by using template actors, the matchmaker engine 108 can scale to support simultaneous matchmaking for a large number of users, such as hundreds of thousands, millions, tens of millions, or more. Thus, some implementations of the present invention can improve the efficiency and processing power of computer hardware resources (e.g., computer processing and memory) to identify matches by supporting and providing substantially faster matching times, particularly for client applications with a large number of users. For example, some implementations of the present invention can more efficiently handle the enqueuing of a large number of users and identifying matches in multiple templates simultaneously. By improving the speed and efficiency of matching for client applications with a large number of users, computer hardware resources can be released more quickly and used for other tasks and processes, resulting in a significant improvement in the utilization of computer resources.

[0077] Figure 5 is a block diagram of an exemplary computing device 500 according to this embodiment, capable of performing one or more of the operations described herein. The computing device 500 may be connected to other computing devices in a LAN, intranet, extranet, and / or the Internet. The computing device 500 may operate as a server machine in a client-server network environment or as a client in a peer-to-peer network environment. The computing device 500 may be provided by a personal computer (PC), a set-top box (STB), a server, a network router, a switch or bridge, or any machine capable of executing a set of instructions (sequential or otherwise) that specify the actions to be taken by the machine. Furthermore, although only a single computing device 500 is shown, the term “computing device” should also be interpreted to include any set of computing devices that execute a set of instructions (or multiple sets) individually or together to perform the methods described herein.

[0078] An exemplary computing device 500 may include computer processing devices 502 (e.g., general-purpose processors, ASICs, etc.), main memory 504, static memory 506 (e.g., flash memory, etc.), and data storage devices 508, which can communicate with each other via a bus 530. The computer processing devices 502 may be provided by one or more general-purpose processing devices, such as a microprocessor, a central processing unit, etc. In exemplary examples, the computer processing device 502 may comprise a composite instruction set computing (CISC) microprocessor, a reduced instruction set computing (RISC) microprocessor, a very long instruction word (VLIW) microprocessor, or a processor that implements a processor or combination of instruction sets, or other instruction sets. The computer processing device 502 may also comprise one or more dedicated processing devices, such as application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), digital signal processors (DSPs), network processors, etc. The computer processing device 502 may be configured to perform the operations described herein in accordance with one or more aspects of this disclosure in order to perform the operations and steps described herein.

[0079] The computing device 500 may further include a network interface device 512 that can communicate with the network 514. The data storage device 508 may include a machine-readable storage medium 528 that may store one or more sets of instructions according to one or more aspects of the present disclosure (e.g., instructions for performing the operations described herein). The instructions 518 that implement the core logic instructions 526 may also reside entirely or at least partially in the main memory 504 and / or the computer processing device 502 during their execution by the computing device 500, the main memory 504, and the computer processing device 502, which also constitute the computer-readable medium. The instructions may be further transmitted or received over the network 514 via the network interface device 512.

[0080] Although the machine-readable storage medium 528 is shown as a single medium in the illustrative examples, the term “computer-readable storage medium” should be interpreted to include a single or multiple mediums that store one or more sets of instructions (e.g., a centralized or distributed database and / or associated caches and servers). The term “computer-readable storage medium” should also be interpreted to include any medium capable of storing, encoding, or carrying a set of instructions for machine execution, causing a machine to perform the methods described herein. Thus, the term “computer-readable storage medium” should be interpreted to include, but not be limited to, solid-state memory, optical media, magnetic media, and the like.

[0081] The subject matter and embodiments of operation described herein may be implemented in digital electronic circuits, including the structures disclosed herein and their structural equivalents, or in computer software, firmware, or hardware, or in one or more combinations thereof. Embodiments of the subject matter described herein may be implemented as one or more modules of computer programs, i.e., computer program instructions, encoded on a computer storage medium for execution by a data processing device or for controlling the operation of a data processing device. Alternatively or additionally, program instructions may be encoded on artificially generated propagating signals, such as machine-generated electrical, optical, or electromagnetic signals generated to encode information for transmission to a suitable receiving device for execution by a data processing device. The computer storage medium may be, or include, a computer-readable storage device, a computer-readable storage board, a random-access or serial-access memory array or device, or one or more combinations thereof. Furthermore, although the computer storage medium is not a propagating signal, the computer storage medium may be the source or destination of computer program instructions encoded within an artificially generated propagating signal. Computer storage media can also be, or be contained within, one or more separate physical components or media (e.g., multiple CDs, disks, or other storage devices).

[0082] The operations described in this disclosure can be implemented as operations performed by a data processing device on data stored in one or more computer-readable storage devices or received from other sources.

[0083] The term “data processing device” encompasses all kinds of devices, machines, and equipment for processing data, including, for example, programmable processors, computer processing devices, computers, systems on a chip, or a combination of the above. Computer processing devices may include one or more processors, such as FPGAs (Field-Programmable Gate Arrays) or ASICs (Application-Specific Integrated Circuits), central processing units (CPUs), or multi-core processors that may contain dedicated logic circuits. In addition to hardware, a device may also include code that creates an execution environment for the computer program in question, such as processor firmware, protocol stacks, database management systems, operating systems, cross-platform runtime environments, virtual machines, or code that constitutes one or more of these. Devices and execution environments can realize a variety of different computing model foundations, such as the foundations for web services, distributed computing, and grid computing.

[0084] Computer programs (also known as programs, software, software applications, scripts, or code) can be written in any form of programming language, including compiled or interpreted languages, declarative languages, procedural languages, or functional languages, and can be deployed in any form, including as standalone programs or as modules, components, subroutines, objects, or other units suitable for use in a computing environment. Computer programs may, but do not have to, correspond to files in a file system. A program can be stored in part 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 collaborative files (e.g., files that store one or more modules, subprograms, or parts of code). Computer programs can be deployed to run on one computer, located in one site, or distributed across multiple sites and interconnected by a communication network.

[0085] The processes and logic flows described herein can be executed by one or more programmable processors that execute one or more computer programs to perform actions by acting on input data and producing outputs. The processes and logic flows can also be executed by dedicated logic circuits, such as FPGAs (Field-Programmable Gate Arrays) or ASICs (Application-Specific Integrated Circuits), and the devices can also be implemented as dedicated logic circuits.

[0086] Processors suitable for executing computer programs include, for example, both general-purpose and dedicated microprocessors, as well as any one or more processors in any type of digital computer. Generally, a processor receives instructions and data from read-only memory, random-access memory, or both. Essential elements of a computer are a processor for performing actions according to instructions, and one or more memory devices for storing instructions and data. Generally, a computer also includes one or more mass storage devices for storing data, such as magnetic disks, magneto-optical disks, optical disks, solid-state drives, etc., or is operablely coupled to them to receive data from them, transfer data to them, or both. However, a computer does not necessarily have such devices. Moreover, a computer can be incorporated into another device, for example, a smartphone, a mobile audio or media user, 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 just a few. Devices suitable for storing computer program instructions and data include, for example, semiconductor memory devices such as EPROM, EEPROM, and flash memory devices; magnetic disks such as internal hard disks or removable disks; magneto-optical disks; and all forms of non-volatile memory, media, and memory devices, including CD-ROM and DVD-ROM disks. Processors and memory may be complemented by or incorporated into dedicated logic circuits.

[0087] To provide user interaction, embodiments of the subject matter described herein can be implemented on a computer having a display device for displaying information to the user, such as a CRT (cathode ray tube), LCD (liquid crystal display) monitor, or LED monitor, and a keyboard and pointing device, such as a mouse, trackball, touchpad, or stylus, thereby allowing the user to provide input to the computer. Other types of devices can also be used to provide user interaction; for example, feedback provided to the user may be any form of sensory feedback, such as visual feedback, auditory feedback, or haptic feedback, and input from the user may be received in any form, including acoustic, speech, or haptic input. Other possible input devices include touchscreens or other touch-sensor devices such as single-point or multi-point resistive or capacitive trackpads, speech recognition hardware and software, optical scanners, optical pointers, digital image capture devices, and associated interpretation software. In addition, a computer can interact with a user by sending resources to a device used by the user and receiving resources from that device, for example, by sending a web page to a web browser on the user's client device in response to a request received from a web browser.

[0088] Embodiments of the subject matter described herein can be implemented in a computing system including, for example, a backend component as a data server, or a middleware component (e.g., an application server), or a frontend component (e.g., a client computer having a graphical user interface or web browser that a user can interact with in an implementation of the subject matter described herein), or in any combination of one or more such backend, middleware, or frontend components. The components of the system can be interconnected by digital data communications in any form or medium, such as communication networks. Examples of communication networks include local area networks ("LANs") and wide area networks ("WANs"), internetworks (e.g., the Internet), and peer-to-peer networks (e.g., ad-hoc peer-to-peer networks).

[0089] A computing system can include clients and servers. Clients and servers are generally remote from each other and typically interact via a communication network. The client-server relationship arises thanks to computer programs running on each computer that have a client-server relationship with each other. In some embodiments, the server sends data (e.g., an HTML page) to the client device (for example, to display data to a user interacting with the client device and to receive user input from the user). Data generated on the client device (e.g., the result of user interaction) can be received from the client device by the server.

[0090] One or more computer systems can be configured to perform a specific operation or action thanks to software, firmware, hardware, or a combination thereof installed on the system that causes the system to perform actions while it is running. One or more computer programs, when executed by a data processing device, can be configured to perform a specific operation or action thanks to containing instructions that cause the device to perform actions.

[0091] Throughout this disclosure, any reference to “one embodiment” or “embodiment” means a specific feature, structure, or characteristic described in relation to an embodiment included in at least one embodiment. Therefore, occurrences of the phrase “in one embodiment” or “in one embodiment” in various places throughout this disclosure do not necessarily all refer to the same embodiment. In addition, the term “or” is intended to mean an inclusive “or” rather than an exclusive “or.”

[0092] While this disclosure includes many details of specific implementations, these should not be interpreted as limitations on the scope of any invention or claimable, but rather as descriptions of features specific to particular embodiments of a particular invention. Certain features described in this disclosure in the context of separate embodiments may also be implemented in combination in a single embodiment. Conversely, various features described in the context of a single embodiment may also be implemented separately or in any suitable partial combination in multiple embodiments. Furthermore, features may be described above as being implemented in a particular combination, and may be initially claimed as such, but one or more features from a claimed combination may, in some cases, be removed from the combination, and the claimed combination may cover a partial combination or a variation of a partial combination.

[0093] Similarly, while the operations and / or logical flows are depicted in the drawings and / or described herein in a specific order, this should not be understood as requiring that such operations and / or logical flows be executed in a specific or sequential order shown, or that all shown operations be executed, in order to achieve the desired result. In certain circumstances, multitasking and parallel processing may be advantageous. Furthermore, 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 together in a single software product or packaged in multiple software products.

[0094] Thus, specific embodiments of the subject matter are described. Other embodiments are within the scope of the following claims. In some cases, the actions enumerated in the claims may be performed in a different order, and the desired results may still be achieved. In addition, the processes depicted in the accompanying drawings do not necessarily require the specific order or sequence shown to achieve the desired results. In certain implementations, multitasking and parallel processing may be advantageous.

[0095] The terms “example” or “exemplary” are used herein to mean that they serve as examples, cases, or illustrations. Any aspect or design described herein as “example” or “exemplary” should not necessarily be construed as being preferable or advantageous to other aspects or designs. Rather, the use of the terms “example” or “exemplary” is intended to present a concept in a specific style. The term “or” as used in this application is intended to mean an inclusive “or” rather than an exclusive “or.” That is, unless otherwise specified or it is evident from the context, “X includes A or B” is intended to mean either of the natural inclusive substitutions. That is, if X includes A, X includes B, or X includes both A and B, “X includes A or B” is satisfied under any of the aforementioned instances. In addition, the articles “a” and “an” as used in this application and the attached claims should generally be construed as meaning “one or more” unless otherwise specified or it is evident from the context that they refer to a singular form. Furthermore, throughout this text, the use of the terms “embodiment,” “one embodiment,” “implementation,” or “implementation” is not intended to mean the same embodiment or implementation unless otherwise stated. In addition, terms such as “first,” “second,” “third,” and “fourth” as used herein are labels to distinguish different elements and do not necessarily have to mean an order that follows their numerical designation.

[0096] In the above description and claims, phrases such as “at least one of ~” or “one or more of ~” may appear, followed by a conjunctive list of elements or features. The term “and / or” may also appear in lists of two or more elements or features. Such phrases are intended to mean any of the enumerated elements or features individually, or any of the enumerated elements or features in combination with any of the other enumerated elements or features, unless implicitly or explicitly contradicted by the context in which they are used. For example, the phrases “at least one of A and B,” “one or more of A and B,” and “A and / or B” are intended to mean “A alone, B alone, or A and B together,” respectively. The same interpretation is intended for lists containing three or more items. For example, the phrases “at least one of A, B, and C,” “one or more of A, B, and C,” and “A, B, and / or C” are intended to mean “A alone, B alone, C alone, A and B together, A and C together, B and C together, or A, B, and C together,” respectively. In addition, the use of the term “based on” in the foregoing and in the claims is intended to mean “at least partially based on” so as to allow for features or elements that are not enumerated.

[0097] The above description of exemplary implementations of the present invention is not intended to be exhaustive or to limit the invention to the very forms disclosed. Specific implementations and examples of the present invention are described herein for illustrative purposes, but various equivalent modifications are possible within the scope of the invention, as will be recognized by those skilled in the art. The subject matter described herein can be put into practice in systems, apparatus, methods, and / or articles, depending on the desired configuration. The implementations described above do not represent all implementations that correspond to the subject matter described herein. Rather, they are merely some examples that correspond to aspects relating to the subject matter described herein. While several variations are described in detail above, other modifications or additions are also possible. In particular, additional features and / or variations can be provided in addition to those described herein. For example, the implementations described above may cover various combinations and partial combinations of the disclosed features, as well as combinations and partial combinations of some of the additional features described above. Other implementations may fall within the following claims.

[0098] Additional non-limiting aspects or embodiments are described in the following numbered clauses.

[0099] Clause 1: At least one data processor receives a first request from a first client device running a client application, requesting to initiate an electronically interactive session within the client application with one or more additional client devices, wherein the first request is based on a first set of interaction templates associated with the first client device, each of which is associated with a set of actors, and each actor in each set of actors is independent of the remaining actors in each set of actors; and at least one data processor receives a second request from a second client device, requesting to initiate an electronically interactive session within the client application with one or more additional client devices, wherein the second request is based on a second set of interaction templates associated with the second client device, each of which is associated with a set of additional actors, and each actor in each set of additional actors is independent of the remaining actors in each set of actors. A method comprising: being independent of the remaining actors among a plurality of additional actors; determining an electronically interactive session between a first client device and a second client device based on the identification of a match between one of a first plurality of interaction templates and one of a second plurality of interaction templates selected on a second client device, wherein the identification of the match is based on a concurrency model that enables scaling to a plurality of servers independently of any architectural modification of the plurality of servers; allocating a client application server from a pool of pre-instantiated client application servers for use with a client application during an electronically interactive session, and providing an electronically interactive session between a first client device and a second client device within a client application, by at least one data processor.

[0100] Clause 2: The method according to Clause 1, wherein a first client device is simultaneously enqueued to each of the first multiple interaction templates, and another pre-instantiated client application server is added to a pool of pre-instantiated client application servers to replace the allocated client application server.

[0101] Clause 3: The method according to Clause 1, wherein each of the first set of interaction templates is associated with each of the matchmaker instances of the set of matchmaker instances.

[0102] Clause 4: The method according to Clause 1, wherein a second client device is simultaneously enqueued to each of the second set of interaction templates.

[0103] Clause 5: The method described in Clause 1, in which each of the multiple actors and each of the multiple additional actors includes behavior or logic.

[0104] Clause 6: The method according to Clause 1, wherein the first actor of each of the multiple actors is capable of modifying a state specific to the first actor, and such modification is independent of the remaining actors of each of the multiple actors, and the second actor of each of the additional multiple actors is capable of additional modification of a state specific to the second actor, and such additional modification is independent of the remaining actors of each of the additional actors of each of the multiple actors.

[0105] Clause 7: The method according to Clause 6, wherein the allocated client application server is unallocated upon completion of the electronic interaction session, the first set of interaction templates is selected on one client device, and the second set of interaction templates is selected on a second client device.

[0106] Clause 8: A system comprising at least one data processor and memory for storing instructions, wherein when an instruction is executed by at least one data processor, it causes at least one data processor to perform an operation, the operation of which at least one data processor receives a first request from a first client device running a client application, requesting to initiate an electronically interactive session within the client application with one or more additional client devices, the first request being based on a first plurality of interaction templates associated with the first client device, the first plurality of interaction templates being associated with each plurality of actors, each actor of each plurality of actors being independent of the remaining actors of each plurality of actors, and at least one data processor initiating a second request from a second client device to initiate an electronically interactive session within the client application with one or more additional client devices. The first request is to receive a request, the second request is based on a second set of interaction templates associated with a second client device, each of which is associated with a set of additional actors, each of which is independent of the remaining actors among the set of additional actors, and the second request is to determine an electronically interactive session between a first client device and a second client device based on the identification of a match between one of the first set of interaction templates and one of the second set of interaction templates selected on the second client device, the identification of the match is based on a concurrency model that enables scaling to multiple servers independently of any architectural modification of the multiple servers, and the first request is to receive a request, the second request is based on a second set of interaction templates associated with a second client device, each of which is associated with a set of additional actors, each of which is independent of the remaining actors among the multiple actors, and the second request is to determine an electronically interactive session between a first client device and a second client device based on the identification of a match between one of the first set of interaction templates and one of the second set of interaction templates selected on the second client device, the identification of the match is based on a concurrency model that enables scaling to multiple servers independently of any architectural modification of the multiple servers, and the second request is to receive a request, the second request is based on a second set of interaction templates associated with a second client device, each of which is associated with a set of additional actors, each of which is independent of the remaining actors among the multiple actors, and set of additional actors, each of which is independent of the remaining actors among the multiple actors, and the second request is based onA system comprising allocating client application servers from a pool of pre-instantiated client application servers, and providing an electronically interactive session between a first client device and a second client device within a client application using at least one data processor.

[0107] Clause 9: The system described in Clause 8, in which a first client device is simultaneously enqueued to each of the first multiple interaction templates, and another pre-instantiated client application server is added to a pool of pre-instantiated client application servers to replace the allocated client application server.

[0108] Clause 10: The system described in Clause 8, in which each of the first multiple interaction templates is associated with each of the multiple matchmaker instances.

[0109] Clause 11: The system described in Clause 8, in which a second client device is simultaneously enqueued to each of the second set of interaction templates.

[0110] Clause 12: The system described in Clause 8, wherein the first actor of each of the multiple actors is capable of modifying the state specific to the first actor, and the modifications are independent of the remaining actors of each of the multiple actors, and the second actor of each of the additional multiple actors is capable of additional modifications specific to the second actor, and the additional modifications are independent of the remaining actors of each of the additional actors.

[0111] Clause 13: The allocated client application server is released upon completion of the electronic interaction session, as described in Clause 8.

[0112] Clause 14: The system described in Clause 13, wherein a first set of interaction templates is selected on a first client device, and a second set of interaction templates is selected on a second client device.

[0113] Clause 15: A non-temporary computer program product that stores executable instructions, which, when executed by at least one data processor forming part of at least one computing system, performs an operation, the operation of receiving a first request from a first client device running a client application, which requests to initiate an electronically interactive session within the client application with one or more additional client devices, the first request being based on a first plurality of interaction templates associated with the first client device, the first plurality of interaction templates being associated with each plurality of actors, each actor of each plurality of actors being independent of the remaining actors of each plurality of actors, and receiving a second request from a second client device, which requests to initiate an electronically interactive session within the client application with one or more additional client devices, the second request being based on a second plurality of interaction templates associated with the second client device, The method includes: having two sets of interaction templates associated with each of several additional actors, with each actor of each set of additional actors being independent of the remaining actors of each set of additional actors; determining an electronically interactive session between a first client device and a second client device based on the identification of a match between one of the first set of interaction templates and one of the second set of interaction templates selected on the second client device, wherein the identification of the match is based on a concurrency model that enables scaling to multiple servers independently of any architectural modification of the multiple servers; allocating a client application server from a pool of pre-instantiated client application servers for use with a client application during an electronically interactive session; and providing an electronically interactive session between the first client device and the second client device within the client application.Non-temporary computer program products.

[0114] Clause 16: A non-transient computer program product as described in Clause 15, wherein a first client device is simultaneously enqueued to each of a first set of interaction templates, each of the first set of interaction templates is associated with each of the matchmaker instances of a set of matchmaker instances, and another pre-instantiated client application server is added to a pool of pre-instantiated client application servers to replace an allocated client application server.

[0115] Clause 17: A non-temporary computer program product as described in Clause 15, in which a second client device is simultaneously enqueued to each of the second set of interaction templates.

[0116] Clause 18: A non-temporary computer program product as described in Clause 15, wherein the determination of an electronically interactive session between a first client device and a second client device is based on the identification of a match between one of a plurality of first interaction templates and one of a plurality of second interaction templates.

[0117] Clause 19: Each of the multiple actors and each of the multiple additional actors, including behavior or logic, constitutes a non-transient computer program product as described in Clause 15.

[0118] Clause 20: The non-temporary computer program product described in Clause 15, wherein the allocated client application server is deallocated upon completion of the electronic interaction session, the first set of interaction templates is selected on the first client device, and the second set of interaction templates is selected on the second client device.

Claims

1. The data processor receives a first request from a first client device running a client application, requesting to initiate an electronically interactive session within the client application with one or more additional client devices, wherein the first request is based on a first set of interaction templates associated with the first client device, each of the first set of interaction templates is associated with a set of actors, and each actor of the set of actors is independent of the remaining actors of the set of actors. The at least one data processor receives a second request from a second client device to initiate the electronically interactive session within the client application with one or more additional client devices, wherein the second request is based on a second set of interaction templates associated with the second client device, the second set of interaction templates being associated with each of the set of additional actors, and each of the set of additional actors being independent of the remaining actors among the set of additional actors. The at least one data processor determines the electronic interaction type session between the first client device and the second client device based on the identification of a match between one of the first plurality of interaction templates and one of the second plurality of interaction templates selected on the second client device, wherein the identification of the match is based on a concurrency model that enables scaling to the plurality of servers independently of any architectural modification of the plurality of servers. The at least one data processor allocates a client application server from a pool of pre-instantiated client application servers for use with the client application during the electronic interaction session, The at least one data processor provides the electronic interaction session between the first client device and the second client device within the client application. Methods that include...

2. The first client device is simultaneously enqueued to each of the first plurality of interaction templates, Another pre-instantiated client application server is added to the pool of pre-instantiated client application servers to replace the allocated client application server. The method according to claim 1.

3. The method according to claim 1, wherein each of the first plurality of interaction templates is associated with each of the plurality of matchmaker instances.

4. The method according to claim 1, wherein the second client device is simultaneously enqueued to each of the second plurality of interaction templates.

5. The method according to claim 1, wherein each of the aforementioned plurality of actors and each of the aforementioned plurality of additional actors includes behavior or logic.

6. The first actor among the aforementioned plurality of actors is capable of modifying a state specific to the first actor, and the modification is independent of the remaining actors among the aforementioned plurality of actors. Each of the aforementioned additional actors, the second actor, is capable of additional modifications to an additional state specific to the second actor, and such additional modifications are independent of the remaining actors among the aforementioned additional actors. The method according to claim 1.

7. The assigned client application server is released upon completion of the electronic interaction session. The first set of interaction templates is selected on the first client device. The second set of interaction templates is selected on the second client device. The method according to claim 6.

8. At least one data processor, Memory for storing instructions and A system comprising, where, when the instruction is executed by the at least one data processor, the at least one data processor causes the operation to be performed, and the operation is The at least one data processor receives a first request from a first client device running a client application, requesting to initiate an electronically interactive session within the client application with one or more additional client devices, wherein the first request is based on a first set of interaction templates associated with the first client device, each of the first set of interaction templates is associated with a set of actors, and each actor of the set of actors is independent of the remaining actors of the set of actors. The at least one data processor receives a second request from a second client device to initiate the electronically interactive session within the client application with one or more additional client devices, wherein the second request is based on a second set of interaction templates associated with the second client device, the second set of interaction templates being associated with each of the set of additional actors, and each of the set of additional actors being independent of the remaining actors among the set of additional actors. The at least one data processor determines the electronic interaction type session between the first client device and the second client device based on the identification of a match between one of the first plurality of interaction templates and one of the second plurality of interaction templates selected on the second client device, wherein the identification of the match is based on a concurrency model that enables scaling to the plurality of servers independently of any architectural modification of the plurality of servers. The at least one data processor allocates a client application server from a pool of pre-instantiated client application servers for use with the client application during the electronic interaction session, The at least one data processor provides the electronic interaction type session between the first client device and the second client device within the client application. including, system.

9. The first client device is simultaneously enqueued to each of the first plurality of interaction templates, Another pre-instantiated client application server is added to the pool of pre-instantiated client application servers to replace the allocated client application server. The system according to claim 8.

10. The system according to claim 8, wherein each of the first plurality of interaction templates is associated with each of the plurality of matchmaker instances.

11. The system according to claim 8, wherein the second client device is simultaneously enqueued to each of the second plurality of interaction templates.

12. The first actor among the aforementioned plurality of actors is capable of modifying a state specific to the first actor, and such modification is independent of the remaining actors among the aforementioned plurality of actors. Each of the additional actors described above, the second actor, is capable of additional modifications to an additional state specific to the second actor, and such additional modifications are independent of the remaining actors described above. The system according to claim 8.

13. The system according to claim 8, wherein the allocated client application server is released upon completion of the electronic interaction type session.

14. The first set of interaction templates is selected on the first client device. The second set of interaction templates is selected on the second client device. The system according to claim 13.

15. A non-temporary computer program product that stores executable instructions, wherein the instructions, when executed by at least one data processor forming part of at least one computing system, perform an operation, and the operation is Receiving a first request from a first client device running a client application, requesting to initiate an electronically interactive session within the client application with one or more additional client devices, wherein the first request is based on a first set of interaction templates associated with the first client device, each of the first set of interaction templates being associated with a set of actors, and each actor of the set of actors being independent of the remaining actors of the set of actors, Receiving a second request from a second client device to initiate the electronic interaction session within the client application with one or more additional client devices, wherein the second request is based on a second set of interaction templates associated with the second client device, the second set of interaction templates being associated with each of the set of additional actors, and each of the set of additional actors being independent of the remaining actors among the set of additional actors, Determining the electronic interaction type session between the first client device and the second client device based on the identification of a match between one of the first plurality of interaction templates and one of the second plurality of interaction templates selected on the second client device, wherein the identification of the match is based on a concurrency model that enables scaling to the plurality of servers independently of any architectural modification of the plurality of servers, For use with the client application during the aforementioned electronic interaction session, a client application server is allocated from a pool of pre-instantiated client application servers, The client application provides the electronic interaction type session between the first client device and the second client device. Non-temporary computer program products, including [specific examples of such products].

16. The first client device is simultaneously enqueued to each of the first plurality of interaction templates, Each of the first interaction templates is associated with each of the matchmaker instances of the multiple matchmaker instances, Another pre-instantiated client application server is added to the pool of pre-instantiated client application servers to replace the allocated client application server. The non-temporary computer program product according to claim 15.

17. The non-temporary computer program product according to claim 15, wherein the second client device is simultaneously enqueued to each of the second plurality of interaction templates.

18. The non-temporary computer program product according to claim 15, wherein the determination of the electronic interaction session between the first client device and the second client device is based on the identification of a match between one of the first plurality of interaction templates and one of the second plurality of interaction templates.

19. The non-temporary computer program product according to claim 15, wherein each of the aforementioned plurality of actors and each of the aforementioned plurality of additional actors includes behavior or logic.

20. The assigned client application server is released upon completion of the electronic interaction session. The first set of interaction templates is selected on the first client device, and the second set of interaction templates is selected on the second client device. The non-temporary computer program product according to claim 15.

Images