Patent Description:
The subject matter described herein relates to controlling operation of a client based on segmentation of a set of clients.

In a video game tournament involving a video game and a large number of players, the players can operate identical clients to play the video game, such as a video game console, Steam, and the like, and the games can be played over a network, such as a local area network, or the Internet.

A recent expansion of video game tournaments played over the Internet, or online video game tournaments, has reflected the overall expansion of computer networks from small local networks to the Internet and the growth of Internet access itself. With the growth of the Internet came the expansion of networked devices, or clients, capable of operating video games, such as mobile devices. Consequently, some devices, or clients, may require different configurations.

Prior art can be found in <CIT> which generally relates to a method and system for providing gambling games and in <CIT> which generally relates to methods and systems for generating tailored game challenges.

In an aspect, data specifying a first segment of a set of clients forming part of a peer-tournament system and first configuration parameters associated with the first segment can be received. The first configuration parameters can specify operation of a first peer tournament interface. The first peer-tournament interface can be integrated into a third-party gaming application. The first peer-tournament interface can provide a peer-to-peer tournament for the third-party gaming application. The first segment, including a first subset of the set of clients forming part of the peer-tournament system, can be determined. A request for initiation of peer-tournament operation can be received from the first peer-tournament interface. The first peer-tournament interface can be integrated into the third-party gaming application. The third-party gaming application can be executing on a first client. The first segment can be determined to include the first client. The first configuration parameters can be transmitted in response to receiving the request for initiation of peer-tournament operation from the first peer-tournament interface. The first configuration parameters can cause the first client to modify operation of the first peer-tournament interface in response to receiving the transmitted configuration parameters.

One or more of the following features can be included in any feasible combination. For example, the first segment can be determined by executing a query of a database. The database can store data characterizing the set of clients forming part of the peer-tournament system. The stored data can specify the first segment of the set of clients. The stored data can include a structured query language expression that can define characteristics of clients within the first segment.

Data characterizing a second segment of the set of clients forming part of a peer-tournament system and second configuration parameters associated with the second segment can be received. The second segment, including a second subset of the set of clients forming part of the peer-tournament system can be determined. The first segment can be determined to include the first client and the second segment can be determined to include the first client. The first segment can include an associated priority that is determined to be greater than an associated priority of the second segment. The first configuration parameters can be transmitted to the first client in response to determining that the first segment includes the associated priority that is greater than the associated priority of the second segment.

Data characterizing a plurality of segments of the set of clients forming part of the peer-tournament system and a plurality of configuration parameters can be received. Each of the plurality of configuration parameters can be associated with at least one of the plurality of segments of the set of clients forming part of the peer-tournament system. The plurality of segments can include the first segment and the plurality of configuration parameters can include the first configuration parameters. The received data characterizing the plurality of segments can be used to determine subsets associated with respective segments of the plurality of segments for each of the plurality of segments. The determined subsets can include subsets of the set of clients forming part of the peer-tournament system. The first client can be determined to be included in at least two of the plurality of segments. The first segment can include an associated priority that is determined to be greater than an associated priority of each other segment of the at least two of the plurality of segments. The first configuration parameters can be transmitted to the first client is in response to the determining that the first segment includes the associated priority that is greater than the associated priority of each other segment of the at least two of the plurality of segments.

A request for peer-tournament operations can be received from a second peer-tournament interface. The second peer-tournament interface can be integrated into a second third party gaming application. The second third-party gaming application can be executing on a second client. The first segment can be determined to include the second client. The first configuration parameters can be transmitted to the second client in response to receiving the request for peer-tournament operation from the second peer-tournament interface. The first configuration parameters can cause the second client to modify operation of the second peer-tournament interface in response to receiving the transmitted first configuration parameters.

The peer-tournament operation for use in executing tournament operation can be determined based on the first configuration parameters associated with the first segment. The determined peer-tournament operation can be transmitted to the first peer-tournament interface.

The first configuration parameters can include chat enabled or disabled, custom matches enabled or disabled, play enabled or disabled, user interface elements to display, tournaments to make available, geographic locations to make available, reconnection tolerance and network latency thresholds.

The peer-tournament system can include a segmentation manager engine, a continuous delivery pipeline, a configuration parameter manager engine, and the set of clients. The segmentation manager engine can be configured to prompt a user for input specifying the first segment of the set of clients. The segmentation engine manager can perform the receiving data specifying the first segment of the set of clients. The segmentation manager engine can be configured to provide the received data specifying the first segment of the set of clients to the continuous delivery pipeline.

The continuous delivery pipeline can be configured to perform the determining of the first segment. The determining of the first segment can include executing a query of a database storing data characterizing the set of clients forming part of the peer-tournament system. The stored data can specify the first segment of the set of clients and can include a structured query language expression that can define characteristics of clients within the first segment. The continuous delivery pipeline can be configured to provide the determined first segment to the configuration parameter manager engine.

The configuration parameter manager engine can be configured to perform the receiving of the request for initiation of peer-tournament operation from the first peer-tournament interface. The configuration parameter manager engine can be configured to perform the determining that the first segment includes the first client. The configuration parameter manager engine can be configured to perform the transmitting of the first configuration parameters to the first client.

The first segment can be determined periodically. The first segment can be determined in a current iteration and a preceding iteration. Clients in the first segment after a preceding iteration of determining the first segment that are determined not to be in the first segment after the current iteration of determining the first segment can be removed. Clients determined to be in the first segment after a current iteration of determining the first segment that were determined not to be in the first segment after a preceding iteration of determining the segment can be added.

The first peer-tournament interface can receive transmitted first configuration parameters. The first peer-tournament interface can modify operation of the first peer-tournament interface in response to receiving in response to receiving the transmitted first configuration parameters.

The first peer-tournament interface can provide the peer-to-peer tournament utilizing the third-party gaming application and according to the first configuration parameters.

In another aspect, a system can include a segmentation server and a tournament server. The segmentation server can be configured to be configured to receive data specifying a first segment of a set of clients forming part of a peer-tournament system and first configuration parameters associated with the first segment. The first peer-tournament interface can be integrated into a third-party gaming application. The first peer-tournament interface can provide a peer-to-peer tournament for the third-party gaming application. The segmentation server can be configured to be configured to determine the first segment, including a first subset of the set of clients forming part of the peer-tournament system.

The tournament server can be configured to receive a request for initiation of peer-tournament operation from the first peer-tournament interface. The first peer-tournament interface can be integrated into the third-party gaming application. The third-party gaming application can be executing on a first client. The first segment can be determined to include the first client. The tournament server can be configured to transmit the first configuration parameters in response to receiving the request for initiation of peer-tournament operation from the first peer-tournament interface. The first configuration parameters can cause the first client to modify operation of the first peer-tournament interface in response to receiving the transmitted configuration parameters.

The segmentation server can be configured to execute a query of a database to determine the first segment. The database can store data characterizing the set of clients forming part of the peer-tournament system. The stored data can specify the first segment of the set of clients. The stored data can include a structured query language expression that can define characteristics of clients within the first segment.

The segmentation server can be configured to receive data characterizing a second segment of the set of clients forming part of a peer-tournament system and second configuration parameters associated with the second segment. The segmentation server can be configured to determine the second segment, including a second subset of the set of clients forming part of the peer-tournament system. The first segment can be determined to include the first client and the second segment can be determined to include the first client. The first segment can include an associated priority that is determined to be greater than an associated priority of the second segment. The segmentation server can be configured to transmit the first configuration parameters to the first client in response to determining that the first segment includes the associated priority that is greater than the associated priority of the second segment.

The segmentation server can be configured to be configured to receive data characterizing a plurality of segments of the set of clients forming part of the peer-tournament system and a plurality of configuration parameters. Each of the plurality of configuration parameters can be associated with at least one of the plurality of segments of the set of clients forming part of the peer-tournament system. The plurality of segments can include the first segment and the plurality of configuration parameters can include the first configuration parameters. The segmentation server can be configured to use the received data characterizing the plurality of segments to determine subsets associated with respective segments of the plurality of segments for each of the plurality of segments. The determined subsets can include subsets of the set of clients forming part of the peer-tournament system. The first client can be determined to be included in at least two of the plurality of segments. The first segment can include an associated priority that is determined to be greater than an associated priority of each other segment of the at least two of the plurality of segments. The segmentation server can be configured to transmit the first configuration parameters to the first client is in response to the determining that the first segment includes the associated priority that is greater than the associated priority of each other segment of the at least two of the plurality of segments.

The tournament server can be configured to receive a request for peer-tournament operations from a second peer-tournament interface. The second peer-tournament interface can be integrated into a second third party gaming application. The second third-party gaming application can be executing on a second client. The tournament server can be configured to determine the first segment to include the second client. The tournament server can be configured to transmit the first configuration parameters to the second client in response to receiving the request for peer-tournament operation from the second peer-tournament interface. The first configuration parameters can cause the second client to modify operation of the second peer-tournament interface in response to receiving the transmitted first configuration parameters.

The tournament server can be configured to determine peer-tournament operation for use in executing tournament operation based on the first configuration parameters associated with the first segment. The tournament server can be configured to transmit the determined peer-tournament operation to the first peer-tournament interface.

A video game tournament can include a competition involving a large number of players playing a video game. Some video game tournaments can involve a multiplayer video game hosted by a single entity, such as the game developer, and can be played over a network, such as a local area network, or the internet. Some tournaments can utilize a peer-to-peer video game tournament platform that can enable eSports tournaments across a wide range of games including games that may not have built in tournament functionality, for example, single player mobile games. In such a peer-to-peer tournament platform, in order to provide the tournament functionality, a peer-to-peer server can work with (e.g., communicate with, work in tandem with, and the like) many different clients executing local game instances. These different clients can include different operating systems (e.g., ANDROID ®, IOS ®, versions thereof, and the like), hardware components, network connection quality, security restrictions, software versions, and the like, such that in order for the clients to compete in the same tournament, they may need to be configured differently. Similarly, the peer tournament server may need to be configured to operate differently for different clients. For example, some clients may be configured to include different network latency threshold requirements, which, if are not met by their respective networks, would result in disabling tournament functionality.

But these client and/or server configuration parameters (also referred to as system settings) may need to be dynamic and may be updated regularly. Because the peer tournament platform can simultaneously enable many different tournaments for many different clients, it may not be feasible for a systems manager to individually update the settings for each client. Accordingly, some aspects of the subject matter described herein can facilitate segmentation of clients within a peer-to-peer video game tournament system, and modification and/or dynamic updating of client and server configuration parameters (e.g., system settings), which can enable dynamic and flexible control of client and tournament operation. The current subject matter can reduce the load on a peer-to-peer video game tournament system's technical infrastructure, reduce the network latency experienced by players, and provide a better overall peer-to-peer video game tournament system.

In some implementations, the current subject matter can group the set of all clients of the tournament platform into segments. For example, users can define a segment of clients based on a client and/or player attribute, such as geographic location, video games played, number of tournaments entered, and the like, and users can link a segment to one or more configuration parameters. This can allow users to specify configuration parameters (which can control operation of the associated clients) by specifying segments, rather than having to specifically control or change the configuration parameters of each individual client. Such an approach can enable a user to determine a segment of players for a particular tournament, and can allow players in a segment to compete in tournaments specific to their respective segment. In some implementations, the current subject matter can include automatic recalculation of segments at predefined time intervals, and can determine a player's segment without querying an entire data warehouse.

<FIG> is a system block diagram <NUM> illustrating an example system that facilitates segmenting a set of clients forming part of a peer-tournament system. The example system can facilitate modification and/or dynamic updating of client and server configuration parameters (e.g., system settings), which can enable dynamic and flexible control of client and tournament operation.

Segmentation system <NUM> can include a segmentation server <NUM>, a continuous delivery pipeline <NUM>, and a tournament server <NUM>. Segmentation server <NUM> can include a segmentation manager engine, or segmentation engine, <NUM>, and a data warehouse interface <NUM>, and can enable the grouping of clients <NUM>; of a set of clients <NUM> into segments. Tournament server <NUM> can include configuration parameter manager engine, or configuration parameter manager, <NUM>, and can enable dynamic and flexible control of a set of clients <NUM> (e.g., during runtime). Attributes <NUM> can be collected from the set of clients <NUM> and stored in a data warehouse <NUM>. The segmentation engine <NUM> can receive segment rules (e.g., definitions) from a user <NUM> through a graphical user interface (GUI) <NUM>. The segment definition can specify attributes <NUM> to be associated with the segment. The segmentation engine <NUM> can provide the segment definition to the continuous delivery pipeline <NUM>. The continuous delivery pipeline <NUM> can schedule the data warehouse interface <NUM> to execute a query on a data warehouse <NUM> based on the provided segment definition. The results of the query can be provided to the data store <NUM> as a segment <NUM>. The segmentation engine <NUM> can receive configuration parameters <NUM>, associate the configuration parameters <NUM> to the segment <NUM>, and store them in a data store <NUM>. The configuration parameter manager <NUM> can receive a request for configuration parameters <NUM>, and can transmit the requested configuration parameters <NUM>.

The set of clients <NUM> can be formed by clients <NUM>i, (where i = <NUM>, <NUM>,. , n), and the clients <NUM>; can be operated by players <NUM>i. Clients <NUM>; can include a mobile device, laptop, video game console, and/or any networked device capable of operating a video game. Each client <NUM>; can include an instance of a third-party gaming application <NUM>i, such as ANGRY BIRDS ® or CANDY CRUSH ®. An instance of a third-party gaming application <NUM>i can include any third-party gaming application in which a peer-tournament interface <NUM>i can be integrated therein. Player skill can determine the outcome of a game, and multiple players <NUM>i can compete against one another in a peer-to-peer tournament. Each instance of a third-party gaming application <NUM>i can be in communication with and receiving game data from a third-party game server. A third-party game server can provide game data necessary to operate the game. In some implementations, instances of third-party gaming applications <NUM>i can exchange game data directly.

Each instance of a third-party gaming application <NUM>i can include a peer-tournament interface <NUM>i. A peer-tournament interface <NUM>i can integrate into a third-party gaming application, and can provide necessary functionality, including user interface components, to enable a player <NUM>; to compete in a peer-to-peer tournament. Peer-tournament interface <NUM>i can communicate with a tournament server <NUM> including a configuration parameter manager <NUM> to initiate peer-tournament operation of a peer-tournament interface <NUM>i (e.g., tournaments available for a player <NUM>; to play). Peer-tournament interface <NUM>i can communicate with a data warehouse interface <NUM> to store attributes <NUM> associated with a player <NUM>; in a data warehouse <NUM>. Attributes <NUM> can include data specifying the properties of clients <NUM>i. Attributes <NUM> associated with a client <NUM>; can include duration on the peer-tournament system, network latency, strength of network connection, geographic location, account creation date, last game played, and the like.

A data warehouse <NUM> (e.g., AMAZON REDSHIFT ®) can include a central repository of data collected from one or more data sources. The data warehouse <NUM> can contain data specifying clients <NUM>; and their associated attributes <NUM>. A data source can include the set of clients <NUM>i. A data warehouse interface <NUM> can communicate data (e.g., attributes) from data sources (e.g., clients) to a data warehouse <NUM>. Data warehouse interface <NUM> can receive a request to execute queries on data warehouse <NUM>, (e.g., from continuous delivery pipeline <NUM>), execute queries on data warehouse <NUM>, receive results of queries (e.g., from data warehouse <NUM>) and transmit query results (e.g., to continuous delivery pipeline <NUM>).

Operation of a peer-tournament interface <NUM>; and associated client <NUM>; can be specified by configuration parameters <NUM> (e.g., system settings). Configuration parameters <NUM> can include data specifying the dynamic and/or flexible control of a client <NUM>; and/or peer-tournament interface <NUM>i. For example, configuration parameters <NUM> can include chat enabled or disabled, custom matches enabled or disabled, play enabled or disabled, user interface elements to display, tournaments to make available, geographic locations to make available, network latency thresholds, and the like.

In some implementations, configuration parameters <NUM> can include offline mode enabled or disabled, game modes to provide (e.g., co-op game mode and/or the like), pending matches to display, completed and/or cancelled matches to display, how games are scored, live event (e.g., tournament and/or the like) cutoff times when no new players can register for the event, warnings related to pending live event cutoff times and the like. Configuration parameters <NUM> can include email verification requirements for playing and/or the like, data collection frequency, the data to collect, max client idle time before aborting, abort warnings, and the like. Configuration parameters <NUM> can include a time interval between new chat messages, the frequency of messages fetched each chat update, the amount of time between message fetch attempts, the maximum number of characters in a message, the amount of time before a message is too old to be loaded in a chat room, the maximum number of messages a player can send in a time frame, the time in which a player can send the maximum number of messages before being rate limited, and the like.

In some implementations, configuration parameters <NUM> can include the base time until a client can reconnect to chat server, the reconnection interval, the maximum time between reconnection attempts, the reconnection tolerance, the amount of time reconnecting before timing out, and the like. Configuration parameters <NUM> can include the number of times play again button appears, whether the start button instantly starts a match, the text appearing on the start button, the length of the welcome back animation, welcome back enabled or disabled, number of client vibrations, API request analytics enabled or disabled, max number of characters in a contact request and the like. Configuration parameters <NUM> can include number of vibrations upon finding an opponent, push notifications when game is backgrounded, and the like. Configuration parameters <NUM> can include displaying modals, GUI elements associated with some and/or any of the operations discussed herein, and the like. Configuration parameters <NUM> can be associated with a segment <NUM> (e.g., as a key-value pair, hash map, and/or the like), and can control tournament server <NUM> and/or client operation of a client <NUM>i. A segment <NUM> can include a set of clients <NUM>; characterized by a shared set of attributes <NUM>, and clients <NUM>; can be segmented by any combination of attributes <NUM>. A segment <NUM> and associated configuration parameters <NUM> can be stored in a data store <NUM>. An example process of segmenting clients <NUM>i into segments is discussed below.

A user <NUM>, such as a tournament system manager, can define a segment <NUM> in a GUI <NUM>. GLTI <NUM> can communicate with a segmentation engine <NUM>, and a segment <NUM> can be defined by specifying a unique name for the segment <NUM>, and a raw SQL statement specifying attributes <NUM> associated with the segment <NUM>. The user <NUM> can specify configuration parameters <NUM> associated with the segment <NUM>. For example, a user <NUM> can name a segment Boston Players, and supply a raw SQL statement specifying an attribute user_location on a table named Players, wherein the Players table is stored in a data warehouse (SELECT user_id, game_id FROM Players WHERE user_location = 'Boston' ; ). A tournament can specify a configuration parameter, and only clients with the specified configuration parameter can access the tournament. The specified configuration parameter segment can be associated with the segment Boston Players, and the tournament will be displayed in a peer-tournament interface <NUM>i for a client <NUM>; in the specified segment <NUM>.

Segmentation engine <NUM> can prompt a user <NUM> to input a segment definition (e.g., a raw SQL statement, and/or the like) into GUI <NUM> specifying (e.g., defining) the segment of the clients. Segmentation engine <NUM> can receive data (e.g., a raw SQL statement, and/or the like) specifying a segment and can communicate the received data to the continuous delivery pipeline <NUM>. Segmentation engine <NUM> can receive data specifying configuration parameters that can be associated with the segment, and communicate the configuration parameters to data store <NUM>.

The continuous delivery pipeline <NUM> can receive the segment definition and determine the segment. To determine the segment, the continuous delivery pipeline <NUM> can communicate with the data warehouse interface <NUM>, and can periodically transmit a request to the data warehouse interface <NUM> to execute a query defined by the segmentation engine <NUM> (e.g., a raw SQL statement specifying segment <NUM>) on data warehouse <NUM>. For example, continuous delivery pipeline <NUM> can transmit a request to data warehouse interface <NUM> every hour, day, and/or the like, to execute a query defined by a raw SQL statement specifying a segment <NUM> on a data warehouse <NUM>. A segment <NUM> can include a result of a query (e.g., the segment <NUM> can include clients <NUM>; with user_id's in a set of records returned by the query).

A segment <NUM>, along with configuration parameters <NUM> that can be associated with the segment, as can be determined above by the continuous delivery pipeline <NUM>, can be stored (e.g., persisted) in a data store <NUM>. The configuration parameter manager <NUM> can receive a request to initiate peer-tournament operations, for example, from a peer-tournament interface <NUM>i integrated into a third-party gaming application <NUM>i executing on a client <NUM>i. The configuration parameter manager <NUM> can determine that the segment <NUM> includes a player <NUM>; operating the client <NUM>i (e.g., by querying a data store <NUM> for a segment <NUM> a player <NUM>i, operating a client <NUM>i, is a member of). The configuration parameter manager <NUM> can transmit configuration parameters <NUM> associated with the segment <NUM> the player <NUM>i is a member of (e.g., a highest priority segment the player <NUM>i is a member of) to the peer-tournament interface 186i, thereby modifying operation of the peer-tournament interface <NUM>i integrated into the third-party gaming application <NUM>i executing on the client <NUM>i.

Data store <NUM> (e.g., ELASTICSEARCH ®) can include a repository for persistently (e.g., permanently, long term, and/or the like) storing and/or managing collections of data. Segment <NUM>, along with configuration parameters <NUM> associated with the segment, can be stored in data store <NUM> (e.g., ELASTICSEARCH ®) that can enable, for example, a client's <NUM>; segment <NUM>, along with configuration parameters <NUM> associated with the segment <NUM>, to be determined without an expensive, with respect to time-complexity, querying operation, (e.g., a sequential scan of the data store <NUM>, and/or the like).

<FIG> is a process flow diagram <NUM> illustrating an example implementation of a process of controlling operation of a tournament server and/or client utilizing segmentation of a set of clients (e.g., players) within a peer-tournament system. The example process can facilitate segmentation of clients within a peer-tournament system, and modification and/or dynamic updating of client and server configuration parameters (e.g., system settings), which can enable dynamic and flexible control of client and tournament operation.

At <NUM>, data can be received characterizing a first segment of clients forming part of a peer-tournament system and first configuration parameters associated with the first segment. The data can be received by segmentation engine <NUM>. The received data can include a characterization of the first segment of clients. The characterization of the first segment of clients can include a precise request for information retrieval from an information system. The precise request for information retrieval can include a structured query language (SQL) statement representing a SQL query, or any query into an information system. The SQL statement can include attributes characterizing the first segment of clients (e.g., location, latency, and the like). The information system can include a relational database, a non-relational database, a key-value database, a data warehouse, or any system for the collection, organization, storage, and communication of information.

The first segment of clients can include one or more clients <NUM>; forming part of a peer-tournament system. The first configuration parameters associated with the first segment can specify operation of a first peer-tournament interface that can be integrated into a third-party gaming application. The first peer-tournament interface can be integrated into the third-party gaming application operating on a client, and can provide a peer-to-peer tournament for the third-party gaming application. Operation of the first peer-tournament interface can include, for example, configuring a client to include different network latency threshold requirements (such as requiring a network latency below a certain latency value), which, if not met by their respective networks, could result in disabling tournament functionality.

At <NUM>, the first segment can be determined using the data received at <NUM>, and the first segment can include a subset of a set of clients forming part of the peer-tournament system. Determining the first segment can include executing a precise request for information retrieval from an information system using the data received at <NUM>. Executing the precise request for information retrieval from an information system can include executing a SQL statement representing a SQL query on an information system (e.g., Amazon Redshift ®), such as the data warehouse <NUM>. The subset of the set of clients forming part of the peer-tournament system can include clients in a set of records returned by the SQL query executed on the information system. For example, if an executed query returns a set of records {client<NUM>, client<NUM>, clients}, then a first segment determined using received data (e.g., a SQL statement representing the executed query) is the set of records returned from executing the query (e.g., the first segment is {client1, client!, client3}).

At <NUM>, a request to initiate peer-tournament operations can be received by a configuration parameter manager (e.g., configuration parameter manager <NUM>). A first player operating a first client can launch a first third-party gaming application executing on the first client to participate in a peer video game tournament, and the first client can be part of a set of clients forming a peer-tournament system. The configuration parameter manager can receive the request to initiate peer-tournament operations facilitating participation in a peer video game tournament. The request to initiate peer-tournament operations can include a request for configuration parameters that can control operation of the first peer-tournament interface (e.g., disabling the display of certain tournaments in a peer-tournament interface if a client has a network latency above a network latency threshold determined by a configuration parameter).

At <NUM>, the first segment can be determined to include the first client. A configuration parameter manager can perform a request for a set of segments of which the first client is a member, and receive the set of segments of which the first client is a member. For example, the configuration parameter manager can query a data store <NUM> containing user_id's associated with each segment of a set of clients forming part of a peer-tournament system for segments associated with a user_id of the first client, and receive a set of segments associated with the first client (e.g., a set of segments {segment<NUM>, segment<NUM>, segments} to which the first client belongs, and the first segment is segment<NUM>). The first segment can be included in the set of segments of which the first client is a member, and therefore, the first segment can be determined to include the first client.

At <NUM>, the first configuration parameters can be transmitted to the first client in response to receiving the request for initiating peer-tournament operations at <NUM>. The first configuration parameters can cause the first client to modify operation of the first peer-tournament interface. For example, operation of the first peer-tournament interface can include disabling peer-tournament functionality, such as peer-to-peer communication (e.g., an ability to chat with other players), in response to the first configuration parameters transmitted to the first client.

<FIG> is a data flow diagram <NUM> illustrating data communication flows between an example implementation of the elements of <FIG> for segmenting a set of clients forming part of a peer-tournament system, for example, as illustrated in <FIG> at <NUM> and <NUM>.

At <NUM>, a user <NUM> defines a segment, and at <NUM> defines configuration parameters, in the GUI <NUM>, that are associated with the segment defined at <NUM> and passed to the segmentation engine <NUM>. For example, the configuration parameters can specify operation of a first peer-tournament interface integrated into a third-party gaming application executing on a first client that is a member of a segment. The segment can be defined as a raw SQL statement including a unique identifier for the segment, as well as a priority for the segment.

At <NUM>, the raw SQL statement defining the segment is associated with an automated job in a continuous delivery pipeline <NUM> that initiates execution of a SQL query of the raw SQL statement at predetermined intervals. At <NUM>, the configuration parameters associated with the defined segment can be persisted into the data store <NUM>. At <NUM> the continuous delivery pipeline <NUM> initiates the automated job, and at <NUM>, the data warehouse interface <NUM> executes the SQL query against the data warehouse <NUM>. At <NUM>, results of the SQL query executed at <NUM> can be returned to the data warehouse interface <NUM>. At <NUM>, results of the SQL query executed at <NUM> can be returned to the continuous delivery pipeline <NUM>. At <NUM>, records in the result set of the SQL query executed at <NUM> can be persisted into the data store <NUM> as the records associated with the segment, and the segment <NUM> can be determined to include a subset of a set of clients forming part of a peer-tournament system.

In some implementation, a data store <NUM> table containing a segment can be updated instead of dropping the data store <NUM> table and repopulating the table with results of a segmentation method (e.g., querying a data warehouse <NUM> with a user <NUM> defined SQL statement representing the segment). A continuous delivery pipeline <NUM> can initiate execution of a SQL query of the raw SQL statement at predetermined intervals to determine a segment (e.g., a current iteration of execution of a SQL query to determine a segment, and a preceding iteration of execution of the SQL query to determine the segment). At a current iteration of determining a segment <NUM>, a data store <NUM> table can already contain a record for the segment <NUM> as determined in a preceding iteration of determining the segment <NUM>. Clients <NUM>; in a segment <NUM> during the preceding iteration of determining the segment <NUM> that are not in the segment <NUM> during the current iteration of determining the segment <NUM> can be removed from the segment <NUM> (e.g., by removing the user_id's of those clients from a record associated with the segment). Clients <NUM>; not in the segment <NUM> during the preceding iteration of determining the segment, that are determined to be in the segment in the current iteration of determining the segment can be added to the segment <NUM> (e.g., by adding the user_id's of those clients to a record associated with the segment). This can reduce overall load on a peer-to-peer video game tournament system's technical infrastructure.

<FIG> is a data flow diagram <NUM> illustrating data communication flow between an example implementation of the elements of <FIG> when determining configuration parameters for a peer-tournament interface integrated into a third-party gaming application operating on a client of a set of clients forming part of a peer-tournament system, for example, as illustrated in <FIG> at <NUM>-<NUM>.

At <NUM>, the configuration parameter manager <NUM> receives a request for configuration parameters, for example, from the peer-tournament interface <NUM>i. The request can be received when the client <NUM>i initiates operation of the third-party gaming application <NUM>i (e.g., by launching the game). At <NUM>, the configuration parameter manager <NUM> can execute a query of the data store <NUM> to determine the segment associated with the client <NUM>i. The client <NUM>; can belong to one and/or more segments. As a result, a highest priority segment from the segments associated with the client <NUM>; can be determined, since configuration parameters associated with a single segment are required for operation of the peer-tournament interface <NUM>i.

At <NUM>, the configuration parameter manager <NUM> receives configuration parameters <NUM>, (e.g., configuration parameters associated with the highest priority segment associated with the first player <NUM><NUM>). At <NUM>, the configuration parameters <NUM> (e.g., configuration parameters associated with the highest priority segment associated with the first player <NUM><NUM>) are transmitted by the configuration parameter manager <NUM> to, for example, the first peer-tournament interface <NUM><NUM>.

At <NUM>, in response to receiving the transmitted configuration parameters, operation of the peer-tournament interface is modified <NUM>. For example, after receiving transmitted first configuration parameters associated with a highest priority segment associated with a first player <NUM><NUM>, a first peer-tournament interface integrated into a first third-party gaming application <NUM><NUM> executing on a first client <NUM><NUM> operated by the first player <NUM><NUM>, the first client can modify operation of the first peer-tournament interface <NUM><NUM> in accordance with the received configuration parameters associated with the highest priority segment associated with the first player <NUM><NUM>.

For example, a player <NUM>i can launch an instance of a third party gaming application <NUM>i. A peer-tournament interface <NUM>i can be integrated into the instance of the third party gaming application <NUM>i, and at <NUM> can send a request for configuration parameters <NUM>. The request for configuration parameters <NUM> can include a request for the segments <NUM> the player <NUM>i is a member of, and can be received by a configuration parameter manager <NUM>. At <NUM>, the configuration parameter manager <NUM> can execute a query of a data store <NUM> for the segments <NUM> the player <NUM>i is a member of. The data store <NUM> can include configuration parameters <NUM> associated with segments <NUM>. At <NUM>, the segments <NUM>, including a highest priority segment, and associated configuration parameters <NUM> can be returned to the configuration parameter manager <NUM>. At <NUM>, the configuration parameter manager <NUM> can transmit the configuration parameters <NUM> associated with the highest priority segment the player <NUM>i is a member of to the peer-tournament interface <NUM>i. At <NUM>, the peer-tournament interface <NUM>i can modify operation of the peer-tournament interface <NUM>i, for example, removing tournaments where the player <NUM>; can experience a network latency higher than a threshold network latency, therefore reducing the network latency the player <NUM>; experiences, and consequently, reducing the network latency experienced by players.

<FIG> is an example user interface <NUM> that can allow users to create a segment. At <NUM> the user <NUM> can enter the name of a segment. At <NUM> the user can enter the rule for determining the clients in the segment (e.g., a SQL statement that, when executed as a query, will return a set of clients that form the members of the segment). To create the segment, the user <NUM> can press the Create User Segment button <NUM>, and to abort defining a new segment, the user <NUM> can press the Close button <NUM>.

Clients can be partitioned into overlapping and/or mutually exclusive segments. <FIG> is an example set of clients partitioned into different subsets, which can be overlapping and/or mutually exclusive. Everyone <NUM> can be a segment that can contains every client of the peer-tournament system. B <NUM> can be a segment containing a subset of everyone <NUM>, and previous B <NUM> can be a segment containing a subset ofB <NUM>.

<FIG> is a diagram of an example ranking of segments based on priority. Some segments, such as current B <NUM> and previous A <NUM> can be mutually exclusive (e.g., no client that is a member of current B <NUM> is also a member of previous A <NUM>). Some segments, such as current <NUM> and B <NUM> can overlap (e.g., some clients can be in both current <NUM> and B <NUM>, but there are also clients that can be in current <NUM> but not B <NUM>, like current A <NUM>). Everyone <NUM> can be a segment that contains every client of the peer-tournament system (e.g., a segment defined with the SQL statement SELECT *). Current A <NUM>, previous A <NUM>, current B <NUM>, previous <NUM>, current <NUM>, B <NUM>, and A <NUM> can be segments with priorities as shown in <FIG>. When a client requests configuration parameters, the set of segments the client is a member of can be determined. However, the client can be a member of multiple segments. As such, a highest priority segment for the client can be determined, and the configuration parameters associated with the highest priority segment can be transmitted to the client. For example, if a client is a member of current A <NUM>, current <NUM>, A <NUM>, and everyone <NUM>, current A <NUM> can be determined to be the highest priority segment, and the configuration parameters associated with current A <NUM> can be transmitted to the client.

Although a few variations have been described in detail above, other modifications or additions are possible. For example, the current subject matter can create partitions (e.g., segments) of the set of clients <NUM>i using SQL queries on attributes <NUM>, like propensity to play, duration on the system, and/or random variables. For example, the random variables can be used to partition clients for A/B testing. Partitions can include millions of clients <NUM>i, and can be defined in a GUI. The data used to create the partitions can be taken from a database and/or a data warehouse (e.g., AMAZON REDSHIFT ®). Configuration parameters (e.g., system settings), such as geographic locations to make available, can be attributed to clients in a partition. For clients in the partition, tournaments with clients from those geographic locations can be displayed in the peer-tournament interface. Clients can be in multiple segments, and each segment can have a numeric priority. Clients can inherit the settings of the segment with the highest priority. Default configuration parameters can be associated with segments that don't have associated configuration parameters. Clients can be reclassified into segments (e.g., via a job on JENKINS ®) at a controllable interval (e.g., hourly).

The current subject matter can allow users to configure partitions/segments of users, and those partitions can be attached to configuration parameters (e.g., system settings), for example, to run A/B tests to evaluate new features (e.g., tournaments), optimize configuration parameters (e.g., what is the furthest client, with respect to geographical distance, that can compete against a given client), and/or the like. It can be desirable to control operation of clients and to maintain a ranked priority of which elements get exposed to which client. Without customizing a gaming platform for each individual client, clients can receive configuration parameters that are irrelevant to the clients. Client peer-tournament interface can display features, options, and/or the like, that can be associated with configuration parameters.

The current subject matter can allow a user to create a segment based on any combination of attributes stored in the data warehouse, and the user can attach any configuration parameters to the created segment. In some implementation, clients can be intentionally excluded from peer-tournament functionality. For example, clients can be determined to be bad actors, and can be excluded from chatting with other clients, and/or the like.

The current subject matter can segment a large number of clients every time a segmentation job runs (e.g., via JENKINS ®, and/or the like). The speed of this process can allow the system to stay up to date with client behavior. Using SQL queries can allow a wide variety of users to interface with the current subject matter in a highly customized way. In some implementations, REDSHIFT ®, MYSQL ®, and JENKINS ® can be used.

The subject matter described herein provides many technical advantages. For example, modification and/or dynamic updating of client and server configuration parameters (e.g., system settings), which can enable dynamic and flexible control of client and tournament operation. The current subject matter can reduce the load on a peer-to-peer video game tournament system's technical infrastructure, and reduce the network latency experienced by players.

To provide for interaction with a user, one or more aspects or features of the subject matter described herein can be implemented on a computer having a display device, such as for example a cathode ray tube (CRT) or a liquid crystal display (LCD) or a light emitting diode (LED) monitor for displaying information to the user and a keyboard and a pointing device, such as for example a mouse or a trackball, by which the user may provide input to the computer. For example, feedback provided to the user can be any form of sensory feedback, such as for example visual feedback, auditory feedback, or tactile feedback; and input from the user may be received in any form, including acoustic, speech, or tactile input. Other possible input devices include touch screens or other touch-sensitive devices such as single or multi-point resistive or capacitive trackpads, voice recognition hardware and software, optical scanners, optical pointers, digital image capture devices and associated interpretation software, and the like.

Claim 1:
A computer implemented method (<NUM>) comprising:
receiving (<NUM>) first data specifying a first segment of a set of clients forming part of a peer-tournament system and first configuration parameters associated with the first segment, the first configuration parameters specifying operation of a first peer-tournament interface integrated into a third-party gaming application, the first peer-tournament interface providing a peer-to-peer tournament for the third-party gaming application;
receiving second data characterizing a second segment of the set of clients forming part of the peer-tournament system and second configuration parameters associated with the second segment;
determining (<NUM>), using the received first data, the first segment including a first subset of the set of clients forming part of the peer-tournament system;
determining, using the received second data, the second segment including a second subset of the set of clients forming part of the peer-tournament system;
receiving (<NUM>) a request for initiation of peer-tournament operation from the first peer-tournament interface integrated into the third-party gaming application executing on a first client;
determining (<NUM>) that the first segment includes the first client and that the second segment includes the first client;
determining that the first segment includes an associated priority that is greater than an associated priority of the second segment; and
transmitting (<NUM>), in response to receiving the request and the determining that the first segment includes the associated priority that is greater than the associated priority of the second segment, the first configuration parameters to the first client, which cause the first client to modify operation of the first peer-tournament interface in response to receiving the transmitted first configuration parameters.