U.S. Pat. No. 10,537,809

DETAILED DESCRIPTION

The present specification describes systems and methods for filtering a video game user's match performance data through validation mechanisms, and transmitting and writing the validated, signed performance information to the leaderboard service of the video gaming system. In one embodiment, the present method uses the free computing and/or networking resources of the game device or console and uses it as an intermediary between the validation and leaderboard services. This ensures that the validation mechanism and leaderboard service are not dependent on each other for functionality. That is, if one service is not working, the other can still function. For example, if the leaderboard service is inaccessible or inoperative, the validation service can still validate match data from all the games. In one embodiment, the validation service stores relevant data payloads in the client game console or device until the leaderboard service resumes.

The present specification describes systems and methods for filtering a video game user's loadout data through validation mechanisms, and transmitting and writing the validated, signed performance information to other client devices. In one embodiment, the present method uses the free computing and/or networking resources of the game device or console to transmit loadout data, local to the game device, to a validation server. The validation server analyzes the loadout data to determine if the loadout data is authentic, authorized, and/or has been tampered with. If successfully validated, the loadout data is signed, transmitted back to the originating client, and then transmitted to other client devices. If not successfully validated, the loadout data is flagged and the originating player is prevented from using that loadout data in a gameplay session.

The present specification is directed towards multiple embodiments. The following disclosure is provided in order to enable a person having ordinary skill in the art to practice the invention. Language used in this specification should not be interpreted as a general disavowal of any one specific embodiment or used to limit the claims beyond the meaning of the terms used therein. The general principles defined herein may be applied to other embodiments and applications without departing from the spirit and scope of the invention. Also, the terminology and phraseology used is for the purpose of describing exemplary embodiments and should not be considered limiting. Thus, the present invention is to be accorded the widest scope encompassing numerous alternatives, modifications and equivalents consistent with the principles and features disclosed. For purpose of clarity, details relating to technical material that is known in the technical fields related to the invention have not been described in detail so as not to unnecessarily obscure the present invention.

In the description and claims of the application, each of the words “comprise” “include” and “have”, and forms thereof, are not necessarily limited to members in a list with which the words may be associated. It should be noted herein that any feature or component described in association with a specific embodiment may be used and implemented with any other embodiment unless clearly indicated otherwise.

In the description and claims of the application, the term “leaderboard data” shall mean any data which is representative of a player's performance in one or more games, including, but not limited to, numerical scores, times, number of kills, number of points earned, degree of health, degree of level, degree of skill, degree of power, degree of wealth or other performance measurements.

In the description and claims of the application, the term “loadout data” shall mean any data which is representative of the virtual resources or assets associated with a player's virtual character in a game, including, but not limited to, outfits, weapons, guns, grenades, ammunition, clothing, shields, defenses, powers, health, looks, treasure, or other virtual cosmetic or functional assets.

As used herein, the indefinite articles “a” and “an” mean “at least one” or “one or more” unless the context clearly dictates otherwise. The disclosed inventions are directed to an improvement in computer-related technology, namely allowing video game platforms to generate valid and accurate leaderboard data with a decreased risk of corruption or tampering or to generate valid and accurate loadout data with a decreased risk of corruption or tampering, and thus does not recite an abstract idea or concept. In particular, Applicant's specification discloses specific teachings regarding how the claimed inventions improve the validation of leaderboard data or loadout data and are not simply directed to patenting “validated data”. Accordingly, Applicant's claimed inventions do not preempt all approaches to obtaining validated leaderboard or loadout data and, instead, are directed to an improvement in video gaming technology grounded firmly in a specific way of achieving the desired outcome of having validated leaderboard data. To the extent the claimed inventions are still considered to be “abstract” in nature, it should be appreciated that each of the claim limitations, when viewed as an ordered combination, amount to significantly more than just an abstract idea or concept.

FIG. 1illustrates a gaming system100, in accordance with an embodiment of the present specification. The system100comprises client-server architecture, where one or more game servers105are in communication with one or more client devices110over a network115. Users may access the system100via the client devices110that may include, but not be limited to, personal or desktop computers, laptops, Netbooks, handheld devices such as smartphones, tablets, and PDAs, gaming consoles and/or any other computing platform known to persons of ordinary skill in the art. Although three client devices110are illustrated inFIG. 1, any number of client devices110can be in communication with the one or more game servers105over the network115. The one or more game servers105are responsible for hosting, running, or executing the video game.

The one or more game servers105can be any computing device having one or more processors and one or more computer-readable storage media such as RAM, hard disk or any other optical or magnetic media. The one or more game servers105include a plurality of hardware, software, and/or firmware components operating together to provide or implement a plurality of functional, operational or service-oriented modules. In some embodiments, the one or more game servers105include or are in communication with a game database system135. The game database system135stores a plurality of game data associated with at least one game that is served or provided to the client devices110over the network115. In one embodiment, the game database system135comprises a plurality of databases, each storing a different kind of data. For example, data associated with leaderboard or gameplay results may be stored in a different database, while error reports associated with a game may be stored in a different database. In some embodiments, the one or more game servers105may be implemented by a cloud of computing platforms operating together as game servers105. In embodiments, the game server is another home console, a personal computing device, such as a laptop or tablet PC, or a dedicated server.

In accordance with aspects of the present specification, the one or more game servers105provide or implement a plurality of modules such as, but not limited to, a master game module120, a validation module125and a master leaderboard module130. In one embodiment, the validation module125and the master leaderboard module130are hosted on a cloud of computing platforms, collectively known as the backend. In the following description, the terms ‘game server’ and ‘backend’ are used interchangeably. In some embodiments, the one or more client devices110are configured to implement or execute one or more of the plurality of modules that are the same as or similar to the modules of the one or more game servers105. For example, in some embodiments the client devices110execute a client-side game module120′.

It should be appreciated that the term ‘module’ refers to computer logic utilized to provide a desired functionality, service or operation. In various embodiments, a module can be implemented in hardware, firmware and/or software controlling a general purpose processor. In one embodiment, the modules are programmatic codes or computer executable instructions stored on a storage system, such as the game database system135, and executed by a processor. It should further be appreciated that the terms “service”, “procedure”, or “method” refer to processes that are implemented by server engines which are specific programmatic structures implemented in either software or hardware. Accordingly, a validation service may be alternatively referred to as a validation server implemented in a form of a plurality of programmatic instructions stored in a non-transient memory and executed by one or more processors.

In embodiments, the master game module120is configured to execute an instance of an online game to facilitate interaction of the users with the game. In embodiments, the instance of the game executed may be synchronous, asynchronous, and/or semi-synchronous. The master game module120controls aspects of the game for all users and receives and processes each user's input in the game. For example, the master game module120may host the online game for users of a particular game, receive game data from the client devices110and transmit updates to client devices110based on the received game data so that the game, on each of the client devices110, represents the most updated or current status with reference to interactions of all users with the game. Thus, the master game module120transmits the game data over the network115to the client devices110for use by the game module120′ at the client devices110to provide local versions and current status of the game to the users.

On the client-side, each of the one or more client devices110implements the game module120′ that operates as a gaming application to provide a user with an interface between the user and the game. The game module120′ generates the interface to render a virtual environment, virtual space or virtual world associated with the game and enables the user to interact in the virtual environment to perform a plurality of game tasks and objectives. The game module120′ accesses game data received from the game server105to provide an accurate representation of the game to the user. The game module120′ captures and processes user inputs and interactions within the virtual environment and provides updates to the game server105over the network115. In embodiments, the game module120′ captures and stores a plurality of statistical data or leaderboard data generated as a result of the user's interactions with the virtual environment of the game. The captured and stored leaderboard data is communicated back to or uploaded to the game server105in real-time, periodically (such as through batch updates) during a game and/or at an end of the game. The game module120′ accesses updated or most current leaderboard data from the game server105and presents or displays the accessed leaderboard data via one or more leaderboard GUIs (Graphical User Interface) to the user.

The game server105is preferably configured to concurrently communicate with at least 20 client devices, and more preferably 20 to 1,000,000 client devices or any increment therein, such that each of said at least 20 client devices are permitted to concurrently upload leaderboard data to the game server. In another embodiment, the game server is configured to concurrently host at least 5 leaderboard data transactions per second, preferably 50-150 leaderboard data transactions per second, with the plurality of client devices.

FIGS. 2a, 2band 2care a series of figures that illustrate the data flow between various components ofFIG. 1. Referring toFIG. 2a, the data flow between a game client201and a game server202is shown. As explained above, a game client comprises a user's home console, personal computer, mobile device or smartphone or any other computing platform capable of being connected to the internet and capable of rendering a video game to be played by the user. During gameplay, the game client201communicates with at least one game server202, which may be a dedicated server or another home based console or computing device, or a computing platform hosted on cloud. In accordance with aspects of the present specification, a plurality of game data is communicated between the client device201and the game server202. This data may be broadly categorized into a first set of data referred to as game-rendering data and a second set of data referred to as leaderboard data. The game-rendering data is associated with accurate rendering, execution or implementation of the online game to all users on their corresponding client devices. In embodiments, the game-rendering data comprises data such as, but not limited to:

a) Data associated with successful and accurate generation of a virtual environment or simulation space of the game. For example, audio-visual and/or graphics data necessary to render the virtual environment on a display screen of the client devices201and virtual objects or virtual elements data such as the various types, objectives and behaviors of virtual elements, objects and characters associated with the game;

b) Game target data including data related to the current game targets, goals or objectives as well as data related to the past, present and future status of the targets, goals or objectives of the game;

c) Data related to the users or players of the game. For example, user's identification data (such as a unique login or username and password), user's geographical location data (such as an IP address of the client device of the user), user's experience level or expertize with reference to playing the game, user's preferences, user-controlled virtual character or avatar and its permissible behaviors as well as customizations at various levels of the game, current number of users; and,

d) Game identification data related to identification of an instance of the game being played by the users including the timestamp related to when a particular game instance was played by a particular user.

The leaderboard data is associated with a plurality of user related metrics, scoring or statistics and/or in-game event data generated as a result of the user's interactions with the virtual environment of the game. In embodiments, the leaderboard data comprises data such as, but not limited to:

a) Data related to a plurality of scoring events that occur during a match. For example, high scores, kills or captures, fastest time periods to achieve certain scores, clearing or achieving specific game levels and/or win specific matches by a set of ‘N’ number of top performing users, ranking of the user with reference to the top ‘N’ users; and,

b) Data associated with in-game events such as, but not limited to, movement of the user throughout the virtual environment or topographical map of the game, interaction of the user's avatar with various virtual characters or elements in the game, virtual elements or items used and/or won, damage taken, perks acquired.

It should be appreciated that the leaderboard data will vary depending upon the type, nature and objectives of the game and therefore encompasses any gameplay data relevant to and defined for a particular type of game and its objectives.

In the present specification, the leaderboard data may be referred to as a) client-side or user-specific leaderboard data generated and stored at the client device201(as a result of a user playing a game) and communicated back or uploaded to at least one game server202or backend, and b) master leaderboard data stored at a game server202or backend as a result of processing of leaderboard data received from all client devices of all users. The master leaderboard data is updated with client-side leaderboard data received from all client devices and therefore is representative of comprehensive leaderboard data encompassing the results of all users' interactions with the virtual environment of the game.

FIG. 2billustrates the flow of data between a validation service213of the gaming system and a game client211. Referring toFIG. 2bin conjunction withFIG. 1, the validation service213is implemented via a validation module125running on a game server or backend of the gaming system. In embodiments, the validation service213is configured to receive client-side leaderboard data generated at a client device211and validate the received leaderboard data. In the embodiment ofFIG. 2b, the game client211reports the user's results after a game, which comprise the client-side leaderboard data, directly to the validation service213. In one embodiment, this data is received by the validation service directly from the game modules120′ (shown inFIG. 1) of the client devices110. In alternate embodiments, the client-side leaderboard data is accessed from the master game module120that in turn receives the client-side leaderboard data from the game modules120′ of the client devices110.

Still referring toFIG. 2b, in accordance with a further aspect of the present specification, the validation service213processes and analyzes the client-side leaderboard data to determine if the client-side leaderboard data is valid, legitimate, authentic or bona fide and has not been manipulated, altered or tampered with at the client device211and/or during transmission from the client device211to the backend. In various embodiments, the validation service213applies at least one of a plurality of validation procedures or validation methods to the client-side leaderboard data to determine if the data has been manipulated in any way. In some embodiments, the plurality of validation methods are software programmatic instructions stored in the game database system, or in one or more computer-readable storage media of the game servers, in other embodiments.

It should be appreciated that the plurality of validation methods are aimed or directed towards ensuring that the client-side leaderboard data is logical. For example, the plurality of validation methods check data time stamps, look for negative values, impossible values, and corrupt match data. In other words, the plurality of validation methods process the client-side leaderboard data for clues or indications to determine if the data has been modified, such as by a human, and if the data did not come directly from the game itself.

It would be evident to persons of ordinary skill in the art that the plurality of validation methods will vary depending upon the type, nature and objectives of a game and therefore the different types of metrics, points, scoring or statistics and/or in-game event data forming the client-side leaderboard data. The validation methods will also programmatically receive data from a client device and subject it to a plurality of programmatic routines to examine or compare the value of the received data against one or more other data stored in local or remote memory by accessing a memory address of the stored predetermined values, or acceptable values, and performing a programmatic comparison of the received results data with the stored predetermined values.

In accordance with non-limiting examples the plurality of validation procedures or methods may comprise (to determine if data has been tampered with): checking that the score, points or achievements of a team or a single user (player) does not exceed a predefined threshold; checking that an increase in a level of a team or player does not exceed a predefined threshold; checking that rewards, such as money, earned by a team or player does not exceed a predefined threshold; in an exemplary racing game, checking that the race is not completed under a minimum threshold time; checking that a number of virtual elements or items gained by a team or player does not exceed a predefined threshold; and/or checking for occurrences of unlikely or impossible in-game events. For example, but not limited to such examples, tampered gameplay and/or data may be in the form of a player in a basketball game making baskets from beyond a certain predetermined distance from a hoop; a player in a FPS shooting an enemy from beyond a certain predetermined distance; a player moving around the topographical map or virtual map in impossible ways (e.g., “teleports”), or a player or vehicle appears to have unlimited ammunition, health, armor or any other types of virtual elements relevant to the game.

In one embodiment, the limits or thresholds verified by the validation procedures for a game are based on those set by the developer for the particular game. In some embodiments, data regarding limits and thresholds for game metrics are stored in a table in the database associated with the game server, from where it can be accessed by the validation service. One of ordinary skill in the art would appreciate that the applicable limits and thresholds can change depending on the situation, type of game, level of game and the like. In one embodiment, the stored limits and thresholds are continually updated by the game server in the associated database.

If the validation service213detects any evidence of tampering within the client side leaderboard data using any of the validation mechanisms it encompasses, as described above, the service discards the tampered gameplay results that were reported. Further, in one embodiment, the failure or rejection of results is recorded and the results that failed the validation tests are stored in a game database214for further analysis. Such data stored for analysis may include information such as user ID, console or device ID on which the game was played, device OS details, game version, gameplay or match duration and timestamp, and the detailed statistics generated from the game play.

If the client side leaderboard data successfully pass the validation tests, the validation service213encrypts the game results and transmits a signed payload of results back to the game client211. It may be appreciated that the game client211acts as an intermediary between the validation service213and the leaderboards service, which are both hosted at the backend of the gaming system. Therefore, the client side leaderboard data, after successful validation is encrypted in a manner such that it cannot be tampered with by the user at the game client211. Exemplary algorithms that may be used to encrypt and/or sign information payloads before transmission from the validation service or module to the game client include JOSE JWS Signing (HMAC using SHA-256 hash algorithm); Public Key Encryption; and other encryption methods known in the art that may be employed for the purpose, so long as they serve the purpose of securing the data such that it cannot be tampered with at the client end.

FIG. 2cillustrates the flow of data between a leaderboard service223of the gaming system and a game client221. Referring toFIG. 2c, after receiving the signed payload of results from the validation service, the client device221transmits the results to the leaderboard service223. In one embodiment, the leaderboard service223is implemented by means of a leaderboard module130(shown inFIG. 1) running on a game server105or backend of the gaming system. The leaderboard data, as explained earlier, comprises relevant statistical data for games that is recorded by leaderboards. Examples of such data include, but are not limited to, number of wins, losses, kills, deaths, duration of game play, and/or levels achieved. It may be appreciated that leaderboard data in the context of the present specification encompasses any data relevant to a leaderboard for any genre of any game.

The leaderboard data which has been validated by the validation service as being untampered, is sent as an encrypted payload of information to the client device, which, in turn, uploads it to the leaderboard service223. The signed payload of information is encrypted in manner such that it can be read or decrypted by only the leaderboard service223. Upon receiving the signed payload from the client221, the leaderboard service223attempts to decrypt the payload. If the leaderboard service223fails to decrypt the payload, the data is deemed as invalid or as having been tampered with. In this case, the payload of gameplay results is discarded. Further, in one embodiment, the failure or rejection of payload is recorded and the payload that failed decryption at the leaderboard service223is stored in a game database224for further analysis. If the leaderboard service223succeeds in decrypting the signed payload of information, the decrypted game results are transmitted to another database225to be recorded in the game leaderboard. One of ordinary skill in the art would appreciate that the same encryption algorithms that are used by the validation service for encrypting the results and creating a signed payload, are used by the leaderboard service223to decrypt the payload of results. In one embodiment, the signed payload also contains specific information or data that can be only read by the leaderboard service223and used for decrypting the statistical information in the payload.

An image of the successfully recorded leaderboard results is subsequently rendered via a GUI on a display associated with the client device. An exemplary leaderboard image300is illustrated inFIG. 3.

It may be noted that the validation and leaderboard services, as per the embodiments of the present specification, are distinct services. By obtaining the results from the client device, validating the results and returning a signed payload back to the client device, before it is sent to the leaderboard service, the two services remain independent and do not depend on each other for functionality or operation. In other words, if the leaderboard service is not working or functional, the game results can still be validated. Further, the validated results may be uploaded to the leaderboard service whenever the network and computing environment at both the client end and the game backend are conducive. This feature also takes advantage of the free computing power at a client device, such as a game console's free computing power, and avoids bottleneck problems encountered in networks. This leads to improved speed for users playing the video game and enhanced scalability for game makers.

FIG. 4is a flowchart illustrating a method of validating leaderboard data, in accordance with an embodiment of the present specification. Referring toFIG. 4, in the first step401, a game or match is completed by the user at a client device, such as a game console, computer or a mobile device. In the next step402, the client device uploads the match data and game results to the validation service running at the server end or backend of the gaming system. Validation mechanisms are run on the reported match data and results in step403, and a check is performed for invalid results in step404. If either or both of invalid results or data tampering are detected, the results are rejected, as shown in step405. If the data is found to be valid and untampered, the validation service returns a signed payload to the client device, in step406. The signed payload comprises the match results and game statistics in encrypted form. In the next step407, the game client uploads the signed payload to the leaderboard service. This step may be executed after the completion of each match, when the validated payload is received, or it may be scheduled for later if the network conditions are not conducive to the transfer. Thereafter, in step408, the leaderboard service examines the signed payload to check if the data is valid and attempts to decrypt the data in the payload. If the leaderboard service is successful in decrypting the signed payload, the relevant results are committed to the memory or database associated with the game leaderboards, as shown in step409. Otherwise, as shown in step405, the results are rejected. Optionally, the results rejected by the validation service or the leaderboard service are recorded in a separate database, to be analyzed later by game developers.

FIG. 5illustrates a gaming system500, in accordance with another embodiment of the present specification. System500comprises client-server architecture, where one or more game servers505are in communication with one or more client devices510over a network515. Users may access system500via client devices510that may include, but not be limited to, personal or desktop computers, laptops, Netbooks, handheld devices such as smartphones, tablets, and PDAs, gaming consoles and/or any other computing platform known to persons of ordinary skill in the art. Although three client devices510are illustrated inFIG. 5, any number of client devices510can be in communication with the one or more game servers505over network515. Each server505is responsible for hosting, running, or executing video games played by users of client devices510.

Server505can be any computing device having one or more processors and one or more computer-readable storage media such as RAM, hard disk or any other optical or magnetic media. Server505includes a plurality of hardware, software, and/or firmware components operating together to provide or implement a plurality of functional, operational or service-oriented modules. In some embodiments, server505includes or is in communication with a game database system535. Game database system535stores a plurality of game data associated with at least one game that is served or provided to client devices510. In one embodiment, game database system535comprises a plurality of databases, each storing a different kind of data. For example, one database may include data related to known attributes of each player's character. Those known attributes may have been gathered based upon what a player has purchased in the marketplace, or based on prior uploads of data from completed games, or any other. More specifically, such a database may comprise data representative of the virtual resources or assets associated with a player's virtual character in a game, including, but not limited to, outfits, weapons, guns, grenades, ammunition, clothing, shields, defenses, powers, health, looks, treasure, or other virtual cosmetic or functional assets. Another database may include data related to error reports or flagged data associated with a game or a player. In some embodiments, server505may be implemented by a cloud of computing platforms operating together as game servers505. In embodiments, server505is another home console, a personal computing device, such as a laptop or tablet PC, or a dedicated server.

In accordance with aspects of the present specification, server505includes a plurality of modules such as, but not limited to, a master game module520a, and a validation module525. In one embodiment, validation module525is hosted on cloud of computing platforms, collectively known as the backend. In the following description, the terms ‘game server’ and ‘backend’ are used interchangeably. In some embodiments, client devices110are configured to implement or execute one or more of the plurality of modules that are the same as or similar to the modules of the one or more game servers505. For example, in some embodiments the client devices110execute a client-side game module520b.

It should be appreciated that the term ‘module’ refers to computer logic utilized to provide a desired functionality, service or operation. In various embodiments, a module can be implemented in hardware, firmware and/or software controlling a general purpose processor. In one embodiment, the modules are programmatic codes or computer executable instructions stored on a storage system, such as the game database system535, and executed by a processor.

In embodiments, master game module520ais configured to execute an instance of an online game to facilitate interaction of the users with the game. In embodiments, the instance of the game executed may be synchronous, asynchronous, and/or semi-synchronous. Master game module520acontrols aspects of the game for all users and receives and processes each user's input in the game. For example, master game module520amay host the online game for users of a particular game, receive game data from client devices510and transmit updates to client devices510based on the received game data so that the game, on each of the client devices510, represents the most updated or current status with reference to interactions of all users with the game. Thus, master game module520atransmits the game data over network515to client devices510for use by the game module520bat client devices510to provide local versions and current status of the game to the users.

On the client-side, each client device510implements game module520bthat operates as a gaming application to provide their users with an interface with the game. Game module520bgenerates the interface to render a virtual environment, virtual space, or virtual world associated with the game and enables the user to interact in the virtual environment to perform a plurality of game tasks and objectives. Game module520baccesses game data received from game server505to provide an accurate representation of the game to the user. Game module520bcaptures and processes user inputs and interactions within the virtual environment and provides updates to game server505. In embodiments, game module520bcaptures and stores a plurality of loadout data generated by a user. The captured and stored loadout data is stored in the local client device and also optionally communicated back to, or uploaded to, the game server505in real-time, periodically (such as through batch updates) during a game, and/or at the end of the game. Game module520bof a second client device510accesses the updated, or most current loadout data of a first client device510, from either the game server505or directly from the first client device510without going through the game server505.

FIG. 6is a flow chart illustrating another method for validating data, in accordance with some embodiments of the present specification. Referring to elements described in context ofFIG. 5, during gameplay, a client device510communicates with at least one server505, which may be a dedicated server or another home based console or computing device, or a computing platform hosted on cloud. In one embodiment, the server executes a backend validation service. In accordance with aspects of the present specification, a plurality of loadout data is communicated between the client device and the server. Conventionally, when playing a multiplayer game, loadouts are transmitted from one client device to the client devices of other players so the character may be properly represented in the gaming environment of other players. In embodiments of the present specification, at step602, the player's loadout is transmitted from the client device and is received by a backend validation service (for example, a service executed by validation module525) executed by the server in communication with the client device.

At step604, the validation service compares data in the loadout to a database535, which includes known attributes of the player's character. Validation of data is performed to establish that the data is correct. In some embodiments, those known attributes are gathered based upon what the player has purchased in the marketplace, based on prior uploads of data from completed games, or any other activity performed by the player. If the comparison validates all the data in the loadout, at step606, it generates an authenticated loadout data element. The validation service does so by applying, or associating, a digital signature with the loadout data set. The digital signature validates that the data in the loadout is authentic and was not altered, tampered with, or otherwise unauthorized.

One of ordinary skill in the art would appreciate that any method of creating and attaching a digital signature, or electronic validation, to loadout data may be used. In embodiments, asymmetric cryptography is used to generate the signature for validating the loadout data. Client side loadout data, after successful validation, may be encrypted in a manner such that it cannot be tampered with by the player at the client device. Exemplary algorithms that may be used to encrypt and/or sign information payloads before transmission from the validation service to the client device include JOSE JWS Signing (HMAC using SHA-256 hash algorithm), Public Key Encryption, and other encryption methods known in the art that may be employed for the purpose, so long as they serve the purpose of securing the data such that it cannot be tampered with at the client end.

At step608, the server transmits the authenticated, digitally signed loadout data element back to the client device. The client device then transmits the authenticated, digitally signed loadout to other client devices of other players, thus enabling other players to have confidence that each players loadout represents a valid, authenticated, and proper set of resources legitimately obtained in the course of gameplay and not the result of hacking or cheating.

If the comparison at604does not validate the data, the loadout is not signed, and instead, at step610, the loadout is flagged as being possibly corrupted and the player is unable to play with that character or using that specific loadout.

It may be appreciated that the present system and method reduces interconnection dependencies between backend services and can be used to securely send encrypted data between backend services through client machines. Thus, the use of the present method and system may be extended to other services running at the backend of a gaming system as well. For example, the present method may be applied to transmitting information to the rewards service of the game system as well. As known in the art, many video games include rewards that may be earned depending on achievement of certain in-match performance milestones. These rewards include various virtual objects, assets or abilities that may be used to enhance the gameplay experience and/or the performance of a user. In one embodiment, the system of present specification may be applied to have such performance milestones reported to the validation service from the client device. After ensuring the validity of the milestone data, the validation service may sign the data payload and forward it to the rewards service, either directly or via the client device. The reward service may then use the performance milestone data to generate appropriate rewards for the user.

The above examples are merely illustrative of the many applications of the methods and systems of present specification. Although only a few embodiments of the present invention have been described herein, it should be understood that the present invention might be embodied in many other specific forms without departing from the spirit or scope of the invention. Therefore, the present examples and embodiments are to be considered as illustrative and not restrictive, and the invention may be modified within the scope of the appended claims.