U.S. Pat. No. 11,951,400

DETAILED DESCRIPTION

Multiple video game consoles each store a blockchain ledger with multiple blocks, which is either associated with a particular video game or with a the particular type of video game console that the video game consoles are each characterized by. One of the consoles receives a message identifying an intended transaction corresponding to transfer of an identified quantity of an in-game virtual asset from a transferor account to a transferee account. The console verifies that the intended transaction is valid and generates a new block that includes the transaction, optionally one or more additional verified intended transactions, and a block header that includes a hash of a header of a most recent block in the blockchain ledger (or alternately/additionally a hash of the entire most recent block). The console appends the new block to the blockchain ledger and transmits it to the other consoles, which each also append the new block to their copy of the blockchain ledger, thereby completing the transaction.

FIG.1Aillustrates a network environment through which a distributed blockchain ledger is kept on a per-game basis.

The network environment ofFIG.1Aincludes three client devices110—specifically, a first client device110A, a second client device110B, and a third client device110C. Each of the three client devices110ofFIG.1Astore a video game A120A and a video-game-A-specific blockchain ledger125A.

Each of the three client devices110ofFIG.1Ais a particular type of video game console that is compatible with video game A120A and optionally a number of other video games. The particular type of video game console include one or more computing devices800as illustrated in or discussed with respect toFIG.8, or may include at least a subset of the components of one or more computing devices800.

The network environment ofFIG.1Aoptionally includes network hardware105, which may include one or more routers, servers, gateways, network bridges, modems, wireless access points, networking cables, line drivers, switches, hubs, repeaters, or combinations thereof.

The first client device110A and second client device110B can communicate via communication path160. The second client device110B and third client device110C can communicate via communication path165. The first client device110A and third client device110C can communicate via communication path170. Each of the communication paths160,165, and170may be direct communications from one client device110to another client device110or may optionally pass through the network hardware105. Each of the communication paths160,165, and170may pass through the public Internet, be confined to a local area network (LAN) that is wireless or wired or some combination thereof, or be confined to a personal area network (PAN) that is wireless or wired or some combination thereof.

A blockchain ledger comprises a digital ledger shared across public or private peer-to-peer networks. These digital ledgers are tamper proof and record transactions where a transferor sends a virtual asset to a transferee. The ledgers, which are distributed to all the nodes in the network, permanently store a validated history of transactions that take place across all of the peers in the network via a process illustrated in and discussed with respect toFIG.4.

The blockchain ledger includes multiple blocks that each identify one or more transactions and also reference the previous block in the blockchain, for example by including a hash of the header of the previous block in the blockchain in a header of each block as illustrated in and described with respect toFIG.3. Including the hash of the header of the previous block secures the blockchain ledger by preventing modification of any block of the blockchain after the block has been entered into the blockchain, as any change to a particular block would cause that block's hash in the next block to be incorrect. Further, modification of that block's hash in the next block would make the next block's hash in the block after the next block incorrect, and so forth.

A Merkle root of the one or more transactions of the block may be generated using the same or a different hash algorithm as illustrated in and discussed with respect toFIG.5, to prevent modification of the transactions in a new block.

The hashes of previous block and the Merkle root hashes are generated using a hash algorithm, which may optionally be a secure hash algorithm (SHA), such as SHA-0, SHA-1, SHA-2, SHA-3, SHA-N, SHA-128, SHA-192, SHA-256, SHA-512, SHA-224, SHA-384, SHA-512/224, SHA-512/256, SHA3-224, SHA3-256, SHA3-384, SHA3-512, SHAKE128, or one or more variants or combinations thereof.

The game-specific blockchain ledger125A ofFIG.1Ais specific to the video game A120A. That is, the game-specific blockchain ledger125A ofFIG.1Astores transactions of in-game virtual assets involving the video game A120A. In-game virtual assets involving the video game A120A may be defined as virtual assets that are earned during gameplay of the video game A120A, acquired in exchange for an in-game virtual currency within the video game A120A, purchased or otherwise acquired via in-app purchase (IAP) or downloadable content (DLC) through the video game A120A, usable to modify gameplay of the video game A120A, or a combination thereof. The game-specific blockchain125A may be limited to only identifying/listing/tracking transactions of in-game virtual assets involving the video game A120A, or may in some cases identify/list/track other types of transactions, such as purchases or transfers of copies of the video game A120A itself, transactions involving purchase or use of gift cards or other virtual currencies tied to a video game platform rather than the individual video game A120A, transactions of in-game virtual assets involving games related to the video game A120A such as sequels or prequels, or a combination thereof.

The game-specific blockchain ledger125A ofFIG.1Amay in some cases be stored and/or maintained only by client devices110/user accounts that store/possess a copy of the video game A120A, client devices110/user accounts that are authorized to access a copy of the video game A120A, client devices110/user accounts that are authorized to run a copy of the video game A120A, client devices110/user accounts that have run a copy of the video game A120A at least a predetermined number of times (e.g., at least once), or a combination thereof.

In such cases, a “miner” client device110such as the one discussed with respect to steps420and425ofFIG.4may verify that the transaction is valid in part by verifying that the transferor account stores/possesses a copy of the video game A120A, is authorized to access a copy of the video game A120A, is authorized to run a copy of the video game A120A, has run a copy of the video game A120A at least a predetermined number of times, or a combination thereof. Such a “miner” client device110may verify that the transaction is valid in part by verifying that the transferee account stores/possesses a copy of the video game A120A, is authorized to access a copy of the video game A120A, is authorized to run a copy of the video game A120A, has run a copy of the video game A120A at least a predetermined number of times, or a combination thereof. Finally, such a “miner” client device110, in some cases, is only allowed to participate in verifying the transaction if the “miner” client device110and/or a user account associated with the “miner” client device110stores/possesses a copy of the video game A120A, is authorized to access a copy of the video game A120A, is authorized to run a copy of the video game A120A, has run a copy of the video game A120A at least a predetermined number of times, or a combination thereof.

Different game-specific blockchain ledgers125may be generated to correspond to different games as visible with the game-specific blockchain ledgers125B that corresponds to the Video Game B120B ofFIG.1C. Each game-specific blockchain ledger125may be a ledger for any type of transaction identified inFIGS.2A-2F, or may alternately be limited to a subset of those types of transactions.

FIG.1Billustrates a network environment through which a distributed blockchain ledger is kept on a platform-wide basis.

The platform-specific blockchain ledger115ofFIG.1Bis similar to the game-specific blockchain ledger12ofFIG.1A, but it may identify transactions associated with multiple games that run on a particular video game platform. For instance, inFIG.1B, client devices110D and110F stores Video Game A120A, but client device110E instead stores Video Game B120B. Despite this, client devices110D,110E, and110F all store the platform blockchain115because Video Game A120A and Video Game B120B are both compatible with the same video game platform, which encompasses client devices110D,110E, and110F. A video game platform as discussed herein may include multiple instances of a particular type of video game console, optionally along with associated network hardware105.

For example, a platform-specific blockchain ledger115may be stored on and managed by multiple Playstation® 4 console systems, which in the context ofFIG.1B, would be client devices110. The platform-specific blockchain ledger115may optionally be stored on and managed by servers (which may also be client devices100in the context ofFIG.1B) and other network hardware105running a network service associated with Playstation® 4 console systems, such as the Playstation® Plus online network service for Playstation® 4. Other types of client devices100, such as older Playstation® 3 console systems or portable Playstation® Vita portable console systems, might be specifically excluded from participation in the platform-specific blockchain ledger115ofFIG.1B, and might instead store and manage their own separate respective platform-specific blockchain ledgers115. A platform-specific blockchain ledger115may additionally encompass and/or be limited to certain client devices100of certain brand(s) or manufacturer(s), such as Sony® client devices100, Playstation® home and/or portable consoles that support blockchain ledger functionality, client devices100that support the Playstation® Plus online network service, or a combination thereof. A platform-specific blockchain ledger115may additionally encompass and/or be limited to certain client devices100based on location or purchase method, such as client devices100sold at a particular store type, client devices100sold at a particular store location, client devices100purchased online generally, client devices100purchased online through a specific website, client devices100located in a particular region, client devices100purchased/sold in a particular region, or a combination thereof. Regions may be defined by country, city, county, state, continent, electoral district, other pre-defined borders, or a combination thereof.

A platform-specific blockchain ledger115may explicitly exclude certain types of client devices100. For example, a platform-specific blockchain ledger115may exclude a category of devices, such as portable video game console devices or home video game console devices. A platform-specific blockchain ledger115may additionally exclude client devices100of certain brand(s) or manufacturer(s), such as Nintendo® or Microsoft® video game console client devices100, client devices100that are too old to support blockchain ledger functionality or otherwise do not support blockchain ledger functionality, client devices100that do not have access to or do not support access to a particular online network service such as the Playstation® Plus online network service, or a combination thereof. A platform-specific blockchain ledger115may additionally exclude certain client devices100based on location or purchase method, such as client devices100sold at a particular store type, client devices100sold at a particular store location, client devices100purchased online generally, client devices100purchased online through a specific website, client devices100located in a particular region, client devices100purchased/sold in a particular region, or a combination thereof. Regions may be defined by country, city, county, state, continent, electoral district, other pre-defined borders, or a combination thereof.

It should be noted that the paragraphs above identifying which client devices100may be included in or excluded from participation in or storage of the blockchain ledger115may also apply to game-specific blockchain ledgers125. Participation in this context may concern participation as a transferor, participation as a transferee, participation as a miner/verifier, participation as a client device100that simply stores at least a portion of the blockchain ledger125/115, or a combination thereof.

In such cases, a “miner” client device110such as the one discussed with respect to steps420and425ofFIG.4may verify that the transaction is valid in part by verifying that the transferor account and/or a client device100associated with the transferor account is permitted to use/access the platform as discussed above, by verifying that the transferee account and/or a client device100associated with the transferee account is permitted to use/access the platform as discussed above, by verifying that the “miner” client device110and/or a user account associated with the “miner” client device110is permitted to use/access the platform as discussed above, or a combination thereof.

Platform-specific blockchain ledgers115may store/manage the same types of transactions as discussed with respect to game-specific blockchain ledgers125. Platform-specific blockchain ledgers115may in some cases, however, be limited to transactions of virtual assets other than in-game assets specific to games that already have game-specific blockchain ledgers125. For example, if client device100detects that Video Game A120A uses a corresponding game-specific blockchain ledger125A, it may store and manage transactions for Video Game A120A using the game-specific blockchain ledger125A instead of using the platform-specific blockchain ledger115. If client device100detects that Video Game C120C does not have a corresponding game-specific blockchain ledger125C, it may store and manage transactions for Video Game C120C using the platform-specific blockchain ledger115. Platform-specific blockchain ledger115may also be used to virtual asset transactions for virtual assets that don't concern any specific video game but instead concern the video game platform, such as purchase or transfer of a video game, purchase or transfer of a service such as online multiplayer, purchase or transfer of media such as music or movies to play via the client device100, purchase or transfer of a gift card or credits acquired through the platform rather than through any individual game, or combinations thereof.

FIG.1Cillustrates a network environment through which different types of distributed blockchain ledgers are kept and managed via a platform management server.

The network environment ofFIG.1Cincludes client devices110A and110B ofFIG.1Aas well as client devices110D and110E ofFIG.1B. The network environment ofFIG.1Calso includes one or more platform management servers150and one or more entitlement servers140. References further herein to a single platform management server150or a single entitlement server140should be understood to alternately refer to multiple single platform management servers150or multiple entitlement servers140, respectively. Some servers may optionally serve as both platform management server(s)150and entitlement server(s)140.

Each platform management server150includes one or more blockchain ledgers, including game-specific blockchain ledgers125and/or platform-specific blockchain ledgers115. For example, the platform management server(s)150ofFIG.1Cstores a game-specific blockchain ledger125A corresponding to video game A120A, a game-specific blockchain ledger125B corresponding to video game B120B, and a platform-specific blockchain ledger115. These ledgers function as illustrated and described with respect toFIG.1AandFIG.1B, respectively.

The platform management server150ofFIG.1Calso includes application programming interfaces (APIs)130/135corresponding to the blockchain ledgers115/125.

Specifically, a game-callable blockchain ledger API130can be called by an operating system, video game, or other software running on client devices110A and110B to implement functionality of a game-centric blockchain ledger125, such as game-centric blockchain ledgers125A and125B ofFIG.1C. The game-callable API130allows game-centric blockchain ledgers125to operate in a standardized way between different client devices110, and allows updates to be instantaneous. It also provides a degree of control and centralization for a party, such as a manufacturer or developer of the client devices110, to adjust and control certain aspects of each game-centric blockchain ledger125. Such control and centralization would typically otherwise be forfeited due to the decentralization that is the focus of blockchain technologies.

Similarly, a platform-callable blockchain ledger API135can be called by an operating system, video game, or other software running on client devices110D and110E to implement functionality of a platform-centric blockchain ledger115ofFIG.1C. The platform-callable API115allows one or more platform-centric blockchain ledgers115to operate in a standardized way between different client devices110, and allows updates to be instantaneous. It also provides a degree of control and centralization for a party, such as a manufacturer or developer of the client devices110, to adjust and control certain aspects of each platform-centric blockchain ledger115. Such control and centralization would typically otherwise be forfeited due to the decentralization that is the focus of blockchain technologies.

An entitlement server140may be a server associated with a developer, publisher, manufacturer, social media influencer, or other entity associated with the client devices110or with particular video games120. An entitlement server140may be associated with certain “entitlements,” such as discounts, coupons, promotions, multiplayer game tournament awards, rewards for certain game achievements, or combinations thereof. “Entitlements” can alternately or additionally define ownership or rental of digital content like subscriptions, games, gift cards/tokens, movies, and TV shows. When a user purchases, rents, receives as a gift, or otherwise acquires an item, a game, a gift card/token, a video, or a subscription to a service or to any of the above, that user can gain an entitlement. These entitlements may likewise be transferred via blockchain ledgers. InFIG.1C, an entitlement server140is illustrated as calling the platform-callable API135to use the platform-specific blockchain ledger115, but it can optionally call the game-callable API130to use a game-specific blockchain ledger130instead or additionally.

For example, a game publisher may acquire one hundred 10% discount coupons in exchange for publishing a particular video game120via the platform to be played by client devices110of a specific type, optionally via platform management server(s)150. These one hundred 10% discount coupons might be tied to one or more user accounts associated with the publisher and/or to the specific hardware of one or more entitlement server(s)140associated with the publisher. The publisher might give out 40 of its coupons to user accounts/client device100associated with players that win tournaments. The publisher might give out 30 of its coupons to user accounts/client device100/entitlement servers140associated with social media influencers, such as celebrity gamers or gaming news publications, to use and/or to distribute further as they choose. The publisher might give out 20 of its coupons to user accounts/client device100associated with players selected at random, optionally limited based on geographic region. The publisher might give out 20 of its coupons to user accounts/client device100associated with players that reach certain achievements in a video game120, such as being the first player to pass a certain level or achieving a high score or fastest completion time.

In some cases, an entitlement server140and/or platform management server150, or one or more accounts associated with such servers, may include an unlimited amount of one or more entitlements or other virtual assets. This may be useful for a company that owns the platform to be able to grant entitlements to publishers, social media influencers, players, and the like. This may also be useful where blockchain ledgers are used to keep track of certain virtual assets gained or lost by a player due to actions other than transfer of the virtual asset between players.

For instance,FIG.2Ekeeps track of tournament wins and losses associated with a specific player, which may be incremented as needed based on the player's performance in one or more tournaments. Incrementing a win or loss count may be performed as a transfer of a “win” or “loss” from a server140/150having an unlimited number of “wins” and “losses” to a specific player based on the player's performance. As another example,FIG.2Fkeeps track of a player's health and number of coins in a very similar way. Actions occurring within the game that cause the player's health or coins to decrease may cause the player's account to transfer a specific amount of health or coins away from the player's account to a server140/150. Actions occurring within the game that cause the player's health or coins to increase may cause the server140to transfer a specific amount of health or coins to the player's account.

While additional network hardware105is not depicted inFIG.1C, it should be understood that any communication or API call illustrated in or discussed with respect toFIG.1Cor any other figure herein may be routed or passed through additional network hardware105as discussed with respect toFIG.1A,FIG.1B, and/orFIG.7.

Each client device110, platform management server150, entitlement server140, or element of network hardware105illustrated inFIG.1A,FIG.1B,FIG.1C,FIG.7, or any other figure herein may include one or more computing devices800as illustrated in or discussed with respect toFIG.8, or may include at least a subset of the components of one or more computing devices800.

The term “user account” or “account” as used herein may refer to a user as visible by a specific blockchain ledger, that is, an entity associated with a particular private/public key pair of a public key infrastructure (PKI). The key pair may be used for transaction verification as discussed further with respect toFIG.4. Each user account's private key may be stored on a client device110associated with the user account. Each user account's private key may alternately be stored on platform management server(s)150, which may be less secure/decentralized than keeping it on client device110but may be easier to use for players and provide a lower barrier of entry to players not familiar with PKI encryption and certificates. Public keys and their corresponding user account identities may be stored at verified via certificate authority (CA). In some cases, the platform management server(s)150may be a certificate authority (CA).

FIG.2Aillustrates a blockchain transaction that conveys transfer of an in-game asset from one player account to another player account.

A first state205of the blockchain ledger ofFIG.2Abefore the transaction210ofFIG.2Astates that a USER_123 possesses one of an in-game virtual asset ITEM_ABC, while a USER_456 possesses zero of the in-game virtual asset ITEM_ABC.

The transaction210ofFIG.2Astates that one of the in-game virtual asset ITEM_ABC is to be transferred from the USER_123 to the USER_456.

A second state215of the blockchain ledger ofFIG.2Aafter the transaction210ofFIG.2Astates that the USER_123 now possesses zero of the in-game virtual asset ITEM_ABC, while the USER_456 now possesses one of the in-game virtual asset ITEM_ABC.

While the blockchain ledger used for the transaction ofFIG.2Ais stated to be a game-specific blockchain ledger125inFIG.2Afor a GAME A, such a transaction may alternately use a platform-specific blockchain ledger115.

FIG.2Billustrates a blockchain transaction that conveys transfer of an amount of in-game currency from one player account to another player account.

A first state220of the blockchain ledger ofFIG.2Bbefore the transaction225ofFIG.2Bstates that a USER_123 possesses 50,000 of an in-game virtual currency GOLD, while a USER_456 possesses 200 of the in-game virtual currency GOLD.

The transaction225ofFIG.2Bstates that 1,000 of the in-game virtual currency GOLD is to be transferred from the USER_123 to the USER_456.

A second state230of the blockchain ledger ofFIG.2Bafter the transaction225ofFIG.2Bstates that the USER_123 now possesses 49,000 of the in-game virtual currency GOLD, while the USER_456 now possesses 1,200 of the in-game virtual currency GOLD.

Some technical benefits of tracking in-game virtual asset/currency transactions via blockchain-based technologies rather than via a centralized server is that virtual asset/currency transactions are more secure due to identity/transaction verification and the self-referential nature of each block's header within the blockchain structure itself, that all records are kept reliably up with no concern about downtime or single points of failure, that blockchain ledgers can be customized and personalized based on video game and/or video game platform and/or region, that the distributed architecture minimizes impact on network resources such as bandwidth and system resources such as processing power and memory due to load distribution. These benefits of decentralization can be combined with servers140/150illustrated inFIG.1Cto also bring some benefits of centralized servers, such as increased degree of control and management, into the decentralized environment and have technical benefits of both network architectures.

While the blockchain ledger used for the transaction ofFIG.2Bis stated to be a game-specific blockchain ledger125inFIG.2Bfor a GAME A, such a transaction may alternately use a platform-specific blockchain ledger115.

FIG.2Cillustrates a blockchain transaction that conveys transfer of an entitlement from a platform server to a player account.

A first state235of the blockchain ledger ofFIG.2Cbefore the transaction240ofFIG.2Cstates that a USER_123 possesses zero of a virtual entitlement asset ENTITLEMENT_XYZ. In an alternate variant of this first state235, a “from” user account may be identified, such as “GAME_PUBLISHER: {ENTITLEMENT_XYZ: 500}” or “GAME_PUBLISHER: {ENTITLEMENT_XYZ: infinite}.”

The transaction240ofFIG.2Cstates that five of the virtual entitlement asset ENTITLEMENT_XYZ is to be transferred to the USER_123. No “from” user account is identified, either implying that this quantity is to be generated, or it is to be transferred from a server140/150or a user account associated with the server140/150. In an alternate variant of this transaction240corresponding to the alternate variant of first state235discussed above, a “from” user account may be identified, such as “GAME_PUBLISHER.”

A second state245of the blockchain ledger ofFIG.2Cafter the transaction240ofFIG.2Cstates that the USER_123 now possesses five of the virtual entitlement asset ENTITLEMENT_XYZ. In an alternate variant of this second state245corresponding to the alternate variants of first state235and transaction240discussed above, a “from” user account may be identified, such as “GAME_PUBLISHER: {ENTITLEMENT_XYZ: 495}” or “GAME_PUBLISHER: {ENTITLEMENT_XYZ: infinite}.”

Some benefits of tracking virtual entitlement transactions via blockchain-based technologies rather than via a centralized server is that game movements are now secure, recorded and accessible reliably, and decentralized.

While the blockchain ledger used for the transaction ofFIG.2Cis stated to be a platform-specific blockchain ledger115inFIG.2C, such a transaction may alternately use a game-specific blockchain ledger125.

FIG.2Dillustrates a blockchain transaction that conveys an in-game movement of an in-game asset from a first position in an in-game environment to a second position in the in-game environment.

The in-game environment ofFIG.2Dmay be, for example, a chessboard, with dark and light pieces. The transaction discussed with respect toFIG.2Drepresents a movement of the dark side's knight piece from one position to another. In this transaction, the two accounts/key pairs actually represent different positions on a chessboard (or other in-game virtual environment) rather than different players.

A first state250of the blockchain ledger ofFIG.2Dbefore the transaction255ofFIG.2Dstates that a POSITION_G1 possesses one of an in-game virtual asset CHARACTER_DARK_KNIGHT, while a POSITION_F3 possesses zero of the in-game virtual asset CHARACTER_DARK_KNIGHT.

The transaction255ofFIG.2Dstates that one of the in-game virtual asset CHARACTER_DARK_KNIGHT is to be transferred from the POSITION_G1 to the POSITION_F3.

Some benefits of tracking character movements via blockchain-based technologies rather than via a centralized server is that game movements are now secure, recorded and accessible reliably, and decentralized.

A second state260of the blockchain ledger ofFIG.2Dafter the transaction255ofFIG.2Dstates that the POSITION_G1 now possesses zero of the in-game virtual asset CHARACTER_DARK_KNIGHT, while the POSITION_F3 now possesses one of the in-game virtual asset CHARACTER_DARK_KNIGHT.

While the blockchain ledger used for the transaction ofFIG.2Dis stated to be a game-specific blockchain ledger125inFIG.2Dfor a GAME A, such a transaction may alternately use a platform-specific blockchain ledger115.

FIG.2Eillustrates a blockchain transaction that conveys a win/loss history for a player in a tournament.

As discussed with respect toFIG.1C,FIG.2Ekeeps track of tournament wins and losses associated with a specific player, which may be incremented as needed based on the player's performance in one or more tournaments. Incrementing a win or loss count may be performed as a transfer of a “win” or “loss” from a server140/150having an unlimited number of “wins” and “losses” to a specific player based on the player's performance.

In the transaction ofFIG.2Especifically, a first state265of the blockchain ledger ofFIG.2Ebefore the transaction270ofFIG.2Estates that a USER_123 possesses 52 of a virtual asset TOURNAMENT_WINS and 37 of a virtual asset TOURNAMENT_LOSSES.

The transaction270ofFIG.2Estates that one of the virtual asset TOURNAMENT_WINS is to be transferred to the USER_123. No “from” user account is identified, either implying that this quantity is to be generated, or it is to be transferred from a server140/150or a user account associated with the server140/150as discussed further below.

A second state275of the blockchain ledger ofFIG.2Eafter the transaction270ofFIG.2Estates that the USER_123 now possesses 53 of the virtual asset TOURNAMENT_WINS and still 37 of the virtual asset TOURNAMENT_LOSSES.

Similarly to the alternate variants of the first state235, transaction240, and second state245ofFIG.2Cdiscussed above, the first state265, transaction270, and second state275ofFIG.2Emay list a “from” virtual entity such as “GAME_PLATFORM” associated with the game, “TOURNAMENT_TRACKER” associated with the platform, or “GAME_LEAGUE” associated with a gaming league such as Major League Gaming. The same applies toFIG.2C.

While the blockchain ledger used for the transaction ofFIG.2Eis stated to be a platform-specific blockchain ledger115inFIG.2E, such a transaction may alternately use a game-specific blockchain ledger125.

FIG.2Fillustrates a blockchain transaction that conveys in-game values specific to a particular player, such as health or number of coins.

As discussed with respect toFIG.1C,FIG.2Fkeeps track of a player's health and number of coins in a very similar way. Actions occurring within the game that cause the player's health or coins to decrease may cause the player's account to transfer a specific amount of health or coins away from the player's account to a server140/150. Actions occurring within the game that cause the player's health or coins to increase may cause the server140to transfer a specific amount of health or coins to the player's account.

In the transaction ofFIG.2Fspecifically, a first state280of the blockchain ledger ofFIG.2Fbefore the transaction285ofFIG.2Fstates that a USER_123 possesses 90 of a virtual asset PLAYER_HEALTH and 5 of a virtual asset NUMBER_OF_COINS.

The transaction285ofFIG.2Fstates that 11 of the virtual asset NUMBER_OF_COINS is to be transferred to the USER_123 and that 7 of the virtual asset PLAYER_HEALTH is to be taken away from the USER_123. No second party in the transaction285is identified, either implying that these quantities are to be tweaked without transfer to or from another virtual entity, or that quantities are to be transferred between USER_123 and a server140/150(or a user account associated with the server140/150) as discussed further below.

A second state290of the blockchain ledger ofFIG.2Fafter the transaction285ofFIG.2Fstates that the USER_123 now possesses 83 of the virtual asset PLAYER_HEALTH and 16 of the virtual asset NUMBER_OF_COINS.

Similarly to the alternate variants of the first state235, transaction240, and second state245ofFIG.2Cdiscussed above, the first state280, transaction285, and second state290ofFIG.2Fmay list a “from” virtual entity such as “GAME_PLATFORM” associated with the game, “PLATFORM_TRACKER” associated with the platform, or “GAME_LEAGUE” associated with a gaming league such as Major League Gaming. The player may alternately be in the “from” field while the virtual entity is in the “to” field, especially where the player is losing a virtual asset as in PLAYER_HEALTH in the transaction285ofFIG.2F.

While the blockchain ledger used for the transaction ofFIG.2Fis stated to be a platform-specific blockchain ledger115inFIG.2F, such a transaction may alternately use a game-specific blockchain ledger125.

The transactions210,225,240,255,270, and285ofFIGS.2A-2Fare illustrated including “sig” or “signature” values, which are hash values generated before, during, or after the transaction goes through. The hash may be a hash of the transaction or a Merkle root546of a few transactions within the same block as illustrated in and discussed with respect toFIG.5.

FIG.3illustrates a portion of a blockchain ledger that implements distributed in-game transfer functionality.

Three blocks—Block A305, Block B335, and Block C365—of the blockchain ledger300are illustrated inFIG.3.

Each block includes a block header310/340/370and a list of one or more transactions330/360/390. The block header310includes a hash of the block header of the previous block315/345/375, which may alternately be replaced or supplemented by a hash of the entire previous block. For instance, the header370of block C365includes a hash375of the header340of block B335. The header340of block B335likewise includes a hash345of the header310of block A305. The header310of block A305likewise includes a hash315of a header (not pictured) of previous block (not pictured) that is before block A305in the blockchain300. Including the hash of the previous block's header secures the blockchain ledger300by preventing modification of any block of the blockchain300after the block has been entered into the blockchain300, as any change to a particular block would cause that block header's hash in the next block to be incorrect. Further, modification of that block header's hash in the next block would make the next block's header's hash in the block after the next block incorrect, and so forth.

Each block's block header310/340/370also includes a Merkle root320/350/380, which is generated based on hashes of the transaction(s) listed in the list of transaction(s)330/360/390for that block as explained further with respect toFIG.5. Any attempt to modify a transaction after the block has been entered would change the Merkle root320/350/380, which would change the hash315/345/375of the block header310/340/370, again allowing all nodes to see if any block has been tampered with.

Each block's block header310/340/370may also include various elements of metadata, such as a version number for the blockchain ledger platform, a version number for the block itself that identifies how many nonces have been tried, a timestamp for verification of each transaction, a timestamp for generation of the block, a difficulty target value as discussed with respect toFIG.4, a nonce value as discussed with respect toFIG.4, or a combination thereof.

Each block305/335/365of the blockchain300also includes a list of one or more transaction(s)330/360/390. Each of these transactions may be identified in a similar matter to the transactions210,225,240,255,270, and285ofFIGS.2A-2F.

WhileFIG.3only illustrates three blocks305/335/365of the blockchain300, it should be understood that any blockchain discussed herein may be longer or shorter in that it may have more or fewer than three blocks.

FIG.4is a flow diagram illustrating operations for realizing an in-game transfer transaction and adding the transaction to the blockchain ledger.

At step405, a device A associated with a user account A receives user input(s) conveying an intended transaction of an identified quantity of a virtual asset from a transferor account to a transferee account. In most cases, user account A must be the transferor account for the intended transaction to proceed, but in some cases it may alternately be the transferee account. In some cases, user account A may even be a third party account other than the transferor and transferee, such as an account corresponding to a game developer, publisher, platform, adjudicative entity for transactions, or other entity with heightened power over transactions.

At step410, Device A associated with user account A encrypts at least part of the intended transaction using a private key associated with user account A to digitally sign the intended transaction.

At step415, Device A broadcasts or otherwise transmits the encrypted intended transaction to each device (node) of a distributed peer-to-peer network of devices (nodes), optionally along with a public key corresponding to the private key used to digitally sign the transaction in step410. Nodes receiving the public key may verify it against a key stored via a CA, or may verify a hash of the public key against a hash of a public key stored via the CA. Alternately, nodes may simply acquire the public key from the CA. The nodes may thereby verify that the intended transaction broadcast at step415was indeed digitally signed at step410by the user account A with the private key corresponding to user account A.

At step420, a “Miner” Device B, a node in the distributed peer-to-peer network, validates the intended transaction in one or more of three ways.

The “Miner” Device B may decrypt the intended transaction using the public key to verify that it was indeed digitally signed at step410by the user account A with the private key corresponding to user account A, and may optionally verify that user account A is a the transferor account, transferee account, or another account authorized to request the transaction in question.

The “Miner” Device B may identify, based on existing records in the blockchain, that the transferor account possesses at least the identified quantity of the asset to be transferred.

The “Miner” Device B may identify that the transferor acct is not trying to perform a simultaneous conflicting transfer, such as one that would leave the transferor acct lacking the identified quantity of the virtual asset to be transferred. That is, the “Miner” Device B may check that if all intended transactions involving the transferor account were to complete, the transferor account would be left with a non-negative (greater than or equal to zero) quantity of the virtual asset.

At step425, once the intended transaction (and optionally other transactions in same time predetermined period) is validated as in step420, the “Miner” Device B generates a block recording the verified transaction (and optionally other verified transactions in same predetermined time period), and broadcasts the block to the distributed peer-to-peer network of devices (nodes), thereby allowing each device (node) to update its copy of the blockchain ledger by appending the new block.

At step430, each device (node) of the distributed peer-to-peer network updates its copy of the blockchain ledger upon receipt of the new block from “Miner” Device B by appending the new block. The transaction is now complete.

Consensus among the nodes of the distributed network regarding new blocks can be achieved using a practical byzantine fault tolerance (PBFT) algorithm, a proof-of-work (PoW) algorithm, a proof-of-stake (PoS) algorithm, a delegated proof-of-stake (DPoS) algorithm, a proof-of-activity (PoA) algorithm, a proof-of-burn (PoB) algorithm, a proof-of-capacity (PoC) algorithm, a proof-of-storage (PoSt) algorithm, a proof-of-space (PoSp) algorithm, a proof-of-elapsed-time (PoET) algorithm, or a combination thereof.

Optional steps440,445, and450expand on steps420,425, and435.

At step440, the “Miner” Device B is rewarded for generating the new block, for example with a cryptocurrency. The cryptocurrency may have real value and be exchangeable for real fiat currency, may be used as a virtual in-game currency, or both. The generation and transfer of cryptocurrency to reward “Miner” Device B may be identified as a transaction in the next block after the block generated by “Miner” Device B at step425. Similarly, the block generated by “Miner” Device B at step425may identify a “Miner” Device that generated a previous block in the blockchain and may generate and transfer a similar reward to that “Miner” Device.

Step445explains that generating a new block to add to the blockchain can be made to be intentionally difficult if “miner” devices/nodes are to be rewarded as in step440. A predetermined numeric (decimal or hexadecimal) difficulty target value may be used. To successfully generate a new block, a hash of the block (or block header) should be numerically less than the difficulty target value for the new block to be successful. Each “miner” device/node can try hashing the new block with various different nonce values in the metadata325/355/385of the block header in an attempt to find a nonce value that makes the hash of the whole block (or block header) be numerically less than the difficulty target value.

Step450explains that the difficulty target value can stay constant during a predetermined time period, such as 2 weeks. Just before the predetermined time period ends and before the next time period starts, difficulty target value is potentially adjusted up or down slightly, using the formula identified in block455or a similar formula. In some cases, a predetermined upper and lower bound may be set on how much the difficulty target value may be adjusted by.

The formula identified in block455identifies that (new adjusted difficulty target value)=(previous difficulty target value)×((predetermined time period)/(total transaction time for N transactions during predetermined time period)). N is defined as ((predetermined time period)/(desired block generation time)).

If the time period is 2 weeks (20160 minutes) and each block should take approximately 10 minutes to generate, N is ((20160 minutes)/(10 minutes))=2016. Thus, one might calculate the new adjusted difficulty target value as (new adjusted difficulty target value)=(previous difficulty target value)×((20160 minutes)/(total transaction time for 2016 transactions during predetermined time period)).

FIG.5is a diagram of a Merkle tree for securing an in-game transfer transaction using the blockchain ledger.

The Merkle tree ofFIG.5is used to generate a Merkle root546for a block with 8 transactions: transaction A502, transaction B504, transaction C506, transaction D508, transaction E510, transaction F512, transaction G514, and transaction H516.

A hash is generated for each transaction. Transaction A502is hashed into hash A518, transaction B504is hashed into hash B520, transaction C506is hashed into hash C522, transaction D508is hashed into hash D524, transaction E510is hashed into hash E526, transaction F512is hashed into hash F528, transaction G514is hashed into hash G530, and transaction H516is hashed into hash H532.

Each of the hashes A518through H532are hashed after being paired with another hash. That is, Hash A518and Hash B520are hashed together into Hash AB534, Hash C522and Hash D524are hashed together into Hash CD536, Hash E526and Hash F528are hashed together into Hash EF538, and Hash G530and Hash H532are hashed together into Hash GH540.

This process repeats until a single hash results. That is, Hash AB534and Hash CD536are hashed together into Hash ABCD542, and Hash EF538and Hash GH540are hashed together into Hash EFGH544. Hash ABCD542and Hash EFGH544are hashed together into Hash ABCDEFGH546. Hash ABCDEFGH546is also known as the Merkle root546for the 8 transactions: transaction A502, transaction B504, transaction C506, transaction D508, transaction E510, transaction F512, transaction G514, and transaction H516. Any modification to any of these 8 transactions also necessarily changes the Merkle root546, which can be verified by any node to ensure that no changes were made to the transactions in any given block.

FIG.6illustrates a distributed directed acyclic graph (DAG) ledger.

WhileFIG.3andFIG.4discuss use of a blockchain ledger, it should be understood that a non-linear ledger structure, such as the directed acyclic graph (DAG) ledger structure ofFIG.6, may be used instead of a blockchain ledger discussed herein. In a DAG ledger, each block header includes the hashes of block headers of a predetermined number of other “parent” blocks in the DAG ledger selected either at random or in some other non-linear manner, rather than the hash of a single previous block in the blockchain. Each block header may alternately or additionally include hashes of the entire parent blocks instead of hashes of just the headers of the parent blocks. Where each block header includes multiple hashes corresponding to different parent blocks or their headers, these hashes can be combined together into a Merkle root much like the hashes A518, B520, C522, D524, E526, F528, G530, and H532ofFIG.5.

For example, in the DAG ledger ofFIG.6, the predetermined number is two, at least after the first two blocks are generated. In the web DAG ledger ofFIG.6, the parent blocks are indicated using arrows. Block610includes hashes of the block headers of parent blocks620and650. Block620includes hashes of the block headers of parent blocks640and660. Block630includes hashes of the block headers of parent blocks620and660. Block640includes hashes of the block headers of parent blocks610and630. Block650includes hashes of the block headers of parent blocks610and620. Block660includes hashes of the block headers of parent blocks610and650. The resulting structure is a directed acyclic graph (DAG) of blocks, where each vertex block includes a hash of its parent vertex block(s), rather than a linear stream of blocks as in a blockchain. A DAG ledger may sometimes be referred to as a “web,” a “tangle,” or a “hashgraph.”

In some cases, the number of parent blocks in a DAG ledger is not strictly predetermined, but there is a predetermined minimum number of blocks, such as a two-parent minimum or a one-parent minimum, meaning that each block has at least the predetermined minimum number of parent blocks. In some cases, each block in a DAG ledger may only identify only a single transaction rather than multiple transactions, and may therefore forego a Merkle root and/or replace it with a hash of the single transaction. In other implementations, each block may identify multiple transactions associated with a predetermined time period as discussed herein.

FIG.7illustrates a network environment through which different types of client devices participate in in-game transfers via the distributed blockchain ledger.

WhileFIG.1A,FIG.1B, andFIG.1Cillustrate client devices110A-110F as each being the same particular type of video game console, they need not be identical. There may be minor differences between the different client devices110, such as firmware, firmware version, operating system, operating system version, hardware, hardware version, or combinations thereof. For example, different client devices might include hard drives or flash memory chips with subtly or widely different storage capabilities. Later-produced client devices110might include faster processor(s) or additional cores. Certain client devices110might include additional hardware that might be missing from other client devices110, even if they are

Furthermore, whileFIG.1A,FIG.1B, andFIG.1Cillustrate client devices110A-110F as each being the same particular type of video game console, this need not be the case at all. Four client devices110are illustrated inFIG.7, including a client device110J that is a laptop computer, a client device110K that is a home video game console, a client device110L that is a desktop computer, and a client device110M that is a portable device/mobile device such as a smartphone, a tablet computing device, a media player device, a portable video game console, a wearable device, or a combination thereof. The client devices110ofFIG.7can communicate directly or via network hardware105as discussed with respect toFIG.1A,FIG.1B, andFIG.1C.

The client devices110ofFIG.7can run game-specific blockchain ledgers125as inFIG.1A. This is particularly useful if the game is released on multiple platforms (types of computing device) or is ported from one platform (type of computing device) to one or more other platforms (types of computing device). That said, client devices110need not be compatible with or capable of playing the video game to which the game-specific blockchain ledger125corresponds.

The client devices110ofFIG.7can run platform-specific blockchain ledgers115as inFIG.1B. This is particularly useful if the game is released on multiple platforms (types of computing device) or is ported from one platform (type of computing device) to one or more other platforms (types of computing device), thereby expanding the effective platform of the game to one encompassing multiple types of computing device. That said, client devices110need not be compatible with or capable of playing any video game(s) associated with the platform to which the platform-specific blockchain ledger115corresponds.

Use of a variety of client devices110may be useful to help ease the burden to video game consoles by allowing remote server(s) to take on some of the work of verifying transactions and generating blocks if needed. This can be particularly useful at launch of a new video game console, to make sure that transactions can be verified in a timely manner even for the first few new video game consoles to attempt transactions using the blockchain ledger.

FIG.8illustrates an exemplary computing system800that may be used to implement some aspects of the subject technology. For example, any of the computing devices, computing systems, network devices, network systems, servers, and/or arrangements of circuitry described herein may include at least one computing system800, or may include at least one component of the computer system800identified inFIG.8. The computing system800ofFIG.8includes one or more processors810and memory820. Each of the processor(s)810may refer to one or more processors, controllers, microcontrollers, central processing units (CPUs), graphics processing units (GPUs), arithmetic logic units (ALUs), accelerated processing units (APUs), digital signal processors (DSPs), application specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or combinations thereof. Each of the processor(s)810may include one or more cores, either integrated onto a single chip or spread across multiple chips connected or coupled together. Memory820stores, in part, instructions and data for execution by processor810. Memory820can store the executable code when in operation. The system800ofFIG.8further includes a mass storage device830, portable storage medium drive(s)840, output devices850, user input devices860, a graphics display880, and peripheral devices880.

The components shown inFIG.8are depicted as being connected via a single bus890. However, the components may be connected through one or more data transport means. For example, processor unit810and memory820may be connected via a local microprocessor bus, and the mass storage device830, peripheral device(s)880, portable storage device840, and display system880may be connected via one or more input/output (I/O) buses.

Mass storage device830, which may be implemented with a magnetic disk drive or an optical disk drive, is a non-volatile storage device for storing data and instructions for use by processor unit810. Mass storage device830can store the system software for implementing some aspects of the subject technology for purposes of loading that software into memory820.

Portable storage device840operates in conjunction with a portable non-volatile storage medium, such as a floppy disk, compact disk or Digital video disc, to input and output data and code to and from the computer system800ofFIG.8. The system software for implementing aspects of the subject technology may be stored on such a portable medium and input to the computer system800via the portable storage device840.

The memory820, mass storage device830, or portable storage840may in some cases store sensitive information, such as transaction information, health information, or cryptographic keys, and may in some cases encrypt or decrypt such information with the aid of the processor810. The memory820, mass storage device830, or portable storage840may in some cases store, at least in part, instructions, executable code, or other data for execution or processing by the processor810.

Output devices850may include, for example, communication circuitry for outputting data through wired or wireless means, display circuitry for displaying data via a display screen, audio circuitry for outputting audio via headphones or a speaker, printer circuitry for printing data via a printer, or some combination thereof. The display screen may be any type of display discussed with respect to the display system880. The printer may be inkjet, laserjet, thermal, or some combination thereof. In some cases, the output device circuitry850may allow for transmission of data over an audio jack/plug, a microphone jack/plug, a universal serial bus (USB) port/plug, an Apple® Lightning® port/plug, an Ethernet port/plug, a fiber optic port/plug, a proprietary wired port/plug, a BLUETOOTH® wireless signal transfer, a BLUETOOTH® low energy (BLE) wireless signal transfer, a radio-frequency identification (RFID) wireless signal transfer, near-field communications (NFC) wireless signal transfer, 802.11 Wi-Fi wireless signal transfer, cellular data network wireless signal transfer, a radio wave signal transfer, a microwave signal transfer, an infrared signal transfer, a visible light signal transfer, an ultraviolet signal transfer, a wireless signal transfer along the electromagnetic spectrum, or some combination thereof. Output devices850may include any ports, plugs, antennae, or any other components necessary for the communication types listed above, such as cellular Subscriber Identity Module (SIM) cards.

Input devices860may include circuitry providing a portion of a user interface. Input devices860may include an alpha-numeric keypad, such as a keyboard, for inputting alpha-numeric and other information, or a pointing device, such as a mouse, a trackball, stylus, or cursor direction keys. Input devices860may include touch-sensitive surfaces as well, either integrated with a display as in a touchscreen, or separate from a display as in a trackpad. Touch-sensitive surfaces may in some cases detect localized variable pressure or force detection. In some cases, the input device circuitry may allow for receipt of data over an audio jack, a microphone jack, a universal serial bus (USB) port/plug, an Apple® Lightning® port/plug, an Ethernet port/plug, a fiber optic port/plug, a proprietary wired port/plug, a BLUETOOTH® wireless signal transfer, a BLUETOOTH® low energy (BLE) wireless signal transfer, a radio-frequency identification (RFID) wireless signal transfer, near-field communications (NFC) wireless signal transfer, 802.11 Wi-Fi wireless signal transfer, cellular data network wireless signal transfer, a radio wave signal transfer, a microwave signal transfer, an infrared signal transfer, a visible light signal transfer, an ultraviolet signal transfer, a wireless signal transfer along the electromagnetic spectrum, or some combination thereof. Input devices860may include any ports, plugs, antennae, or any other components necessary for the communication types listed above, such as cellular SIM cards.

Display system880may include a liquid crystal display (LCD), a plasma display, an organic light-emitting diode (OLED) display, an electronic ink or “e-paper” display, a projector-based display, a holographic display, or another suitable display device. Display system880receives textual and graphical information, and processes the information for output to the display device. The display system880may include multiple-touch touchscreen input capabilities, such as capacitive touch detection, resistive touch detection, surface acoustic wave touch detection, or infrared touch detection. Such touchscreen input capabilities may or may not allow for variable pressure or force detection.

Peripherals880may include any type of computer support device to add additional functionality to the computer system. For example, peripheral device(s)880may include a modem, a router, an antenna, a printer, a bar code scanner, a quick-response (“QR”) code scanner, a document/image scanner, a visible light camera, a thermal/infrared camera, an ultraviolet-sensitive camera, a night vision camera, a light sensor, a battery, a power source, or some combination thereof.

The components contained in the computer system800ofFIG.8are those typically found in computer systems that may be suitable for use with some aspects of the subject technology and are intended to represent a broad category of such computer components that are well known in the art. Thus, the computer system800ofFIG.8can be a personal computer, a hand held computing device, a telephone (“smart” or otherwise), a mobile computing device, a workstation, a server (on a server rack or otherwise), a minicomputer, a mainframe computer, a tablet computing device, a wearable device (such as a watch, a ring, a pair of glasses, or another type of jewelry/clothing/accessory), a video game console (portable or otherwise), an e-book reader, a media player device (portable or otherwise), a vehicle-based computer, some combination thereof, or any other computing device. The computer system800may in some cases be a virtual computer system executed by another computer system. The computer can also include different bus configurations, networked platforms, multi-processor platforms, etc. Various operating systems can be used including Unix, Linux, Windows, Macintosh OS, Palm OS, Android, iOS, and other suitable operating systems.

In some cases, the computer system800may be part of a multi-computer system that uses multiple computer systems800, each for one or more specific tasks or purposes. For example, the multi-computer system may include multiple computer systems800communicatively coupled together via at least one of a personal area network (PAN), a local area network (LAN), a wireless local area network (WLAN), a municipal area network (MAN), a wide area network (WAN), or some combination thereof. The multi-computer system may further include multiple computer systems800from different networks communicatively coupled together via the internet (also known as a “distributed” system).

Some aspects of the subject technology may be implemented in an application that may be operable using a variety of devices. Non-transitory computer-readable storage media refer to any medium or media that participate in providing instructions to a central processing unit (CPU) for execution and that may be used in the memory820, the mass storage830, the portable storage840, or some combination thereof. Such media can take many forms, including, but not limited to, non-volatile and volatile media such as optical or magnetic disks and dynamic memory, respectively. Some forms of non-transitory computer-readable media include, for example, a floppy disk, a flexible disk, a hard disk, magnetic tape, a magnetic strip/stripe, any other magnetic storage medium, flash memory, memristor memory, any other solid-state memory, a compact disc read only memory (CD-ROM) optical disc, a rewritable compact disc (CD) optical disc, digital video disk (DVD) optical disc, a blu-ray disc (BDD) optical disc, a holographic optical disk, another optical medium, a secure digital (SD) card, a micro secure digital (microSD) card, a Memory Stick® card, a smartcard chip, a Europay®/Mastercard®/Visa® (EMV) chip, a subscriber identity module (SIM) card, a mini/micro/nano/pico SIM card, another integrated circuit (IC) chip/card, random access memory (RAM), static RAM (SRAM), dynamic RAM (DRAM), read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), flash EPROM (FLASHEPROM), cache memory (L1/L2/L3/L4/L5/L8), resistive random-access memory (RRAM/ReRAM), phase change memory (PCM), spin transfer torque RAM (STT-RAM), another memory chip or cartridge, or a combination thereof.

Various forms of transmission media may be involved in carrying one or more sequences of one or more instructions to a processor810for execution. A bus890carries the data to system RAM or another memory820, from which a processor810retrieves and executes the instructions. The instructions received by system RAM or another memory820can optionally be stored on a fixed disk (mass storage device830/portable storage840) either before or after execution by processor810. Various forms of storage may likewise be implemented as well as the necessary network interfaces and network topologies to implement the same.

While various flow diagrams provided and described above may show a particular order of operations performed by some embodiments of the subject technology, it should be understood that such order is exemplary. Alternative embodiments may perform the operations in a different order, combine certain operations, overlap certain operations, or some combination thereof.

The foregoing detailed description of the technology has been presented for purposes of illustration and description. It is not intended to be exhaustive or to limit the technology to the precise form disclosed. Many modifications and variations are possible in light of the above teaching. The described embodiments were chosen in order to best explain the principles of the technology, its practical application, and to enable others skilled in the art to utilize the technology in various embodiments and with various modifications as are suited to the particular use contemplated. It is intended that the scope of the technology be defined by the claim.