Machine learning trust scoring based on sensor data

Abstract

The present invention provides a trained machine learning model that is used to determine scores for user accounts registered with a video game service and use these scores to match players together in a multiplayer video game setting. For example, sensor data received from client machines can be input into the trained machine learning model, and the model generates scores as output that are related to the probability that the game control data received from those client machines was generated by a handheld device, rather than having been synthesized and / or modified using software. In this way, a subset of logged-in user accounts executing a video game can be assigned to different matches (e.g., by isolating non-human players from human players) based at least in part on the scores determined for those logged-in user accounts, and the video game can be executed in the assigned matches for each logged-in user account.

Description

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This PCT application claims priority to pending U.S. patent application Ser. No. 16 / 663,041, filed on October 24, 2019, entitled “MACHINE-LEARNED TRUST SCORING BASED ON SENSOR DATA,” which in turn claims priority, as a continuation-in-part application under 35 U.S.C. §120, to pending U.S. patent application Ser. No. 16 / 125,224, filed on September 7, 2018, entitled “MACHINE-LEARNED TRUST SCORING FOR PLAYER MATCHMAKING.” Each of Application Serial Nos. 16 / 663,041 and 16 / 125,224 is hereby incorporated by reference herein in its entirety. Background Art

[0003] The constant or nearly constant availability of wide area network communications, coupled with the increase in client machine functionality, has led to the growing popularity of online multiplayer video games. In these multiplayer video games, video game services can use a matching system to match players together in groups so that the grouped players can play video games together in a multiplayer mode. A popular video game type that players often play in a multiplayer mode is the first-person shooter type. In this exemplary type, two or more teams of players can compete in multiple rounds, with the goal of winning enough rounds to win a game. Players on the same team can work together to achieve a goal when competing with players on the opposing team.

[0004] Although the overwhelming majority of video game players do not participate in cheating, there are usually a few players who cheat in order to obtain more advantages than other players. Usually, the cheating player adopts the third-party software that provides them with some information advantages or mechanical advantages more than other players. For example, the third-party software can be configured to extract the position data about other players' positions, and these positions can be presented to the cheating player. This information advantage allows the cheating player to ambush other players, or otherwise utilizes the position information disclosed by the third-party software. More obvious cheating methods are to use the third-party software that can detect the position of another player and automatically operate the action of the cheater's avatar (for example, by programmatically making the mouse cursor move to the target player and firing a weapon in an automatic manner). In other words, some players cheat by allowing the third-party software to play video games for them, and this third-party software uses the computerized algorithm that strengthens the cheating player's performance from a mechanical perspective.

[0005] Typically, bad player behavior (such as cheating) can ruin the gaming experience for players who want to play the game legally. Therefore, if players who intend to engage in bad behavior are matched with other players who exhibit good behavior, their multiplayer video game experience will be ruined for the well-behaved players. Currently used systems that attempt to identify players who may engage in bad behavior in the future are somewhat inaccurate in terms of prediction. These systems are also static to a large extent in the sense that they are based on statically defined rules and inputs, which means that they must be manually adjusted to change the output of the system. The disclosure made herein is proposed with respect to these and other considerations. BRIEF DESCRIPTION OF THE DRAWINGS

[0006] The specific embodiments are described with reference to the accompanying drawings. In the figures, the leftmost digit of a reference number identifies the figure in which the reference number first appears. The use of the same reference number in different figures indicates similar or identical components or features.

[0007] Figure 1 is a schematic diagram illustrating an example environment including a remote computing system configured to train and use a machine learning model to determine trust scores associated with likely behaviors of players and to match players together based on the machine learning-based trust scores.

[0008] Figure 2 Shown Shown Figure 1 A block diagram of exemplary components of a remote computing system and a schematic diagram illustrating how machine-learned trust scores may be used for player matching.

[0009] Figure 3 is a flow chart of an exemplary process for training a machine learning model to predict the probability of a player performing or not performing a particular behavior.

[0010] Figure 4 is a flow chart of an exemplary process for utilizing a trained machine learning model to determine trust scores for user accounts, these trust scores being related to the probability of a player performing or not performing a particular behavior.

[0011] Figure 5 is a flow chart of an exemplary process for assigning user accounts to different matches for a multiplayer video game based on machine-learned trust scores that are correlated with likely player behavior.

[0012] Figure 6 is a schematic diagram illustrating an exemplary environment, including a block diagram illustrating exemplary components of a handheld device, and Figure 6 Shown is how sensor data received by a remote computing system can be used for machine learning trust scoring.

[0013] Figure 7 is a flow chart of an exemplary process for using data (including sensor data) to train a machine learning model to predict the probability that game control data received from a client machine has been generated by a handheld device.

[0014] Figure 8 is a flow chart of an exemplary process for utilizing a trained machine learning model to determine trust scores for user accounts that are related to the probability that game control data has been generated by a handheld device.

[0015] Figure 9 is a flow chart of an exemplary process for assigning user accounts to different matches for a multiplayer video game based on machine-learned confidence scores that are related to the probability that game control data has been generated by a handheld device. DETAILED DESCRIPTION

[0016] Among other things, this document describes techniques, devices, and systems for using machine learning methods to generate trust scores and subsequently using the machine-learned trust scores to match players together in a multiplayer video game setting. The disclosed technology can be implemented, at least in part, by a remote computing system that distributes video games (and their content) to client machines of a user community as part of a video game service. These client machines can individually install a client application that is configured to execute video games received (e.g., downloaded, streamed, etc.) from the remote computing system. The video game platform enables registered users of the community to play video games as "players." For example, a user can load the client application, log in with a registered user account, select a desired video game, and execute the video game on his / her client machine via the client application.

[0017] Each time the aforementioned user accesses and uses the video game platform, data may be collected by the remote computing system, and the data may be maintained by the remote computing system associated with the registered user account. Over time, it may be realized that a large collection of historical data associated with the registered user account is available to the remote computing system. The remote computing system can then use a portion of the historical data as training data to train one or more machine learning models. For example, a portion of the historical data associated with a sample set of user accounts may be represented by a set of features and labeled to indicate players who have behaved in a particular way when playing video games in the past. The machine learning model trained on this data can predict player behavior by outputting a machine learning score (e.g., a trust score) for the user account registered with the video game service. These machine learning scores can be used for player matching, so that players who are likely to behave according to a particular behavior or not according to a particular behavior can be grouped together in a multiplayer video game setting.

[0018] In an exemplary process, a computing system may determine scores (e.g., trust scores) for multiple user accounts registered with a video game service. The individual scores may be determined by accessing data associated with the individual user accounts, providing the data as input to a trained machine learning model, and generating a score associated with the individual user accounts as output from the trained machine learning model. The scores are related to the probability that a player associated with the individual user accounts will behave or not behave in a particular manner when playing one or more video games in a multiplayer mode. The computing system may then receive information from multiple client machines indicating logged-in user accounts logged into a client application executing a video game, and the computing system may define matches into which multiple players will be grouped for playing the video game in a multiplayer mode. The multiple matches may include at least a first match and a second match. The computing system may assign a first subset of the logged-in user accounts to the first match and a second subset of the logged-in user accounts to the second match based at least in part on the scores determined for the logged-in user accounts. A first subset of client machines associated with a first subset of logged-in user accounts may be enabled to execute the video game in a first match, while a second subset of client machines associated with a second subset of logged-in user accounts may be enabled to execute the video game in a second match.

[0019] Because human players who want to play video games legally often use handheld devices (e.g., handheld game controllers) to play video games, and because software configured to synthesize and / or modify game control data for cheating purposes does not use handheld devices to generate synthesized and / or modified game control data, machine learning scores can be used to utilize sensor data associated with one or more sensors of the handheld device to distinguish legitimate human players from software programmed to cheat, so that players who use software to cheat can be isolated from legitimate human players. Therefore, this article describes techniques, devices, and systems for receiving game control data and sensor data from one or more client machines interacting with a video game platform and providing at least the sensor data as input to a trained machine learning model to generate a trust score associated with a user account. In this case, the trust score can be related to the probability that the game control data received from a given client machine is generated by a handheld device associated with the given client machine. Therefore, these trust scores can be used for player matching to mitigate the situation where non-human players (e.g., software designed to cheat) are matched with human players who want to play video games legally with one or more other human players.

[0020] To illustrate, whenever a user plays a video game via a video game platform, they can use a handheld device (such as a handheld game controller) to control aspects of the video game. A given handheld device may include one or more sensors, such as, but not limited to, a gyroscope, an accelerometer, and / or a touch sensor, among other possible sensors. A touch sensor (e.g., a capacitive pad) may, for example, be located beneath or on the surface of the device, and / or within or on a finger-operated control. The touch sensor may be configured to detect the proximity of a finger to the surface or finger-operated control, and in response, the touch sensor may generate sensor data indicating the proximity of the finger to the touch sensor. As another example, a gyroscope and / or accelerometer mounted in the housing of the handheld device may detect movement of the handheld device in different directions (e.g., movement such as by translation, rotation, and / or tilt), and in response, the gyroscope and / or accelerometer may generate sensor data indicating characteristics of the movement. Typically, this sensor data may be used for various purposes, such as to control aspects of the video game (e.g., to control a player-controlled character, to rotate a virtual camera indicating what is visible on a display, etc.). When sensor data is used as game control data in this manner, in some cases, the sensor data may be altered (e.g., filtered / attenuated, amplified, etc.) before being used to control aspects of a video game. However, the techniques and systems described herein relate to a handheld device that is configured to send raw, unfiltered sensor data generated by one or more sensors of the handheld device to a remote computing system (e.g., by sending the sensor data via an associated client machine). The raw sensor data may be sent along with the game control data (e.g., data generated by button presses, joystick deflections, etc., as well as altered sensor data), which is processed for use in controlling aspects of the video game.

[0021] Over time, as users use handheld devices with one or more sensors to interact with a video game platform, as described above and elsewhere herein, a large collection of historical sensor data and game control data can be associated with registered user accounts and used to train a machine learning model. For example, a remote computing system can use a portion of the historical sensor data as training data to train one or more machine learning models. For example, a portion of the historical sensor data associated with a sample set of user accounts can be represented by a set of features, and when a human player holds and operates a handheld device to generate game control data, each user account in the sample set can be marked to indicate whether the historical game control data associated with the user account was generated by a real handheld device. The machine learning model trained with this sensor data is able to determine whether the game control data associated with a particular user account was generated by a physical handheld device, rather than having been synthesized and / or modified by software. In this way, the machine learning model can detect cheating based on the sensor data provided as input to the machine learning model. For example, when a human operates a handheld device, such as a handheld game controller, there may be subtle movements of the handheld device that are unintentional, but these subtle movements may be manifested in sensor data generated by one or more physical sensors of the handheld device (e.g., a touch sensor, a gyroscope, and / or an accelerometer, etc.). The machine learning model may be trained using at least this sensor data as training data to distinguish between human players and non-human players. For example, by identifying subtle differences in new sensor data received from a client machine, the machine learning model may output a confidence score indicating that the corresponding game control data has been generated by the physical sensors of a real handheld device, such as a device mechanically operated (e.g., by a human user). Conversely, due to a failure to receive sensor data from another client machine, or a failure to identify subtle differences in sensor data received from another client machine that would be expected to be present in the sensor data, the machine learning model may output a confidence score indicating that the corresponding game control data (such as game control data synthesized and / or modified by a so-called "aimbot") has been synthesized and / or modified using software that programmatically generates game control data to aim and fire a player-controlled character's weapon in an automated manner and without human intervention. Thus, using machine learning scores for player matching can help avoid matching human players (who wish to play a video game legally) with non-human players (such as software designed to cheat in a video game's multiplayer mode).

[0022] In an exemplary process, a computing system may receive game control data and sensor data from a client machine and may determine a score (e.g., a trust score) for a user account associated with the received data and registered with a video game service. For example, the computing system may provide the received sensor data as input to a trained machine learning model and generate a score associated with the user account as an output of the trained machine learning model. The score is associated with a probability that the received game control data was generated by a handheld device associated with the client machine. Based on the score, the computing system may assign the user account to an assigned match from a plurality of matches, the plurality of matches including at least one of a first match designated for a human player or a second match designated for a non-human player. Accordingly, a video game may be executed for the user account in the assigned match.

[0023] The techniques and systems described herein can provide an improved gaming experience for users who wish to play video games in multiplayer mode in an expected manner. This is because the techniques and systems described herein can match players (including non-human players, such as "automatic aimbots") who may behave badly (e.g., cheat) together and isolate these players from other trustworthy players who may be playing the video game legally. For example, a trained machine learning model can learn to predict which players are likely to cheat and which players are less likely to cheat by attributing a corresponding trust score to each player's user account that indicates their propensity to cheat (or not cheat). In this way, players with low (e.g., below a threshold) trust scores can be matched together and isolated from other players whose user accounts are considered to have high (e.g., above a threshold) trust scores, allowing trustworthy players to participate in matches without any players who are likely to cheat. Although the use of a threshold score is described as an exemplary way to provide match assignments, other techniques are also contemplated, such as clustering algorithms, or other statistical methods (e.g., based on similarity metrics, such as distance metrics, variance metrics, etc.) that use trust scores to preferentially match user accounts (players) with "similar" trust scores.

[0024] The techniques and systems described herein also improve upon existing matching technologies that use static rules to determine a user's trust level. However, machine learning models can learn to identify complex relationships in player behavior to better predict player behavior, which is not possible with static rule-based approaches. Therefore, compared to existing trust systems, the techniques and systems described herein allow for the generation of trust scores that more accurately predict player behavior, resulting in lower false positive rates and fewer instances of players being defined by inaccurate trust scores. The techniques and systems described herein are also more adaptable to changing player behavior dynamics than existing systems because machine learning models can be retrained using new data so that as player behavior changes, the machine learning models adapt their understanding of player behavior over time. The techniques and systems described herein may also allow one or more devices to save resources regarding processing resources, memory resources, network resources, and the like in the various ways described herein.

[0025] It should be understood that while many of the examples described herein refer to "cheating" as a target behavior by which players can be scored and grouped for matchmaking purposes, the techniques and systems described herein can be configured to use machine learning-based scoring methods to identify any type of behavior (good or bad) and to predict the likelihood that a player will engage in that behavior for the purposes of player matching. Thus, these techniques and systems can be expanded beyond the concept of a "trust" score in the context of bad behavior (e.g., cheating) and can more broadly attribute scores to user accounts that indicate compatibility or affinity between players.

[0026] Figure 1 1 is a diagram illustrating an exemplary environment 100 including a remote computing system configured to train and use a machine learning model to determine trust scores associated with players' likely behaviors and to match players together based on the machine learning-based trust scores. A community of users 102 can be associated with one or more client machines 104. Figure 1 The client machines 104(1) through 104(N) shown represent computing devices that can be used by the user 102 to execute programs, such as video games, thereon. Figure 1The user 102 shown is sometimes referred to as a "player" 102, and these names are used interchangeably herein to refer to a human operator of a client machine 104. The client machine 104 may be implemented as any suitable type of computing device configured to execute a video game and present graphics on an associated display, including, but not limited to: a personal computer (PC), a desktop computer, a laptop computer, a mobile phone (e.g., a smartphone), a tablet computer, a portable digital assistant (PDA), a wearable computer (e.g., a virtual reality (VR) headset, an augmented reality (AR) headset, smart glasses, etc.), an in-vehicle (e.g., in-car) computer, a television (smart TV), a set-top box (STB), a game console, and / or any similar computing device. Furthermore, the client machines 104 may differ in terms of their respective platforms (e.g., hardware and software). For example, Figure 1 The multiple client machines 104 shown may represent different types of client machines 104 having different capabilities in terms of processing power (e.g., central processing unit (CPU) model, graphics processing unit (GPU) model, etc.), graphics driver versions, etc.

[0027] Client machine 104 may communicate with remote computing system 106 (sometimes referred to herein simply as "computing system 106" or "remote system 106") via computer network 108. Computer network 108 may represent and / or include, but is not limited to, the Internet, other types of data and / or voice networks, wired infrastructure (e.g., coaxial cable, fiber optic cable, etc.), wireless infrastructure (e.g., radio frequency (RF), cellular, satellite, etc.), and / or other connectivity technologies. In some cases, computing system 106 may be part of a network-accessible computing platform maintained and accessible via computer network 108. Network-accessible computing platforms such as these may be referred to by terms such as "on-demand computing," "software as a service (SaaS)," "platform computing," "network-accessible platform," "cloud service," "data center," and the like.

[0028] In some embodiments, the computing system 106 acts as or has access to a video game platform that implements a video game service for distributing (e.g., downloading, streaming, etc.) video games 110 (and their content) to client machines 104. In an example, the client machines 104 may each have a client application installed thereon. The installed client application may be a video game client (e.g., game software for playing the video game 110). The client machine 104 with the installed client application may be configured to download, stream, or otherwise receive the program (e.g., video game 110 and its content) from the computing system 106 via the computer network 108. Any type of content distribution model may be used for this purpose, such as a direct purchase model in which a program (e.g., video game 110) may be purchased separately for download and execution on the client machine 104, a content distribution model in which the program is rented or leased for a period of time, streamed, or otherwise made available to the client machine 104. Thus, a single client machine 104 may include one or more installed video games 110 that can be executed by loading the client application.

[0029] like Figure 1 As shown in FIG. 112 , a client device 104 can be used to register with and subsequently log into a video game service. For this purpose, a user 102 can create a user account and specify / set credentials (e.g., a password, PIN, biometric ID, etc.) that are tied to the registered user account. As multiple users 102 interact with the video game platform (e.g., by accessing their user / player profiles using registered user accounts, playing video games 110 on their respective client machines 104, etc.), the client machines 104 transmit data 114 to the remote computing system 106. For a given client machine 104, the data 114 transmitted to the remote computing system 106 may include, but is not limited to, user input data, video game data (e.g., game performance statistics uploaded to the remote system), social network messages and related activity, an identifier (ID) for the video game 110 being played on the client machine 104, and / or the like. The data 114 may be streamed in real time (or substantially real time), transmitted to the remote system 106 at defined intervals, and / or uploaded in response to an event (e.g., exiting a video game).

[0030] Figure 1The computing system 106 is shown as storing data 114 that it collects from the client machines 104 in a data store 116, which may represent a data repository maintained by and accessible to the remote computing system 106. The data 114 may be organized in any suitable manner within the data store 116 to associate user accounts with relevant portions of the data 114 that are relevant to those user accounts. Over time, given a large community of users 102 who frequently interact with the video game platform for extended periods of time, sometimes during a given session, a large amount of data 114 may be collected and maintained in the data store 116.

[0031] exist Figure 1 At step 1 in , computing system 106 may train a machine learning model using historical data 114 sampled from data store 116. For example, computing system 106 may access a portion of historical data 114 associated with a sample set of user accounts registered with a video game service, and use the sampled data 114 to train a machine learning model. In some embodiments, the portion of data 114 used as training data is represented by a set of features, and each user account in the sample set is labeled with a label indicating whether the user account is associated with a player who has behaved in a particular manner while playing at least one video game in the past. For example, if a player with a particular user account was banned from a video game service for cheating in the past, the "ban" may be used as one of a plurality of classification labels for the particular user account. In this manner, a supervised learning approach may be employed to train a machine learning model to predict players who are likely to cheat in the future.

[0032] At step 2, the computing system 106 may score multiple registered user accounts using a trained machine learning model. For example, the computing system 106 may access data 114 associated with multiple registered user accounts from a data store 116, provide the data 114 as input to the trained machine learning model, and generate scores associated with the multiple user accounts as outputs of the trained machine learning model. These scores (sometimes referred to herein as "trust scores" or "trust factors") are related to the probability that players associated with the multiple user accounts will behave according to or not behave according to a specific behavior when playing one or more video games in multiplayer mode. In the case of "bad" behavior (such as cheating), the trust score may be related to the probability that the player did not cheat. In this case, a high trust score indicates a trustworthy user account, while a low trust score indicates an untrustworthy user account, which can be used as an indicator of a player who may exhibit bad behavior (such as cheating). In some embodiments, the score is a variable normalized within the range of [0, 1]. The trust score may have a monotonic relationship with the probability that the player will behave in a particular manner (or not behave in a particular manner, as the case may be) while playing the video game 110. The relationship between the score and the actual probability associated with a particular behavior, while monotonic, may or may not be linear. Of course, the scoring may be implemented in any suitable manner to predict whether a player associated with a user account will behave in a particular manner. Figure 1 A plurality of user accounts 120 are shown that have been scored according to the techniques described herein. For example, for any suitable number of registered user accounts 120, a first score 118(1) (score=X) is attributed to the first user account 120(1), a second score 118(2) (score=Y) is attributed to the second user account 120(2), and so on.

[0033] Where machine learning scores 118 are determined for a plurality of registered user accounts 120, computing system 106 may be configured to match players together in a multiplayer video game setting based at least in part on machine learning scores 118. For example, Figure 1 The diagram shows that the computing system 106 can receive information 122 from multiple client machines 104 that have begun executing a video game 110. This information 122 can indicate to the computing system 106 that a set of logged-in user accounts 120 are currently executing the video game 110 on each client machine 104 via an installed client application. In other words, when players 102 log in with their user accounts 120 and begin executing a particular video game 110, requesting to play in multiplayer mode, their respective client machines 104 can provide the computing system 106 with information 122 indicating as much as possible.

[0034] At step 3, in response to the information 122 received from the client machine 104, the computing system 106 may match the players 102 together by defining a plurality of matches into which the players 102 will be grouped for playing the video game 110 in multiplayer mode and by providing match assignments 124 to the client machine 104 such that a subset of the logged-in user accounts 120 are assigned to different ones of the plurality of matches based at least in part on the machine-learned scores 118 determined for the logged-in user accounts 120. In this manner, if the trained machine-learning model assigns low (e.g., below a threshold) scores 118 to a first subset of the logged-in user accounts 120 and high (e.g., above a threshold) scores 118 to a second subset of the logged-in user accounts 120, the first subset of the logged-in user accounts 120 may be assigned to a first one of the plurality of matches, and the second subset of the logged-in user accounts 120 may be assigned to a different second one of the plurality of matches. In this manner, a subset of players 102 having similar scores 118 may be grouped together and may be kept isolated from other players having scores 118 that differ from the scores 118 of the subset of players 102 .

[0035] At step 4, the client application on each client machine 104 executing the video game 110 may execute the video game 110 in the assigned match for the logged-in user account 120 in question. For example, a first subset of client machines 104 may be associated with a first subset of logged-in user accounts 120 assigned to a first match, and this first subset of client machines 104 may execute the video game 110 in the first match, while a second subset of client machines 104 (the second subset associated with a second subset of logged-in user accounts 120 assigned to a second match) may execute the video game 110 in a second match. By grouping players into matchups based at least in part on the machine learning scores 118, the gaming experience for at least some of the groups of players 102 may be improved because the system may group players who are expected to perform poorly (e.g., by cheating) into the same match, and by doing so, may isolate players with poor behavior from other players who wish to legitimately play the video game 110.

[0036] Figure 2 Shown Shown Figure 12 is a block diagram of exemplary components of a remote computing system 106, and a schematic diagram of how machine-learned trust scores may be used for player matching. In the illustrated implementation, the computing system 106 includes, among other components, one or more processors 202 (e.g., central processing units (CPUs)), memory 204 (or non-transitory computer-readable media 204), and a communication interface 206. The memory 204 (or non-transitory computer-readable media 204) may include volatile and non-volatile memory, removable and non-removable media implemented using any method or technology for storing information (such as computer-readable instructions, data structures, program modules, or other data). Such memory includes, but is not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disks (DVDs) or other optical storage devices, magnetic cassettes, magnetic tape, magnetic disk storage devices or other magnetic storage devices, RAID storage systems, or any other medium that can be used to store the desired information and that can be accessed by the computing device. The computer-readable medium 204 may be implemented as a computer-readable storage medium ("CRSM"), which may be any available physical medium that the processor 202 can access to execute instructions stored on the memory 204. In one basic implementation, the CRSM may include random access memory ("RAM") and flash memory. In other implementations, the CRSM may include, but is not limited to, read-only memory ("ROM"), electrically erasable programmable read-only memory ("EEPROM"), or any other tangible medium that can be used to store the desired information and that can be accessed by the processor 202. The video game service 208 may represent instructions stored in the memory 204 that, when executed by the processor 202, cause the computing system 106 to perform the techniques and operations described herein.

[0037] For example, the video game service 208 may include a training component 210, a scoring component 212, and a matching component 214, among other possible components. The training component 210 may be configured to train a machine learning model using a portion of the data 114 in the data store 116 as training data, a portion of the data associated with a sample set of user accounts 120, to obtain a trained machine learning model 216. The trained machine learning model 216 may be used by the scoring component 212 to determine scores 118 (e.g., trust scores 118) for a plurality of registered user accounts 120. The matching component 214 provides match assignments 124 based at least in part on the machine learning scores 118, such that players are grouped into different matches in a plurality of matches 218 (e.g., a first match 218(1), a second match 218(2), etc.) for playing the video game 110 in a multiplayer mode. Figure 2102) are assigned to a first match 218(1), and a second group of players 102 (e.g., another ten players 102) associated with a second subset of logged-in user accounts 120 are assigned to a second match 218(2). Of course, any number of matches 218 may be defined, which may depend on the number of logged-in user accounts 120 requesting to play the video game 110 in multiplayer mode, the capacity limits of the network traffic that the computing system 106 can handle, and / or other factors. In some embodiments, other factors (e.g., skill level, geographic region, etc.) are considered during the matchmaking process that may result in players being further segmented and / or subdivided into a fewer or greater number of matches 218.

[0038] As mentioned, the score 118 determined by the scoring component 212 (e.g., output by the trained machine learning model 216) is a machine learning score 118. Machine learning generally involves processing a set of samples (referred to as "training data") in order to train a machine learning model. Once trained, the machine learning model 216 is a learning mechanism that can receive new data as input and estimate or predict an outcome as output. For example, the trained machine learning model 216 may include a classifier that is responsible for classifying an unknown input (e.g., an unknown image) into one of a plurality of classification labels (e.g., labeling an image as a cat or a dog). In some cases, the trained machine learning model 216 is configured to implement a multi-label classification task (e.g., labeling an image as "cat," "dog," "duck," "penguin," etc.). Additionally or alternatively, the trained machine learning model 216 can be trained to infer a probability or a set of probabilities for a classification task based on unknown data received as input. In the context of the present disclosure, the unknown input may be data 114 associated with a single user account 120 registered with a video game service, and the trained machine learning model 216 is responsible for outputting a score 118 (e.g., a trust score 118) that indicates, or is otherwise related to, the probability that the single user account 120 belongs to one of a plurality of categories. For example, the score 118 may be related to the probability that the player 102 associated with the single user account 120 will behave in a particular manner (or not behave in a particular manner, as the case may be) when playing the video game 110 in multiplayer mode. In some embodiments, the score 118 is a variable normalized to a range of [0, 1]. The trust score 118 may have a monotonic relationship with the probability that the player 102 will behave in a particular manner (or not behave in a particular manner, as the case may be) when playing the video game 110. The relationship between the score 118 and the actual probability associated with a particular behavior, while monotonic, may or may not be linear. In some embodiments, the trained machine learning model 216 may output a set of probabilities (e.g., two probabilities) or scores associated therewith, wherein one probability (or score) is associated with the probability that the player 102 will perform a particular behavior, and the other probability (or score) is associated with the probability that the player 102 will not perform a particular behavior. The score 118 output by the trained machine learning model 216 may be associated with either of these probabilities to guide the matchmaking process. In an illustrative example, the particular behavior may be cheating. In this example, the score 118 output by the trained machine learning model 216 is associated with the likelihood that the player 102 associated with a single user account 120 will or will not continue to cheat during the process of playing the video game 110 in multiplayer mode.Thus, in some embodiments, the score 118 may indicate a level of trustworthiness of the player 102 associated with a single user account 120 , and this is why the score 118 described herein is sometimes referred to as a “trust score” 118 .

[0039] The trained machine learning model 216 may represent a single model or a collection of base-level machine learning models, and may be implemented as any type of machine learning model 216. For example, suitable machine learning models 216 for use with the techniques and systems described herein include, but are not limited to, neural networks, tree-based models, support vector machines (SVMs), kernel methods, random forests, splines (e.g., multivariate adaptive regression splines), hidden Markov models (HMMs), Kalman filters (or enhanced Kalman filters), Bayesian networks (or Bayesian belief networks), expectation maximization, genetic algorithms, linear regression algorithms, nonlinear regression algorithms, classification models based on logistic regression, or collections thereof. An "ensemble" may include a collection of machine learning models 216 whose outputs (predictions) are combined, such as by using a weighted average or voting. The individual machine learning models in the collection may differ in their expertise, and the collection may operate as a committee of individual machine learning models that is, in aggregate, "smarter" than any individual machine learning model of the collection.

[0040] The training data used to train the machine learning model 216 may include various types of data 114. Typically, training data for machine learning may include two components: features and labels. However, in some embodiments, the training data used to train the machine learning model 216 may be unlabeled. Thus, the machine learning model 216 may be trained using any suitable learning technique (such as supervised learning, unsupervised learning, semi-supervised learning, reinforcement learning, etc.). The features included in the training data may be represented by a set of features, such as in the form of an n-dimensional feature vector of quantifiable information about attributes of the training data. The following is a list of exemplary features that may be included in the training data used to train the machine learning model 216 described herein. However, it should be understood that the following list of features is non-exhaustive and that the features used in training may include additional features not described herein, and in some cases, include some (but not all) of the features listed herein. Exemplary features included in the training data may include, but are not limited to: the amount of time a player spends playing a video game 110 generally, the amount of time a player spends playing a particular video game 110, the number of times a player logs in and plays a video game 110 in a day, the player's game history data (e.g., total score (per game, per round, etc.), headshot rate, kills, deaths, assists, player ranking, etc.), the number and / or frequency of reports of cheating by the player, the number and / or frequency of cheating convictions for the player, the number and / or frequency of cheating convictions for the player, a confidence value (score) output by a machine learning model that detects cheating during video game play, the number of multiple user accounts 120 associated with a single player (which may be inferred from a common address, phone number, payment instrument, etc. tied to the multiple user accounts 120), The number of times a user account 120 has been registered with the video game service, the number of previously banned user accounts 120 associated with the player, the number and / or frequency of monetary transactions by the player on the video game platform, the amount of each transaction, the number of digital items of monetary value associated with the player's user account 120, the number of times a user account 120 has changed hands (e.g., between different owners / players), the frequency with which a user account 120 has been transferred between players, the geographic location from which the player has logged into the video game service, the number of different payment instruments, phone numbers, mailing addresses, etc. associated with the user account 120, and / or how often these items have changed, and / or any other suitable features that may be relevant to calculating a trust score 118 that indicates a player's propensity to engage in particular behaviors. As part of the training process, the training component 210 may set weights for machine learning. These weights may be applied to a set of features included in the training data, such as derived from historical data 114 in the data store 116.In some embodiments, the weights set during the training process may be applied to parameters internal to the machine learning model (e.g., the weights of neurons in a hidden layer of a neural network). These internal parameters of the machine learning model may or may not be mapped one-to-one with each input feature in the set of features. These weights may indicate the impact of any given feature or parameter on the score 118 output by the trained machine learning model 216.

[0041] With particular regard to cheating (which is an illustrative example of the type of behavior that can be used as a basis for matching players), there may be behaviors associated with the user accounts 120 of players who are planning to cheat in the video game 110 that are different from the behaviors associated with the user accounts 120 of non-cheating players. Therefore, the machine learning model 216 can learn to identify those behavioral patterns from the training data, so that players who are likely to cheat can be identified with high confidence and scored appropriately. It should be understood that outliers may exist in the ecosystem, and the system can be configured to protect these outliers based on some known information about outliers. For example, professional players may exhibit different behaviors than ordinary players, and these professional players may be at risk of being scored incorrectly. As another example, employees of the service provider of the video game service may log in with user accounts for research purposes or quality control purposes and may behave in a manner that is different from the behavior of ordinary players. These types of players / users 102 can be considered outliers and, outside of the context of machine learning, actively assigned scores 118 that give those players / users 102 a high degree of confidence. In this manner, well-known professional players, employees of service providers, and the like may be assigned authoritative scores 118 that are unmodifiable by the scoring component 212 to avoid matching those players / users 102 with players of poor behavior.

[0042] Training data can also be marked for supervised learning methods. Similarly, using cheating as an exemplary type of behavior that can be used to match players together, the label in this example can indicate whether user account 120 is banned from playing video games 110 via video game services. The data 114 in data storage 116 can include some data 114 associated with players banned for cheating, and some data 114 associated with players not yet banned for cheating. An example of this ban type is the Valve Anti-Cheat (VAC) ban used by Valve Corporation of Bellevue, Washington. For example, the authorized user of computing system 106 and / or computing system 106 may be able to detect when unauthorized third-party software has been used for cheating. In these cases, after a strict verification process to ensure that it is correct, the cheating user account 120 can be marked as banned in data storage 116 to ban the cheating user account. Therefore, the user account 120 may be used as both positive and negative training examples depending on its status as to whether it has been banned or not banned.

[0043] It should be understood that past player behavior (such as past cheating) can be indicated in other ways. For example, a mechanism for detecting and reporting suspected cheating players can be provided for users 102 or even separate machine learning models. These reported players can be placed in front of a jury composed of their peers, who can review the reported player's game replays and make a ruling (e.g., cheating or not cheating). If enough other players determine that the reported player's behavior is equivalent to cheating, a high confidence threshold can be reached, and the reported player is determined to be cheating and receives a ban on their user account 120, which can also constitute a label for associated training data.

[0044] Figure 2Examples of other behaviors besides cheating are shown, which can be used as a basis for player matching. For example, the trained machine learning model 216 can be configured to output a trust score 118, which is related to the probability that a player will behave according to a game abandonment behavior (e.g., by abandoning (or quitting) a video game midway through a match) or will not behave according to a game abandonment behavior. Just like cheating, game abandonment is a behavior that tends to ruin the gaming experience for non-abandoning players. As another example, the trained machine learning model 216 can be configured to output a trust score 118, which is related to the probability that a player will behave according to a griefing behavior or will not behave according to a griefing behavior. A "griefer" is a player who intentionally angers and harasses other players in a video game 110 in a multiplayer video game, which can ruin the gaming experience for non-griefing players. As another example, the trained machine learning model 216 can be configured to output a trust score 118, which is related to the probability that a player will behave according to a vulgar language behavior or will not behave according to a vulgar behavior. Typically, multiplayer video games allow players to participate in chat sessions or other social network communications that are visible to other players in the video game 110, and when players use vulgar language (e.g., profanity, offensive language, etc.), this can disrupt the gaming experience for players who do not use vulgar language. As another example, the trained machine learning model 216 can be configured to output a trust score 118 that is related to the probability that a player will behave in a "highly skilled" manner or not behave in a "highly skilled" manner. In this way, the score can be used to identify highly skilled players or novice players from a group of players. This helps prevent situations where experienced gamers create new user accounts pretending to be players at the novice skill level so that they can play with amateur players. Thus, the players matched together in a first match 218 (1) may be those players who are likely to behave in a particular "bad" manner (as determined based on the machine learning score 118), while the players matched together in other matches (such as a second match 218 (2)) may be those players who are less likely to behave in a particular "bad" manner.

[0045] This may be the case when the distribution of trust scores 118 output for multiple players (user accounts 120) is primarily bimodal. For example, one peak in the statistical distribution of scores 118 may be associated with players who are likely to behave in a particular manner, while the other peak in the statistical distribution of scores 118 may be associated with players who are less likely to behave in that manner. In other words, the number of players with bad behavior and the number of players with good behavior may be separated by a significant margin in the statistical distribution. In this sense, if a new user account registers with a video game service and is assigned a trust score that lies between the two peaks of the statistical distribution, the user account will be quickly driven in one direction or another when interacting with the video game platform. Due to this tendency, the matchmaking parameters used by the matching component 214 may be adjusted to treat players with trust scores 118 that are not within the lower peak of the statistical distribution similarly, and the matching component 214 may be primarily concerned with separating / isolating bad behavior players with trust scores 118 that are within the lower peak of the statistical distribution. While the use of a threshold score is described herein as one exemplary way to provide match assignments, other techniques are also contemplated, such as clustering algorithms, or other statistical methods that use trust scores to preferentially match together user accounts (players) with “similar” trust scores (e.g., based on similarity metrics such as distance metrics, variance metrics, etc.).

[0046] Furthermore, the matching component 214 may not utilize player matching for new user accounts 120 that have recently registered with the video game service. Instead, a rule may be implemented that requires a player to accumulate a certain level of experience / performance in individual game mode before being scored and matched with other players in the multiplayer mode of the video game 110. It should be understood that a player's path from first launching the video game 110 to gaining access to player matching can be very different for different players. Some players may take a long time to be matched into multiplayer mode, while other users may complete the qualification process easily and quickly. With this qualification process in place, a user account that is to be scored for matching purposes will play the video game and provide sufficient data 114 to give the user account 120 an accurate score 118.

[0047] Also, as mentioned, while many of the examples described herein use "bad" behaviors (such as cheating, game abandonment, griefing, vulgar language, etc.) as target behaviors by which players can be scored and grouped for matchmaking purposes, the techniques and systems described herein can be configured to use machine learning scoring methods to identify any type of behavior and predict the likelihood that a player will engage in that behavior for the purposes of player matching.

[0048] The processes described herein are illustrated as a collection of blocks in a logical flow diagram, which represent a series of operations that can be implemented in hardware, software, or a combination thereof. In the context of software, these blocks represent computer-executable instructions that, when executed by one or more processors, perform the enumerated operations. Typically, computer-executable instructions include routines, programs, objects, components, data structures, etc. that perform specific functions or implement specific abstract data types. The order in which the operations are described is not intended to be construed as a limitation, and any number of the described blocks may be combined in any order and / or in parallel to implement the processes.

[0049] Figure 3 3 is a flow chart of an exemplary process 300 for training a machine learning model to predict the probability of a player performing or not performing a particular behavior. For discussion purposes, process 300 is described with reference to the previous figures.

[0050] At 302, computing system 106 may provide user 102 with access to a video game service. For example, computing system 106 may allow the user to access and browse a catalog of video games 110, modify a user profile, conduct transactions, participate in social media activities, and other similar and / or related actions. Computing system 106 may distribute video games 110 (and their content) to client machines 104 as part of the video game service. In the illustrative example, a user 102 with access to the video game service may load an installed client application, log in with a registered user account, select a desired video game 110, and execute the video game 110 on his / her client machine 104 via the client application.

[0051] At 304, the computing system 106 may collect and store data 114 associated with the user account 120 registered with the video game service. Each time a user 102 accesses the video game service with their registered user account 120 and uses the video game platform (such as to play a video game 110 thereon), this data 114 may be collected at block 304. Over time, it may be recognized that a large collection of data 114 associated with the registered user accounts is available for use by the computing system 106.

[0052] At 306, the computing system 106 may access (historical) data 114, via the training component 210, that is associated with a sample set of user accounts 120 registered with the video game service. At least some of the (historical) data 114 may have been generated as a result of a player playing one or more video games 110 on a video game platform provided by the video game service. For example, the (historical) data 114 accessed at 306 may represent match history data for players who have played one or more video games 110 (e.g., in a multiplayer mode by participating in a match). In some embodiments, the (historical) data 114 may indicate whether the sample set of user accounts 120 has been transferred between players, or indicate other types of user activity with respect to the user accounts 120.

[0053] At 308, the computing system 106, via the training component 210, may tag each user account 120 of the sample set of user accounts 120 with a label indicating whether the user account is associated with a player who has behaved in a particular manner in the past while playing at least one video game 110. Examples of labels are described herein, such as whether a user account 120 has been banned for cheating in the past, which may be used as a label in the context of scoring players based on their propensity to cheat or not cheat, as the case may be. However, these labels may correspond to other types of behavior, such as a label indicating whether the user account is associated with a player who has abandoned a game in the past, has been sad during a game in the past, has used vulgar language during a game in the past, etc.

[0054] At 310, the computing system 106 may train the machine learning model using the (historical) data 114 as training data via the training component 210 to obtain a trained machine learning model 216. As shown in sub-block 312, the training of the machine learning model at block 310 may include setting weights for machine learning. These weights may be applied to a set of features derived from the historical data 114. Exemplary features are described herein, such as those described above with reference to Figure 2 those described. In some embodiments, the weights set at block 312 may be applied to parameters internal to the machine learning model (e.g., weights of neurons in a hidden layer of a neural network). These internal parameters of the machine learning model may or may not map one-to-one with each input feature in the set of features. As indicated by the arrow from block 310 to block 304, the machine learning model 216 may be retrained using updated (historical) data 114 to obtain a new trained machine learning model 216 adapted to recent player behavior. This allows the machine learning model 216 to adapt to changing player behavior over time.

[0055] Figure 41 is a flow chart of an exemplary process 400 for determining trust scores 118 for user accounts 120 using a trained machine learning model 216, these trust scores 118 being associated with (or indicating) the probability that a player will or will not behave in a particular manner. For discussion purposes, the process 400 is described with reference to the previous figures. In addition, as Figure 3 and Figure 4 As shown in the page external reference “A” in FIG, process 400 may continue from block 310 of process 300 .

[0056] At 402, computing system 106 can access data 114 associated with a plurality of user accounts 120 registered with a video gaming service via scoring component 212. This data 114 can include any information (e.g., quantifiable information) from the set of features that, as described herein, have been used to train machine learning model 216. This data 114 constitutes unknown input to be input to trained machine learning model 216.

[0057] At 404 , the computing system 106 may provide the data 114 accessed at block 402 as input to the trained machine learning model 216 via the scoring component 212 .

[0058] At 406, the computing system 106 may generate, via the scoring component 212, a trust score 118 associated with the plurality of user accounts 120 as an output of the trained machine learning model 216. On an individual basis, the score 118 is associated with a single user account 120 from the plurality of user accounts 120, and the score 118 is related to the probability that the player 102 associated with the single user account 120 will or will not engage in a particular behavior when playing one or more video games 110 in multiplayer mode. In this case, the particular behavior can be any suitable behavior represented in the data 114 such that the machine learning model can be trained to predict players with a propensity to engage in that behavior. Examples include, but are not limited to, cheating behavior, game abandonment behavior, griefing behavior, or foul language behavior. In some embodiments, the score 118 is a variable normalized within the range of [0, 1]. The trust score 118 may have a monotonic relationship with the probability that the player will engage in the particular behavior (or not, as the case may be) when playing the video game 110. The relationship between the score 118 and the actual probability associated with a particular behavior, while monotonic, may or may not be linear.

[0059] Thus, process 400 represents a machine learning scoring method in which a score 118 (e.g., a trust score 118) is determined for a user account 120 that indicates the probability that a player using the user account 120 will engage in a particular behavior in the future. Compared to existing methods that attempt to predict player behavior, using a machine learning model in this scoring process allows for the identification of complex relationships in player behavior to better predict player behavior. This can result in more accurate predictions of player behavior using a more adaptable and versatile system that can adjust to changing player behavior dynamics without human intervention.

[0060] Figure 5 1 is a flow chart of an exemplary process 500 for assigning user accounts 120 to different matches for a multiplayer video game based on machine-learned trust scores 118 that are correlated with likely player behavior. For discussion purposes, the process 500 is described with reference to the previous figures. Figure 4 and Figure 5 As shown in the page external reference “B” in FIG. , process 500 may continue from block 406 of process 400 .

[0061] At 502, the computing system 106 may receive information 122 from a plurality of client machines 104, the information 122 indicating logged-in user accounts 120 logged into a client application executing a video game 110 on each of the client machines 104. For example, a plurality of players 102 may have begun executing a particular video game 110 (e.g., a first-person shooter game) and desire to play the video game 110 in a multiplayer mode. The information 112 received 122 at block 502 may at least indicate the logged-in user accounts 120 of those players.

[0062] At 504, the computing system 106, via the matching component 214, may define matches into which the players 102 will be grouped for playing the video game 110 in multiplayer mode. Any number of matches may be defined, depending on various factors, including demand, capacity, and other factors involved in the matching process. In an example, the plurality of defined matches at block 504 may include at least a first match 218(1) and a second match 218(2).

[0063] At 506, the computing system 106 may assign, via the matching component 214, a first subset of the logged-in user accounts 120 to a first match 218(1) and a second subset of the logged-in user accounts 120 to a second match 218(2) based at least in part on the scores 118 determined for the logged-in user accounts 120. As mentioned, any number of matches may be defined such that further subdivisions and additional matches may be assigned to the user accounts at block 506.

[0064] As shown in sub-block 508, the assignment of user accounts 120 to different matches can be based on a threshold score. For example, the matching component 214 can determine that the scores 118 associated with a first subset of logged-in user accounts 120 are less than a threshold score, and can assign the first subset of logged-in user accounts 120 to a first match based on those scores being less than the threshold score. Similarly, the matching component 214 can determine that the scores 118 associated with a second subset of logged-in user accounts 120 are equal to or greater than the threshold score, and can assign the second subset of logged-in user accounts 120 to a second match based on those scores being equal to or greater than the threshold score. However, this is merely one exemplary way to provide match assignments 124, and other techniques are also contemplated. For example, in addition to or as an alternative to using a threshold score, a clustering algorithm or other statistical method can also be used. In an example, the trust score 118 can be used to preferentially match together user accounts (players) with "similar" trust scores. Given the natural tendency of the distribution of trust scores 118 across the plurality of user accounts 120 to be primarily bimodal, grouping trust scores 118 based on a similarity metric (e.g., a distance metric, a variance metric, etc.) may provide similar results as using a threshold score. However, in situations where the pool of matches is small (e.g., players in a small geographic area who want to play a less popular game mode), it may be useful to use a similarity metric to group user accounts together for matchmaking purposes, as this may provide a more granular approach that allows for gradual adjustment of the relative importance of trust scores relative to other matching factors (e.g., skill level). In some embodiments, multiple thresholds may be used to "bucketize" user accounts 120 into multiple different matches.

[0065] As shown in sub-block 510, other factors besides the trust score 118 may be considered in the match assignment at block 506. For example, the match assignment 124 determined at block 506 may be further based on the skill level of the player associated with the logged-in user account, the amount of time the logged-in user account has been waiting to be placed in one of the multiple matches, the geographic region associated with the logged-in user account, and / or other factors.

[0066] At 512, the computing system 106 may cause (e.g., by providing control instructions) a client application executing the video game 110 on each client machine 104 that sent the information 122 to initiate one of the defined matches (e.g., one of the first match 218(1) or the second match 218(2)) based at least in part on the logged-in user accounts 120 associated with the client machines 104. For example, where the first match 218(1) and the second match 218(2) are defined, the computing system 106 may cause a first subset of the plurality of client machines 104 associated with a first subset of the logged-in user accounts 120 to execute the video game 110 in the first match 218(1), and may cause a second subset of the plurality of client machines 104 associated with a second subset of the logged-in user accounts 120 to execute the video game 110 in the second match 218(2).

[0067] Because the machine-learned trust score 118 is used as a factor in the matchmaking process, an improved gaming experience can be provided to users who wish to play a video game in a multiplayer mode in an intended manner. This is because the techniques and systems described herein can be used to match players who may be behaving unethically (e.g., cheating) and isolate these players from other trustworthy players who may be legitimately playing the video game.

[0068] Figure 6 is a schematic diagram illustrating an exemplary environment 600, including a block diagram illustrating exemplary components of a handheld device 602, and Figure 6 1 illustrates how sensor data 604 received by a remote computing system 106 can be used for machine learning trust scoring. Figure 6 106 to interact with the video game platform as described herein. For example, the user 102 may pair the handheld device 602 with a client machine 104 on which a video game client (e.g., game software for playing the video game 110) is executing. Once the handheld device 602 is paired with the client machine 104 and is able to communicate with it (e.g., by sending / receiving data to / from the client machine 104), the handheld device 602 may be used to interact with the video game platform described herein, such as to register the handheld device 602 with a user account 120, access a video game 110 available from a remote computing system 106, and play the video game 110 using the handheld device 602.

[0069] The handheld device 602 may represent a handheld game controller, such as a game controller designed to be held by one or both hands of the user 102 and configured with one or more finger-operated controls that are operated by the fingers and / or thumbs of the hands of the user 102. In some embodiments, the handheld device 602 may also be configured to be operated by moving (e.g., translating, rotating, tilting, etc.) the game controller in three-dimensional (3D) space. It should be understood that the handheld device 602 may represent any other suitable type of handheld device, such as a mobile phone (e.g., a smartphone), a tablet computer, a portable digital assistant (PDA), a wearable computer (e.g., a smartwatch, a head-mounted display (HMD)), a portable game console, and / or any similar handheld electronic device. The term “handheld,” as used herein to describe the handheld device 602, means a device that is configured to be held by the user 102, regardless of whether the device is held by the hand of the user 102 or by another part of the body of the user 102 (e.g., wearable devices worn on the wrist, arm, leg, waist, head, etc. are considered “handheld” devices, as the term is used herein).

[0070] like Figure 6 As shown, the handheld device 602 includes one or more input / output (I / O) devices 608, such as finger-operated controls (e.g., joysticks, touchpads, triggers, depressible buttons, etc.), possibly other types of input or output devices, such as a touch screen, a microphone for receiving audio input (such as user voice input), a camera or other type of sensor (e.g., sensor 610) that can be used as an input device for receiving gesture input (such as movement of the handheld device 602 and / or the user's 102 hand). In some embodiments, additional input devices may be provided in the form of a keyboard, keypad, mouse, touch screen, joystick, control buttons, etc. The input devices may also include control mechanisms, such as basic volume control buttons for increasing / decreasing the volume, and power and reset buttons. The input devices may facilitate the entry of biometric data of the user 102, such as obtaining a fingerprint or palm print, scanning the user's eyes and / or face, capturing the user's voice, etc., for biometric identification / authentication of the user 102.

[0071] Meanwhile, the output device may include a display, a light emitting element (e.g., LED), a vibrator that generates a tactile sensation, a speaker (e.g., a headset), etc. A simple light emitting element (e.g., LED) may also be present to indicate a state, such as, for example, when powered on. Although some examples have been provided, the handheld device 602 may additionally or alternatively include any other type of output device. In some cases, the output of one or more output devices may be based on the input received by one or more of the input devices. For example, actuation of a control may cause a vibrator located near (e.g., below) or at any other location of the control to output a tactile response.

[0072] In addition, the handheld device 602 may include one or more communication interfaces 612 to facilitate wireless connections to a network and / or to one or more remote systems (e.g., a client machine 104 executing an application, a gaming console, a wireless access point, etc.). The communication interface 612 may implement one or more of a variety of wireless technologies, such as Wi-Fi, Bluetooth, radio frequency (RF), etc. It should be understood that the handheld device 602 may also include physical ports to facilitate wired connections to a network, connected peripherals, or plug-in network devices that communicate with other wireless networks.

[0073] In the illustrated implementation, the handheld device 602 also includes one or more processors 614 and a computer-readable medium 616. In some implementations, the processor 614 may include a central processing unit (CPU), a graphics processing unit (GPU), both a CPU and a GPU, a microprocessor, a digital signal processor, or other processing units or components known in the art. Alternatively or in addition, the functions described herein may be performed, at least in part, by one or more hardware logic components. For example, but not limited to, exemplary types of hardware logic components that may be used include field programmable gate arrays (FPGAs), application specific integrated circuits (ASICs), application specific standard products (ASSPs), system-on-chips (SOCs), complex programmable logic devices (CPLDs), and the like. In addition, each of the processors 614 may have its own local memory, which may also store program modules, program data, and / or one or more operating systems.

[0074] Computer-readable media 616 may include volatile and nonvolatile memory, removable and non-removable media implemented using any method or technology for storing information, such as computer-readable instructions, data structures, program modules, or other data. Such memory includes, but is not limited to, RAM, ROM, EEPROM, flash memory or other memory technologies, CD-ROM, digital versatile disks (DVDs) or other optical storage devices, cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, RAID storage systems, or any other medium that can be used to store the desired information and accessed by a computing device. Computer-readable media 616 may be implemented as a computer-readable storage medium ("CRSM"), which can be any available physical medium that processor 614 can access to execute instructions stored on computer-readable media 616. In one basic implementation, the CRSM may include random access memory ("RAM") and flash memory. In other implementations, the CRSM may include, but is not limited to, read-only memory ("ROM"), electrically erasable programmable read-only memory ("EEPROM"), or any other tangible medium that can be used to store the desired information and accessed by processor 614.

[0075] Several modules, such as instructions, data storage, etc., may be stored in the computer-readable medium 616 and configured to execute on the processor 614. Some exemplary functional modules are shown as being stored in the computer-readable medium 616 and executed on the processor 614, but the same functionality may alternatively be implemented in hardware, firmware, or a system on a chip (SOC).

[0076] The operating system module 618 can be configured to manage hardware within and coupled to the handheld device 602 for the benefit of other modules. Furthermore, the computer-readable medium 616 can store a network communication module 620 that enables the handheld device 602 to communicate with one or more other devices (such as a client machine 104 (e.g., a PC) executing an application (e.g., a game application), a gaming console, a remote computing system 106, etc.) via the communication interface 612. The computer-readable medium 616 can also include a game session database 622 to store data associated with games (or other applications) executed on the handheld device 602 or on a client machine 104 connected to the handheld device 602. The computer-readable medium 616 can also include a device record database 624 that stores data associated with devices to which the handheld device 602 is coupled (such as a client machine 104 (e.g., a PC, a gaming console, etc.), a remote computing system 106, etc.). The computer-readable medium 616 may also store game control instructions 626 that configure the handheld device 602 to function as a game controller, and general control instructions 628 that configure the handheld device 602 to function as a controller for other non-gaming devices.

[0077] The handheld device 602 is also shown as including one or more sensors 610. For example, the sensors 610 may include motion sensors, such as an inertial measurement unit (IMU), which may include one or more gyroscopes and / or accelerometers and / or magnetometers and / or compasses, or any other suitable motion sensor. In some embodiments, the sensors 610 may be implemented as independent gyroscopes, accelerometers, magnetometers, and compasses, and are not necessarily implemented as an IMU. In some embodiments, one or more of these sensors may be used to provide six-component motion sensing. For example, an IMU may be configured to sense and generate sensor data 604 indicating translational and / or rotational movement around 3D space. The sensor data 604 generated by such sensors 610 may be related to the range, rate, and / or acceleration of translational movement (X, Y, and Z movement) in 3D space, as well as the range, rate, and / or acceleration of rotational movement (roll, pitch, and yaw) in 3D space. The measurements may be generated according to a 3D coordinate system, such as a Cartesian (X, Y, and Z) or spherical coordinate system. The sensor data 604 may include, for example, measurements of displacement (e.g., displacement since a previous time record), velocity, and / or acceleration (represented by variables d, v, a and θ, ω, α, respectively) for translational and angular movement. The sensor data 604 may also include the number of times the sensor data 604 was generated and / or transmitted (e.g., within any suitable time interval), so that a history of the sensor data 604 may be collected and temporarily or permanently stored on the handheld device 602.

[0078] As another example, the sensor 610 may include a touch sensor configured to sense the proximity of an object (such as a finger, palm, etc.) to the touch sensor, which may be based on any suitable touch sensing technology, such as a capacitive touch sensor, a resistive touch sensor, an infrared touch sensor, a touch sensor that uses sound waves to detect the proximity of the finger 102, or any other type of touch sensor. For example, the touch sensor may be provided below or on the surface of the device, and / or within or on a finger-operated control to detect the proximity of the finger to the surface or to the finger-operated control. In response to detecting proximity (e.g., a finger touching or hovering over a surface), the touch sensor may generate sensor data 604 indicating the proximity of the finger. For example, the touch sensor may be embedded in the handle of the handheld device 602 to detect the grip of the user 102, and / or embedded in various controls including a touchpad, a joystick, buttons, etc. In an implementation utilizing capacitance-based sensing, a touch sensor may include electrodes (e.g., transmitter electrodes and receiver electrodes of a transcapacitive sensor), and voltages may be applied to the electrodes such that the electrodes are configured to measure changes in capacitance at the electrodes, which may be converted into sensor data 604 in the form of capacitance values ​​that indicate the proximity of an object to the sensor 610. For example, changes in capacitance at electrodes of a capacitance-based touch sensor may be affected by an object (such as a finger) approaching the electrodes. The raw capacitance may be digitized into a proximity value to generate sensor data 604.

[0079] As another example, sensor 610 may include a pressure sensor, such as a force sensing resistor (FSR). For example, an FSR may include a conductive material (e.g., a semiconductor material, such as an ink composition) spaced apart from a resistive film, and an actuator configured to transmit a force to the resistive film such that the resistive material contacts the conductive material under the action of a compressive force applied to the actuator. The FSR may exhibit a varying resistance in response to a variable force to generate sensor data 604 corresponding to a resistance value. The FSR may be a "shunt mode" FSR or a "pass mode" FSR. In the case of a shunt mode FSR, the conductive material spaced apart from the resistive film may be a plurality of interdigitated metal fingers. When a force is applied to the actuator of the FSR, the resistive film contacts some of the interdigitated metal fingers, which shuns the metal fingers, thereby changing the resistance at the output terminal of the FSR, which may be digitized into an FSR value to generate sensor data 604. In some embodiments, the pressure sensor may additionally or alternatively include other types of pressure sensing mechanisms, such as piezoelectric sensors, strain gauges, and the like.

[0080] Other examples of sensors 610 configured to generate corresponding sensor data 604 may include, but are not limited to, temperature sensors, humidity sensors, cameras, and the like. Regardless of the type of sensor 610 of the handheld device 602, the sensor 610 is configured to generate sensor data 604 related to the physical state of the handheld device 602 in some manner. For example, a touch sensor may generate sensor data 604 indicating whether an object (e.g., a finger) is in contact with or in proximity to a portion of the device 602 that includes the touch sensor (e.g., a directional pad (D-pad), a joystick, a trigger button, a bumper button, a selector button, etc.). As another example, a pressure sensor may generate sensor data 604 indicating whether an object is pressing on a portion of the device 602 and whether the portion of the device 602 is being pressed lightly or hard by the object. As yet another example, a motion sensor (e.g., a gyroscope and / or an accelerometer) may generate sensor data 604 indicating whether the orientation and / or spatial position of the handheld device 602 in 3D space has changed and / or whether the handheld device 602 is moving quickly or slowly. Thus, the sensors 610 of the handheld device 602 are configured to generate sensor data 604 indicative of these and other types of physical states of the device 602 .

[0081] Figure 6 The handheld device 602 is shown to also include cryptographic hardware 630. For example, a service provider of a video gaming service and / or a third-party manufacturer may manufacture a "trusted" handheld device 602 that is manufactured with tamper-resistant hardware components embedded therein. The embedded hardware components may include Figure 6 , which in turn can store a private key 632. For example, the private key 632 can exist in the non-volatile memory of the handheld device 602.

[0082] In some embodiments, the cryptographic hardware 630 is tamper-resistant. For example, the cryptographic hardware 630 may be included or encapsulated within a tamper-resistant housing, and the cryptographic hardware 630 may be configured to disable itself if the tamper-resistant housing is damaged. For example, the cryptographic hardware 630 may be configured to erase or delete the private key 632 and / or send an alert to the remote computing system 106 if the tamper-resistant housing is damaged or otherwise tampered with. This makes it difficult for a user to illegally gain access to the private key 632, or at least difficult to do so without being detected, which prevents the private key 632 from being shared with others and the private key 632 from being used to act as a "smurf" through another user account 120. In online gaming, "smurfing" is the act of a player of a certain skill level playing the game under another person's account or secondary account to appear to be of a lower level or skill level.

[0083] In some embodiments, user 102 may initially associate or register handheld device 602 with his / her user account 120 (and possibly with additional user accounts 120, such as family members' accounts). This may be accomplished by performing an initial registration process for handheld device 602. The initial registration process may include an initial activation process that utilizes, for example, a two-factor authentication (2FA) step for added security. For example, user 102 may pair handheld device 602 with client machine 104 in proximity to handheld device 602 using, for example, a short-range wireless protocol (such as Bluetooth). User 102 may log in to his / her user account 120 using a client application (e.g., a video game client) executed on client machine 104 or on user 102's mobile device (e.g., a mobile phone). In response to user 102 logging in, remote computing system 602 may receive an indication of paired but unregistered / unactivated device 602 and may send an activation code to user 102, such as by sending a message (such as a text message) to a mobile number or an email to an email address specified in user account 120. The user 102 can access the message to obtain the activation code and can enter the activation code via a video game client executed on the user's phone or on the client machine 104 (e.g., by using the handheld device 602 to enter the activation code). If the remote system 106 receives the correct activation code within a specified time limit, the handheld device 602 can be associated with the user account 120 of the user 102, such as by indicating in the user account 120 that the handheld device 602 is a registered device for the user account 120, the time and date of registration, the location where the handheld device 602 was activated, etc. The remote computing system 106 can also associate the user account 120 with the private key 632 of the handheld device 602 and / or with the biometric data of the user 102 (e.g., fingerprint, eye print, face print, voice print, etc.) obtained through an input device of the handheld device 602 as a method of authenticating the user 102 in the future, such as when the user 102 logs into his / her user account 120 in the future and is using the handheld device 602 registered with the user account 120.

[0084] In some embodiments, an additional layer of security may be implemented to make switching a handheld device 602 from one user account 120 to another more secure, which may help prevent unauthorized use of a trusted handheld device 602 in the event that the device 602 is stolen or lost. For example, the remote computing system 106 may enforce a waiting period (e.g., a waiting period of several days) after the device 602 is associated / registered with a first user account 120 before the device 602 is allowed to switch to a second user account 120 (e.g., by disassociating / unregistering the device 602 from the first user account 120 and associating / registering the device 602 with the second user account 120). The remote computing system 106 may additionally or alternatively limit the number of times a user 102 is allowed to switch a handheld device 602 between user accounts 120 within a given time period (e.g., the user 102 may be allowed to switch a handheld device 602 from one user account 120 to another user account 120 no more than twice within an hour). These additional layers of security can help curb unauthorized use of the trusted handheld device 602 .

[0085] Once the handheld device 602 is registered with the user account 120, the user 102 may use the device 602 to interact with the video game platform, such as by connecting the handheld device 602 to their client machine 104 (e.g., pairing the device 602 with the client machine 104 via a wireless communication link) (this may occur automatically after a first pairing process using the device record database 624), and use the device 602 as a handheld game controller to play the video game 110. In this scenario, the client machine 104 may be used to display images of the video game 110 while the user 102 plays the video game 110 by operating the handheld device 602. At any suitable time during interaction with the video game platform, the handheld device 602 may obtain biometric data (e.g., fingerprint, eye print, face print, voice print, etc.) of the user 102 via input devices of the handheld device 602, and may transmit the obtained biometric data to the remote computing system 106 via the communication interface 612 (e.g., by routing the biometric data through the client machine 104 to the remote computing system 106), and the biometric data may be used by the remote computing system 106 to authenticate the user account 120, authenticate the user 102, and / or authenticate the handheld device 602. Furthermore, at any suitable time during interaction with the video game platform, the private key 632 may be used by logic of the handheld device 602 to encrypt device output (such as game control data 606 and / or sensor data 604 transmitted by the handheld device 602 during use of the device 602). For example, the private key 632 can be used to sign the game control data 606 and / or the sensor data 604 to convert the data into ciphertext form using any suitable encryption algorithm, and the device 602 can send the encrypted data to the remote computing system 106 via the communication interface 612 (e.g., by routing the encrypted data through the client machine 104 to the remote computing system 106). The remote computing system 106 can maintain a repository of private keys for trusted handheld devices in the data store 116 (or database 116), which can include a copy of the private key 632 used by the handheld device 602 to encrypt data sent by the device to the remote computing system 106. The remote computing system 106 may have recorded the private key in the data store 116 when the trusted handheld device was manufactured or thereafter. Using the private key accessible to the remote computing system 106, the system 106 can decrypt the encrypted data it receives from the handheld device 602 to verify that the received data was encrypted with the expected private key 632. Thus, the remote system 106 can use a copy of the private key 632 for authenticating the user account 120, authenticating the user 102 and / or authenticating the handheld device 602, as well as other possible uses of the private key 632, knowing that the private key 632 is used by the handheld device 602 to encrypt device output.In some embodiments, the remote computing system 106, in response to receiving data associated with a logged-in user account 120, may request the user 102 to enter a code (e.g., a personal identification number (PIN), a password, a passphrase, etc.) to authenticate the user 102 each time the user account 120 is logged in. Such a request may be sent via a 2FA device of the user 102 (e.g., via a mobile phone, via the client machine 104, etc.), and a response to the request may be received by the remote system 106 from the same 2FA device of the user 102. In some embodiments, no additional user action is required in order to use an already registered handheld device 602 associated with the corresponding logged-in user account 120. That is, using the handheld device 602 associated with the user account 120 with which the device 602 is registered requires that the device 602 encrypt data using its private key 632 and send the encrypted data to the remote computing system 106, and the remote computing system 106 decrypt the data to verify that the received data was encrypted with the expected private key 632. For example, the remote system 106 may send a block of data to the handheld device 602, which may encrypt the block of data and return the encrypted data to the remote system 106, and the remote system 106 may then verify that the encryption was performed correctly, all without transmitting the key 632 itself.

[0086] For example, a data store 116 (or database 116) accessible to the remote computing system 106 may maintain biometric data and / or multiple private keys that have been associated with multiple trusted handheld devices (such as the handheld device 602), and the remote computing system 106 may compare biometric data and / or private keys (such as the private key 632) used to encrypt data received from the client machine 104 and / or handheld devices to determine whether the received biometric data and / or private key matches any biometric data and / or private keys maintained in the database 116. As described herein, these operations may be performed for authentication purposes and / or for calculating a trust score. In other words, receipt of biometric data that matches biometric data maintained in database 116 and / or encrypted data encrypted with a private key 632 that matches a private key maintained in the database can be used to authenticate user 102, device 602, and / or user account 120 associated therewith, and / or receipt of matching biometric data and / or encrypted data encrypted with a matching private key 632 can be used to generate a trust score for the associated user account 120, which can be used for player matching. In this sense, a user account 120 associated with a handheld device 602 that provides matching biometric data and / or encrypted data encrypted with a matching private key 632 to a remote computing system 106 can be seamlessly authenticated (e.g., in some cases, without requiring additional user action) and is more likely to be matched with user accounts 120 of other human players than with "untrusted" user accounts 120 that may be associated with non-human players (e.g., software designed to cheat).

[0087] Thus, when a user 102 utilizes a handheld device 602 to interact with a video game platform (e.g., to play one or more video games 110 on their respective client machines 104), sensor data 604 and game control data 606 may be sent to the client machine 104 and forwarded from the client machine 104 to the remote computing system 106. The game control data 606 may be used to control aspects of the video game 110 and, thereby, processed by the video game 110 to determine how to render the next frame of the video game 110. The sensor data 604 represents raw, unfiltered sensor data 604, such as raw data generated by a gyroscope, raw data generated by an accelerometer, and / or raw data generated by a touch sensor (e.g., a capacitive touchpad). In a streaming implementation, the video game 110 may be executed on the remote computing system 106, and the remote computing system 106 may capture the video game 110 data and may transmit the video game 110 data to the client machine 104 of the user 102 via the network 108. This may involve capturing the state of the video game 110, encoding the video and audio data into bits, transmitting the encoded bits to the remote computing system 106 of the client machine 104 over the computer network 108, and an application (e.g., a video game client) executing on the client machine 104 may decode the bits to output the image of a given frame via a display and the audio of a given frame via the speakers of the client machine 104 (or via headphones connected to the client machine). The user 102 may react to the video he / she is viewing and the audio he / she is hearing by operating the handheld device 602. For example, the user 102 may actuate controls of the handheld device (e.g., press a directional pad (D-pad), yaw a joystick, swipe a finger on a trackpad, etc.), and / or may tilt or move the handheld device 602 in 3D space to control aspects of the video game 110. In response to operation of the handheld device 602, the handheld device 602 may generate game control data 606 that is transmitted to the remote computing system 106 either directly via the wireless access point and through the computer network 108, or via the client machine 104 associated with the handheld device 602. In either case, the game control data 606 may be transmitted to the remote computing system 106 in real time to control aspects of the video game 110. For example, the game control data 606 may be processed by the video game 110 to control the movement of virtual objects (e.g., a player-controlled character) of the video game 110 by causing the virtual objects to move within a virtual world represented by a scene on the display of the client machine 104.

[0088] The game control data 606 may include at least some sensor data 604 generated by the sensors 610 of the device 602 (such as filtered / attenuated sensor data 604 and / or amplified sensor data 604), sensor data 604 sent by the device 602 to the remote computing system 106 (such as Figure 6 ) represents raw, unfiltered sensor data 604 that is not used to control aspects of the video game 110, but is instead used to generate a machine-learned trust score for the associated user account 120.

[0089] exist Figure 6 At step 1 in the example, the computing system 106 may train the machine learning model 216 using historical sensor data 604 sampled from at least the data store 116. For example, the computing system 106 may access a portion of the historical sensor data 604 associated with a sample set of user accounts 120 registered with the video game service and may use the sampled sensor data 604 to train the machine learning model 216. As described herein, the historical sensor data 604 may have been received from the client machine 104 along with historical game control data 606 as the user 102 interacts with the video game platform using their handheld device 602. In some embodiments, the portion of the sensor data 604 used as training data is represented by a set of features, and each user account 120 in the sample set is labeled with a label indicating whether the historical game control data 606 associated with the corresponding user account 120 was generated by the handheld device 602, rather than having been synthesized and / or modified using software, as a human player holds and operates the handheld device 602. In other words, user accounts 120 that are determined to be associated with game control data 606 that was artificially generated by a human user 102 operating a handheld device 602 may be marked as such, while other user accounts 120 that are determined to be associated with synthesized and / or modified game control data (i.e., data synthesized and / or modified by software to control aspects of a video game) may be marked as such. In this way, supervised learning methods can be employed to train the machine learning model 216 to predict legitimate human players who are likely to be operating a handheld device 602, rather than players of non-human software designed to cheat.

[0090] For example, when a human operates the handheld device 602, there may be subtle movements of the handheld device 602 that are unintentional movements, but which are nevertheless detectable by one or more physical sensors 610 of the handheld device 602 and, therefore, may be represented in the sensor data 604. Based on the notion that such sensor data 604 will exhibit these subtle differences, the machine learning model 216 may be trained using the sensor data 604 as training data to distinguish between human players and non-human players by identifying these subtle differences (e.g., movement, finger proximity, etc.) in the sensor data 604 that are generated by the physical sensors 610 of the real, physical handheld device 602 as a result of the handheld device 602 having been mechanically operated (e.g., by the human user 102). Conversely, if sensor data 604 is received but does not exhibit the expected subtle differences that would be generated by human operation of the handheld device 602, it may be inferred that the corresponding game control data 606 was not generated by operation of the real, tangible handheld device 602, but rather was synthesized and / or modified using software. For example, cheating players may employ third-party software, or develop their own software, that is configured to automate the actions of the cheating player's avatar (e.g., by programmatically causing a mouse cursor to move to a target and firing a weapon in an automated manner). This so-called "automatic aimbot" software effectively plays the video game 110 in place of a human player, such that the human player is not actually playing the video game 110, and the software is synthesizing and / or modifying game control data 606 that is processed by the video game 110 in the same manner as real game control data 606, thereby giving the cheating player an advantage over legitimate human players who do not cheat. If such synthesized and / or modified game control data 606 is not detected, computerized algorithms may become ubiquitous and be widely used to enhance the performance of cheating players in multiplayer games, which may ruin the experience of human players who want to play the video game 110 legitimately and who may be matched with these computerized algorithms. In these cases, attempts to mimic sensor data 604 generated by human operation of handheld device 602 can be detected by machine learning model 216, which is trained to distinguish between human players and non-human players (such as automated aimbots), and these and other kinds of cheating can be remedied, such as by isolating non-human players from matches in their own multiplayer video games.

[0091] It should be understood that in addition to or in lieu of the historical sensor data 604 described above, additional data may be used to train the machine learning model 216. For example, historical game control data 606 may be collected over time from the client machine 104, where the game control data 606 has been generated based on user input provided by a human user to a handheld device to control aspects of the video game 110. These user inputs may include actuation of controls on the handheld device 602 (such as button presses, deflections of a joystick, swipes of a finger on a trackpad, etc.) and / or tilting or movement of the handheld device 602 in 3D space. Thus, the historical game control data 606 (e.g., data indicating user input provided to the handheld device 602, such as to control aspects of the video game 110) may be used as training data in addition to or in lieu of the historical sensor data 604. Using both the historical sensor data 604 and the historical game control data 606 as training data allows for the formation of correlations between the game control data 606 and the sensor data 604 generated simultaneously. As yet another example, wireless communication data may be collected from the client machines 104 over time, and the historical wireless communication data may be used as training data in conjunction with or in place of the historical sensor data 604. The wireless communication data may include, but is not limited to, wireless (e.g., WiFi, Bluetooth, etc.) signal strength values, data indicating instances of dropped data packets sent from the handheld device 602 to the associated client machine 104, data indicating the number of dropped data packets sent from the handheld device 602 to the associated client machine 104, etc. The wireless communication data may be obtained by the handheld device 602, by the client machine 104, and / or any other suitable device local to the environment of the user 102.

[0092] As described above, the training data may include two components: features and labels. However, in some embodiments, the training data used to train the machine learning model 216 may be unlabeled. Therefore, any suitable learning technique (such as supervised learning, unsupervised learning, semi-supervised learning, reinforcement learning, etc.) may be used to train the machine learning model 216. The features included in the training data may be represented by a set of features, such as in the form of an n-dimensional feature vector that contains quantifiable information about the properties of the training data.Exemplary features included in the training data may include, but are not limited to: sensor data 604 values ​​(e.g., capacitance values, resistance values, displacement values, velocity values, acceleration values, temperature values, humidity values, etc.), game control data 606 values ​​(e.g., values ​​generated by potentiometers and other switches of finger-operated controls), biometric data values, private key 632 values ​​associated with the handheld device 602 that encrypts data sent to the remote computing system 106 using the private key 632, including the amount of time the private key 632 (and, therefore, the trusted handheld device 602) has been associated with / registered with the user account 120, the amount of time the trusted handheld device 602 (and / or its private key 632) has been associated with / registered with the user account 120, and the number of times the trusted handheld device 602 (and / or its private key 632) has been used by the user. the number of times the user account 120 has been used, wireless communication data values ​​(e.g., wireless signal strength values, values ​​indicating instances of dropped data packets sent from the handheld device 602 to the associated client machine 104, values ​​indicating the number or frequency of dropped data packets sent from the handheld device 602 to the associated client machine 104, etc.), the number of times the trusted handheld device 602 (and / or its private key 632) has been switched between different user accounts 120), the amount of time the player spends playing the video game 110 generally, the amount of time the player spends playing a particular video game 110, the number of times the player logs in and plays the video game 110 in a day, the player's game history data (e.g., total scores (per game, per round, etc.), the number and / or frequency of reports of cheating by the player, the number and / or frequency of acquittals of cheating by the player, the number and / or frequency of convictions of cheating by the player, a confidence value (score) output by a machine learning model that detects cheating players during video game play, the number of multiple user accounts 120 associated with a single player (this may be inferred from common addresses, phone numbers, payment instruments, etc. tied to multiple user accounts 120), how long the user account 120 has been registered with the video game service, the number of previously banned user accounts 120 tied to the player, the number and / or frequency of monetary transactions by the player on the video game platform, the amount of each transaction, and the number of transactions with the player. The number of digital items of monetary value associated with a user account 120, the number of times a user account 120 has changed hands (e.g., transferred between different owners / players), the frequency with which a user account 120 has been transferred between players, the geographic locations from which players have logged into the video gaming service, the number of different payment instruments, phone numbers, mailing addresses, etc., that have been associated with the user account 120, and / or how often these items have changed, and / or any other suitable characteristics that may be relevant to calculating a trust score 118 that indicates the probability that the game control data 602 associated with the user account was generated by a handheld device held and operated by a human player, rather than having been synthesized and / or modified using software.

[0093] As in Figure 6 As part of the training at step 1 in

[0065] , the training component 210 may set weights for machine learning. These weights may be applied to a set of features included in the training data, such as those derived from historical data in the data store 116 (including historical sensor data 604). In some embodiments, the weights set during the training process may be applied to parameters internal to the machine learning model (e.g., the weights of neurons in a hidden layer of a neural network). These internal parameters of the machine learning model may or may not map one-to-one with each input feature in the set of features. These weights may indicate the impact of any given feature or parameter on the score 118 output by the trained machine learning model 216.

[0094] exist Figure 6At step 2, the computing system 106 may score one or more registered user accounts 120 using the trained machine learning model 216. For example, the computing system 106 may receive new sensor data 604 and new game control data 606 associated with one or more logged-in, registered user accounts 120 from one or more client machines 104. In an illustrative example, the computing system 106 may receive information 122 indicating that the logged-in user account 120 is currently playing or has launched a video game 110. The video game 110 may be executed on the client machine 104 via an installed client application, or the video game 110 may be streamed to the client machine 104 while executing on a remote computing system 106. In any case, when players 102 log in with their user accounts 120 and execute a particular video game 110, requesting to play in multiplayer mode, their respective client machines 104 may provide information 122 indicating as much as possible to the computing system 106, and when the video game 110 is launched and the players begin playing, sensor data 604 and game control data 606 may be streamed in real time from the client machines 104 to the remote computing system 106. The computing system 106 may provide the new sensor data 604 it receives as input to the trained machine learning model 216 and may generate scores 118 as outputs of the trained machine learning model 216, these scores being associated with the respective user accounts 120 that are logged in and associated with the new game control data 606. In this example, the scores 118 may be associated with the probability that the new game control data 606 has been generated by the handheld device 602 associated with the client machine. In this case, a high trust score indicates a trustworthy user account 120 (e.g., a user account that may be associated with a human player operating the handheld device 602), while a low trust score indicates an untrustworthy user account 120 (e.g., a user account that may be associated with a non-human player (such as software) that generates synthesized and / or modified game control data 606 that appears to be similar to real game control data 606 generated by the real handheld device 602). In some embodiments, the score 118 is a variable that is normalized within the range of [0, 1]. The trust score 118 can have a monotonic relationship with the probability that the new game control data 606 has been generated by the handheld device 602. The relationship between the score 118 and the actual probability, while monotonic, can be a linear relationship or a non-linear relationship. Of course, the scoring can be implemented in any suitable manner to predict whether the new game control data 606 is generated by the handheld device 602 or synthesized and / or modified using software.

[0095] In some embodiments, the new game control data 606 itself can be provided as additional input to the trained machine learning model 216 to generate the score 118 based at least in part on the game control data 606 provided as additional input to the trained machine learning model 216. For example, the user 102 can operate the handheld device 602 during gameplay by actuating controls of the handheld device 602 (e.g., pressing buttons such as a directional pad (D-pad), yaw a joystick, swiping a finger on a trackpad, etc.), and / or control aspects of the video game 110 by tilting or moving the handheld device 602 in 3D space. In response to the user's operation of the handheld device 602, the handheld device 602 can generate game control data 606 that is sent to the remote computing system 106. This new game control data 606 (indicative of the user input provided to the handheld device 602) can be provided as input to the trained machine learning model 216. It should be understood that in addition to providing sensor data 604 as input to the trained machine learning model 216, new game control data 606 may also be provided as input to the trained machine learning model 216. An exemplary reason for providing the game control data 606 as input to the trained machine learning model 216 is that a person providing user input to the handheld device 602 may be "noisier" or less polished than a computer program simulating the same type of user input. Thus, the trained machine learning model 216 may be trained to distinguish between human users and non-human players (e.g., software designed to cheat) based at least in part on the game control data 606 received from the client machine 104 and provided as input to the trained machine learning model 216.

[0096] In some embodiments, new wireless communication data can be provided as additional input to the trained machine learning model 216 to generate the score 118 based at least in part on the wireless communication data provided as additional input to the trained machine learning model 216. For example, wireless (e.g., WiFi, Bluetooth, etc.) signal strength can be determined relative to the handheld device 602 relative to another device (such as the client machine 104) with which it is communicating, and the signal strength can vary (e.g., increase or decrease) with interference from wireless signals in the environment and / or the distance separating the handheld device 602 and the other device with which it is communicating. The presence of a wireless signal strength value and / or a wireless signal strength that varies over time (e.g., observing a varying signal strength value) can indicate that a human player is using the handheld device 602, as these characteristics are typically encountered in a gaming system setting. In contrast, the absence of a signal strength value or a constant signal strength value that does not vary over time can indicate a non-human player (e.g., software designed to cheat). As another example, wireless communication data indicating instances of dropped data packets sent from the handheld device 602 to the associated client machine 104 and / or the number of dropped data packets sent from the handheld device 602 to the associated client machine 104 may be determined and used as input to the trained machine learning model 216. For example, the presence of one or more dropped packets and / or the number of dropped data packets that varies over time may indicate that a human player is using the handheld device 602. In contrast, if dropped packets are absent from the wireless communication data and / or if the number of dropped data packets remains constant (e.g., does not vary) over time, this may indicate a non-human player (e.g., software designed to cheat).

[0097] In some embodiments, determining the score 118 is further based on determining that the biometric data received from the client machine 104 matches the biometric data maintained in the database 116 and / or that the private key 632 used to encrypt the data received from the client machine 104 matches one of a plurality of private keys maintained in the database, the biometric data and private keys maintained in the database being associated with a plurality of trusted handheld devices 602. That is, the biometric data and / or private key 632 can be used as a proxy for trust to prove to the remote computing system 106 that an authentic handheld controller 602, trusted by the system 106, is sending 606 game control data.

[0098] exist Figure 6At step 3 in , the computing system 106 may match players 102 together in multiplayer matches for playing the video game 110 in a multiplayer mode using the machine learning scores 118 determined for the logged-in, registered user accounts 120 based on the new sensor data 604 received from the corresponding client machines 104, and may assign a subset of the logged-in user accounts 120 to different ones of the plurality of matches by providing match assignments 124 to the client machines 104, such that a subset of the logged-in user accounts 120 is assigned to different ones of the plurality of matches based at least in part on the machine learning scores 118 determined for the logged-in user accounts 120. In this manner, if the trained machine learning model 216 assigns low (e.g., below a threshold) scores 118 to a first subset of the logged-in user accounts 120 and high (e.g., above a threshold) scores 118 to a second subset of the logged-in user accounts 120, the first subset of the logged-in user accounts 120 may be assigned to a first one of the plurality of matches, and the second subset of the logged-in user accounts 120 may be assigned to a different second one of the plurality of matches. This may include assigning the user account 120 to a match at the start of the video game 110 (e.g., before a match is initiated) and / or reassigning the user account 120 to a new match midway through the video game 110 (e.g., after a match is initiated). For example, if a first logged-in user account 120 is initially assigned to a first match designated for a human player 102, and subsequently, based on real-time data provided as input to the trained machine learning model 216, a machine learning score 118 is generated for the user account 120, the score 118 indicating that the first user account 120 may be associated with a non-human player (e.g., software) that is synthesizing and / or modifying game control data 606, then the computing system 106 may reassign the first user account to a second match designated for a non-human player 102 (e.g., a cheating player that is using software to synthesize and / or modify game control data). In some embodiments, when a client machine 104 sends game control data 606 and does not send raw, unfiltered sensor data 604 along with the game control data 606, the user account 120 associated therewith may be deemed untrustworthy based on the absence of the raw sensor data 604. In other embodiments, the game control data 606 may be provided as input to a trained machine learning model 216 to generate a score 118 for a user account even in the absence of the raw sensor data 604, or a machine learning score 118 may be generated for such a user account 120 in any other suitable manner as described herein to determine the cheating propensity of a player associated with the user account 120.

[0099] exist Figure 6At step 4 in , the computing system 106 may cause the video game 110 to be executed in the assigned match for each user account 120. In a specific implementation of streaming, this may involve capturing the state of the video game 110, executing on the remote system 106, encoding the video and audio data into bits, transmitting the encoded bits to the remote computing system 106 of the client machine 104 over the computer network 108, and an application (e.g., a video game client) executing on the client machine 104 may decode the bits to output the image of the given frame via the display and output the audio of the given frame via the speakers of the client machine 104 (or via headphones connected to the client machine). It should be understood that in some embodiments, Figure 1 The computer network 108 may represent a local area network (LAN), which may be the case in a "home-based" video game streaming scenario. In such a scenario, the computing system 106 may represent a host computing system located in the same geographic location as or near the client machine 104. In a wide area network (WAN) or LAN implementation, the client machine 104 may be implemented as a thin client that is configured to send data to and receive data from the computing system 106 with minimal processing of the data on the client machine 104 itself (e.g., without having to execute the video game 110 on the client machine 104 itself). In a thin client implementation, game control data 606 and sensor data 604 may be received by the computing system 106, and the computing system 106 may send frames of image data and audio data to the client machine 104 for presentation on a display associated with the client machine 104. In an implementation where a client application on each machine 104 is executing the video game 110, at step 4, information may be sent to each client application executing on the client machine 104 to cause execution of the video game 110 on the client machine 104 in the assigned match for the logged-in user account 120 in question. In cases where players are grouped into matches based at least in part on the machine-learned scores 118, the in-game experience for at least some of the groups of players 102 may be improved because the system may group players (including non-human players (e.g., software designed to cheat)) who are expected to behave poorly (e.g., through cheating) into the same match, and in doing so may keep badly behaved players isolated from other players who wish to play the video game 110 legitimately.

[0100] Figure 76 is a flow chart of an exemplary process 700 for training a machine learning model 216 using data including sensor data 604 to predict the probability that game control data 606 received from a client machine 104 has been generated by a handheld device 602. For purposes of discussion, the process 700 is described with reference to the previous figures.

[0101] At 702, the computing system 106 may provide the user 102 with access to a video game service. For example, the computing system 106 may allow the user to access and browse a catalog of video games 110, modify a user profile, conduct transactions, participate in social media activities, and other similar actions. The computing system 106 may distribute the video games 110 (and their content) to the client machines 104 as part of the video game service. In an illustrative example, a user 102 with access to the video game service may load an installed client application, log in using a registered user account, select a desired video game 110, and execute the video game 110 on his / her client machine 104 via the client application, by streaming the video game 110, downloading the video game 110, and executing the game locally on the client machine 104, or any other suitable game distribution / execution platform.

[0102] At 704, the computing system 106 may collect and store data associated with the user account 120 registered with the video game service. This data may include at least the sensor data 604 described herein, but may also include the data 114 and game control data 606 described herein. This data may be collected at any suitable time at block 704, such as when the user 102 accesses the video game service with their registered user account 120 and uses the video game platform, such as to play a video game 110 thereon. Because this data is generated at defined intervals (e.g., by receiving real-time streaming data from the client machine 104), received, and / or in response to events (e.g., when the user account 120 exits the video game, when network bandwidth is sufficient to send the data, etc.), data generated locally on the client machine 104 and / or by the handheld device 602 may be collected in real time. Over time, it may be realized that a large collection of data associated with the registered user account 120 is available for use by the computing system 106.

[0103] At 706, the computing system 106 may access (historical) data including (historical) sensor data 604 associated with a sample set of user accounts 120 registered with the video game service via the training component 210. When the game control data 606 is received, the (historical) sensor data 604 may have been received from the client machine 104 along with (historical) game control data 606 processed by the video game 110, such as to control aspects of the video game 110. Thus, the (historical) sensor data 604 may be associated with corresponding (historical) game control data 606 generated at the same time. In an example, the sensor data 604 accessed at block 706 may include raw sensor data 604 generated by one or more physical sensors 610 of the handheld devices 602 when the user 102 operated those handheld devices 602 to play the video game 110 on the video game platform.

[0104] At 708, when a human player holds and operates the device 602 to generate (historical) game control data 606 associated with the user account 120, the computing system 106 may, via the training component 210, tag each user account 120 in the sample set of user accounts 120 with a label indicating whether the (historical) game control data 606 associated with the user account 120 was generated by the handheld device 602.

[0105] At 710, the computing system 106 may train the machine learning model 216 via the training component 210 using the (historical) sensor data 604 and possible additional data as described herein (e.g., (historical) game control data 606, (historical) wireless communication data, etc.) as training data to obtain a trained machine learning model 216. As shown in sub-block 712, the training of the machine learning model 216 at block 710 may include setting weights for machine learning. These weights may be applied to a set of features derived from the historical sensor data 604. In some embodiments, the weights set at block 712 may be applied to parameters internal to the machine learning model (e.g., weights of neurons in a hidden layer of a neural network). These internal parameters of the machine learning model 216 may or may not have a one-to-one mapping with each input feature in the set of features. As shown by the arrow from block 710 to block 704, the machine learning model 216 may be retrained using updated (historical) data, including updated (historical) sensor data 604, to obtain a new trained machine learning model 216 adapted to recent player behavior. This allows the machine learning model 216 to automatically adapt to changing player behavior over time.

[0106] Figure 8is a flow chart of an exemplary process 800 for determining trust scores for user accounts using a trained machine learning model 216, which are associated with the probability that game control data 606 has been generated by a handheld device 602. For discussion purposes, the process 800 is described with reference to the previous figures. Figure 7 and Figure 8 As shown by page external reference “C” in FIG, process 800 may continue from block 710 of process 700 .

[0107] At 802, the computing system 106 may receive game control data 606 and sensor data 604 from the client machine 104. The game control data 606 and sensor data 604 may be associated with a user account 120 logged into and registered with the video game service. The game control data 606 may be data to be processed by the video game 110 for controlling aspects of the video game 110. The sensor data 604 received at block 802 may include, but is not limited to, capacitance values, resistance values, displacement values, velocity values, acceleration values, temperature values, humidity values, and the like. In some embodiments, these values ​​represent raw (e.g., unfiltered, unamplified) values, assuming they were generated by the actual physical sensors 610 of the handheld device 602. Additionally, some or all of the data received at block 802 may be encrypted (e.g., the device 602 may have encrypted the data using a private key 632 before sending it to the remote system 106).

[0108] At 804, the computing system 106 may also receive biometric data from the client machine 104. For example, an input device (e.g., a touch sensor, a camera, a microphone, etc.) of the handheld device 602 may obtain biometric data from a user of the handheld device 602, and the handheld device 602 may transmit the obtained biometric data to the client machine 104, and the client machine 104 may forward the biometric data to the remote computing system 106 over the computer network 108. The biometric data may also be received as encrypted data (e.g., the device 602 may encrypt the biometric data using the private key 632 before sending the data to the remote system 106).

[0109] At 806, the computing system 106 may evaluate the private key 632 and / or the biometric data. As shown in sub-blocks 808, 810, and 812, this evaluation may include various operations. For example, the remote system 106 may decrypt any encrypted data received at blocks 802 and / or 804 to verify that the expected private key 632 was used to encrypt the received data. At sub-block 808, the computing system 106 may determine that the biometric data and / or private key 632 is associated with the user account 120 associated with the game control data 606 and sensor data 604 received at block 802. This may be determined by comparing the biometric data with biometric data already associated with the user account 120 and / or by determining that the encrypted data was actually encrypted using the private key 632 already associated with the user account 120.

[0110] At sub-block 810, the computing system 106 may determine that the biometric data matches the biometric data maintained in the database 116 and / or the private key 632 matches one of a plurality of private keys maintained in the database 116. The biometric data and / or private keys maintained in the database 116 may be associated with a plurality of trusted handheld devices 602 such that if the private key 632 derived from the encrypted data matches one of the private keys in the database 116 and / or if the received biometric data matches any of the biometric data in the database 116, the computing system 106 may use the matching data as a proxy for trust that it was sent from the trusted handheld device 602.

[0111] At sub-block 812, the computing system 106 may determine data associated with the biometric data and / or private key 632. For example, the computing system 106 may determine the length of time the biometric data and / or private key 632 has been associated with the user account 120. The computing system 106 may additionally or alternatively determine the number of times the biometric data and / or private key 632 has been used with or to log into the user account 120. The computing system 106 may additionally or alternatively determine the number of times the private key 632 has been switched between different user accounts 120, such as by being disassociated / unregistered from a first user account 120 and subsequently associated / registered with a second user account 120.

[0112] At 814, the computing system 106 may provide data as input to the trained machine learning model 216 via the scoring component 212. In some embodiments, this may involve providing various types of data as input to the trained machine learning model 216 at block 806, as shown in sub-blocks 816, 818, and 820. For example, at sub-block 816, the sensor data 604 received at block 802 may be provided as input to the trained machine learning model 216. At sub-block 818, the game control data 606 received at block 802 may be provided as an additional input to the trained machine learning model 216. At sub-block 820, private key 632 data and / or biometric data may be provided as another additional input to the trained machine learning model 216, such as the value of the private key 632 and / or any data determined at sub-block 812. In some embodiments, wireless communication data (e.g., wireless signal strength data, data related to discarded data packets, etc.) may be provided as input to the trained machine learning model 216 at block 814. In some embodiments, as described herein, the data 114 may be provided as input to the trained machine learning model 216 at block 814. Generally, as described herein, any quantifiable data included in a set of features used to train the machine learning model 216 may be provided as input to the trained machine learning model 216. In embodiments where the sensor data 604 is provided as input to the model 216, the sensor data 604 constitutes the unknown input used to score the user account 120 in question.

[0113] At 822, the computing system 106, via the scoring component 212, may generate a trust score 118 associated with the user account 120, as output from the trained machine learning model 216, that is associated with the game control data 606 received at block 802. The score 118 is associated with a probability that the game control data 606 has been generated by a handheld device 602 associated with the client machine 104 that sent the game control data 606 to the remote computing system 106. The score 118 may also be considered to be associated with a probability that the game control data 606 has been “human-generated,” as opposed to having been synthesized and / or modified by software (e.g., an automated aimbot). Because various types of data can be input into the trained machine learning model 216 to generate the score 118, determining the score 118 can be based at least in part on the sensor data 604, at least in part on the game control data 606, at least in part on determining that the private key matches a private key in the database 116, and / or at least in part on the length of time that the private key 632 has been associated with the user account 120, etc. In some embodiments, the score 118 is a variable normalized to a range of [0, 1]. The confidence score 118 can have a monotonic relationship with the probability that the game control data 606 has been generated by the handheld device 602. The relationship between the score 118 and the actual probability associated with a particular behavior, while monotonic, can be linear or non-linear.

[0114] Thus, process 800 represents a machine learning scoring method in which scores 118 (e.g., trust scores 118) are determined for user accounts 120 that indicate the probability that game control data 606 has been generated by a handheld device 602. Thus, the trust scores 118 generated in process 800 may indicate the probability that a player is engaging in non-cheating behavior by playing the video game 110 using an authentic handheld device 602. Using the machine learning model 216 in this scoring process allows for differentiation between human players and non-human players (e.g., software designed to cheat).

[0115] Figure 9 is a flow chart of an exemplary process 900 for assigning a user account 120 to different matches for a multiplayer video game 110 based on a machine-learned trust score 118 that is related to a probability that game control data 606 has been generated by a handheld device 602. For purposes of discussion, the process 900 is described with reference to the previous figures. Figure 8 and Figure 9 As shown by the page external reference “D” in , process 900 can continue from block 822 of process 800 .

[0116] At 902, for a logged-in user account 120 that has been scored according to process 800, the computing system 106, via the matching component 214, may assign the logged-in user account 120 to an assigned match 218 from a plurality of matches 218, the assignment being based at least in part on the machine learning score 118 generated for and associated with the user account 120. The plurality of matches 218 may include at least one match 218(1) designated for human players, and a second match 218(2) designated for non-human players (such as those using software to synthesize and / or modify game control data 606). As mentioned, any number of matches may be defined such that further subdivisions and additional matches may be assigned to the user account 120 at block 902. For example, the computing system 106, via the matching component 214, may define any suitable number of matches into which the player 102 will be grouped for playing the video game 110 in multiplayer mode based on various factors, including demand, capacity, and other factors that come into play in the matching process.

[0117] As shown in sub-block 904, the assignment of the user account 120 to the assigned match can be based on a threshold score. For example, the matching component 214 can determine that the score 118 associated with the logged-in user account 120 is less than a threshold score, and can assign the logged-in user account 120 to a second match 218 (2) designated for a non-human player based on these scores being less than the threshold score. Similarly, the matching component 214 can determine that the score 118 associated with the logged-in user account 120 is equal to or greater than a threshold score, and can assign the logged-in user account 120 to a first match 218 (1) designated for a human player based on these scores being equal to or greater than the threshold score. However, this is merely one exemplary way to provide match assignments 124, and other techniques are also contemplated. For example, in addition to or as an alternative to using a threshold score, a clustering algorithm or other statistical method can also be used. In an example, the trust score 118 can be used to preferentially match user accounts (players) with "similar" trust scores together. Given the natural tendency of the distribution of trust scores 118 across the plurality of user accounts 120 to be primarily bimodal, grouping trust scores 118 based on a similarity metric (e.g., a distance metric, a variance metric, etc.) may provide similar results as using a threshold score. However, in situations where the pool of matches is small (e.g., players in a small geographic area who want to play a less popular game mode), it may be useful to use a similarity metric to group user accounts together for matchmaking purposes, as this may provide a more granular approach that allows for gradual adjustment of the relative importance of trust scores relative to other matching factors (e.g., skill level). In some embodiments, multiple thresholds may be used to "bucketize" user accounts 120 into multiple different matches.

[0118] As shown in sub-block 906, other factors besides the trust score 118 may be considered in the match assignment at block 902. For example, the match assignment 124 determined at block 902 may be further based on the skill level of the player associated with the logged-in user account, the amount of time the logged-in user account has been waiting to be placed in one of the multiple matches, the geographic region associated with the logged-in user account, and / or other factors.

[0119] As shown in sub-block 908, the assignment operation at block 902 may include a reassignment operation in which a user account 120 currently assigned to a first match 218(1) is reassigned to a second match 218(2), or vice versa. For example, the reassignment at sub-block 908 may include removing the user account 120 from the first match 218 based on the trust score 118 generated for the user account 120, and reassigning the user account 120 to the second match 218. This means that the trust scoring 118 may occur at runtime while the video game is being played, and if the machine-learned trust score 118 predicts that there is a high probability that the player is cheating (e.g., using "auto-aimbot" software), the player may be reassigned mid-game. Thus, while match assignments may be made based on the machine-learned trust score 118 before the multiplayer video game 110 begins, the computing system 106 may regenerate the trust score 118 at any suitable time during the game to determine whether a player is to be reassigned to a different match.

[0120] At 910, the computing system 106 may cause the video game 110 to be executed in the assigned match (e.g., one of the first match 218(1) or the second match 218(2)) for the logged-in user account 120 associated with the client machine 104 used to play the video game 110. For example, the computing system 106 may cause the video game 110 to be executed in the first match 218(1) for the first user account 120(1) associated with the first trust score 118(1), and may cause the video game 110 to be executed in the second match 218(2) for the second user account 120(2) associated with the second trust score 118(2). In a streaming implementation, the video game 110 may be executed on the remote computing system 106 and streamed to the client machine 104 at block 910. In other implementations, the remote computing system 106 may provide control instructions to a client application executing the video game 110 on the client machine 104 to execute the video game 110 in the assigned match.

[0121] Because the machine-learned trust scores 118 are used as a factor in the matchmaking process, an improved gaming experience can be provided to users who wish to play the video game in a multiplayer mode in an intended manner. This is because the techniques and systems described herein can be used to match players (e.g., non-human players) who may be behaving unethically (e.g., by using software to synthesize and / or modify game control data 606 to cheat) and isolate these players from other trustworthy players who may be legitimately playing the video game.

[0122] Although the subject matter has been described in language specific to structural features, it is to be understood that the subject matter defined in the appended claims is not necessarily limited to the specific features described. Rather, the specific features are disclosed as example forms of implementing the claims.

Claims

1. A non-transitory computer-readable medium storing computer-executable instructions that, when executed by one or more processors, result in the performance of operations comprising: receiving game control data and sensor data from a client machine, the game control data and the sensor data associated with a user account registered with a video game service, wherein at least one of the game control data or the sensor data is received as encrypted data; determining private key data associated with a private key used to encrypt the encrypted data, the private key data comprising at least one of: the length of time the private key has been associated with the user account; the number of times the private key has been used with the user account or to log into the user account; and the number of times the private key has been switched between different user accounts; providing the sensor data and the private key data as input to a trained machine learning model; generating a trust score associated with the user account as an output of the trained machine learning model, the trust score being related to a probability that the game control data was generated by a handheld game controller associated with the client machine; assigning the user account to an assigned match among a plurality of matches for playing a video game in a multiplayer mode based at least in part on the trust score, the plurality of matches including at least a first match designated for a human player and a second match designated for a non-human player using software to generate synthesized or modified game control data; as well as Causing execution of the video game in the assigned match for the user account.

2. The non-transitory computer-readable medium of claim 1 , wherein the sensor data comprises raw sensor data generated by one or more physical sensors of the handheld game controller, and wherein the assigned match is the first match designated for the human player.

3. The non-transitory computer-readable medium of claim 1 , the operations further comprising: decrypting the encrypted data; determining that the private key is associated with the user account; as well as determining that the private key matches one of a plurality of private keys maintained in a database, the plurality of private keys associated with a plurality of trusted handheld game controllers, Wherein said generating a trust score associated with said user account is further based on said determining that said private key matches said one of said plurality of private keys.

4. The non-transitory computer-readable medium of claim 1 , wherein the assigning of the user account to one of a plurality of matches for playing a video game in a multiplayer mode comprises: removing the user account from the first match; as well as The user account is reassigned to the second match.

5. A method comprising: receiving, by a computing system, game control data and sensor data from a client machine, wherein the game control data and the sensor data are associated with a user account logged into a video game service, wherein the game control data is to be processed by a video game for controlling aspects of the video game, wherein at least one of the game control data or the sensor data is received as encrypted data; determining private key data associated with a private key used to encrypt the encrypted data, the private key data comprising at least one of: the length of time the private key has been associated with the user account; the number of times the private key has been used with the user account or to log into the user account; and the number of times the private key has been switched between different user accounts; The computing system determines a score associated with the user account by: providing the sensor data and the private key data as input to a trained machine learning model; and generating the score as an output of the trained machine learning model, the score indicating a probability that the game control data has been generated by a handheld device associated with the client machine; assigning the user account to an assigned match among a plurality of matches based at least in part on the score, the assigned match comprising at least one of a first match or a second match; and The computing system causes execution of the video game for the user account in the assigned match. The method of claim 5 , wherein the sensor data comprises raw sensor data generated by one or more physical sensors of the handheld device. 7 . The method of claim 6 , wherein the raw sensor data comprises at least one of raw gyroscope data, raw accelerometer data, or raw capacitive sensor data.

8. The method of claim 6, wherein the handheld device is a handheld game controller.

9. The method according to claim 5, further comprising: Prior to said determining a score associated with said user account: accessing, by the computing system, historical sensor data associated with a sample set of user accounts registered with the video game service, the historical sensor data having been received from client machines along with historical game control data processed by the video game or a different video game to control aspects of the video game or the different video game; when a human player holds and operates the handheld device to generate the historical game control data associated with the user account, marking each user account of the sample set of user accounts with a tag, the tag indicating whether the historical game control data associated with the user account was generated by the handheld device; as well as The historical sensor data is used as training data to train a machine learning model to obtain the trained machine learning model.

10. The method of claim 9, wherein said training the machine learning model comprises setting a weight for at least one feature in a set of features derived from the historical sensor data or parameters internal to the machine learning model.

11. The method of claim 5, wherein determining a score associated with the user account further comprises: providing the game control data as an additional input to the trained machine learning model in addition to providing the sensor data and the private key data as the input to the trained machine learning model, Wherein the score is generated based at least in part on the game control data provided as the additional input to the trained machine learning model.

12. The method according to claim 5, further comprising: decrypting the encrypted data by the computing system; determining, by the computing system, that the private key is associated with the user account; as well as determining, by the computing system, that the private key matches one of a plurality of private keys maintained in a database, the plurality of private keys being associated with a plurality of trusted handheld devices, Wherein the determining of the score associated with the user account is further based on the determining that the private key matches the one of the plurality of private keys.

13. The method of claim 5, wherein assigning the user account to the at least one of the first match or the second match based at least in part on the score comprises determining whether the score satisfies a threshold score.

14. The method according to claim 5, wherein Determination of the score also includes: providing, in addition to the sensor data and the private key data as inputs to the trained machine learning model, wireless communication data as an additional input to the trained machine learning model, the wireless communication data indicating at least one of a wireless signal strength associated with the handheld device or one or more instances of dropped data packets sent from the handheld device, wherein the score is generated based at least in part on the wireless communication data provided as the additional input to the trained machine learning model.

15. A system comprising: one or more processors; and a memory storing computer-executable instructions that, when executed by the one or more processors, cause the system to: receiving game control data and sensor data from a plurality of client machines, wherein the game control data and the sensor data are associated with logged-in user accounts from a plurality of user accounts registered with a video game service, wherein the game control data is to be processed by a video game for controlling one or more aspects of the video game, wherein at least one of the game control data or the sensor data is received as encrypted data; determining private key data associated with a private key used to encrypt the encrypted data, the private key data comprising at least one of: a length of time that the private key has been associated with a corresponding one of the logged-in user accounts; a number of times the private key has been used with or to log into a corresponding one of the logged-in user accounts; and the number of times the private key has been switched between different user accounts; A score for the logged-in user account is determined, wherein each score in the score is determined by: providing the sensor data and the private key data associated with a single user account as input to a trained machine learning model; and generating a score associated with the single user account as an output of the trained machine learning model, the score being related to a probability that the game control data was generated by a handheld device associated with a client machine of the plurality of client machines, the game control data being associated with the single user account; assigning a first subset of the logged-in user accounts to a first match and a second subset of the logged-in user accounts to a second match based at least in part on the scores determined for the logged-in user accounts; and The video game is caused to execute in the first match for the first subset of the logged-in user accounts and in the second match for the second subset of the logged-in user accounts. 16 . The system of claim 15 , wherein the sensor data associated with the first subset of the logged-in user accounts comprises raw sensor data generated by one or more physical sensors of a handheld device.

17. The system of claim 16, wherein the raw sensor data comprises at least one of raw gyroscope data, raw accelerometer data, or raw capacitive sensor data.

18. The system of claim 15, wherein each of the scores is further determined by: providing the game control data associated with the single user account as an additional input to the trained machine learning model in addition to the sensor data and the private key data associated with the single user account, Wherein the score associated with the single user account is generated based at least in part on the game control data associated with the single user account provided as the additional input to the trained machine learning model.

19. The system of claim 15, wherein the computer-executable instructions, when executed by the one or more processors, further cause the system to: decrypting the encrypted data; determining that a private key used to encrypt the encrypted data is associated with one of the logged-in user accounts; and determining that the private key matches one of a plurality of private keys maintained in a database, the plurality of private keys associated with a plurality of trusted handheld devices, A single score associated with the one of the logged-in user accounts is further determined based on determining that the private key matches the one of the plurality of private keys.

20. The system of claim 15, wherein: The individual ones of the scores are further determined by: providing, in addition to the sensor data and the private key data associated with the single user account as the inputs to the trained machine learning model, wireless communication data associated with the single user account as an additional input to the trained machine learning model, the wireless communication data indicating at least one of a wireless signal strength associated with the handheld device or one or more instances of dropped data packets sent from the handheld device, wherein the score associated with the single user account is generated based at least in part on the wireless communication data associated with the single user account provided as the additional input to the trained machine learning model.

Images