A secure decentralized video game trading platform

Abstract

A plurality of video game consoles each store a blockchain ledger having a plurality of blocks associated with a particular video game or with a particular type of video game console each characterized by the video game consoles. One of the consoles receives a message identifying an expected transaction corresponding to a transfer of an identified amount of in-game virtual assets from a transferor account to a transferee account. The console verifies that the expected transaction is valid and generates a new block including a block header of the transaction, optionally one or more additional verified expected transactions, and a hash of the header of the most recent block included in the blockchain ledger. The console appends the new block to the blockchain ledger and transmits it to the other consoles, each of which also appends the new block to their copy of the blockchain, thereby completing the transaction.

Description

[0001] This divisional application is a divisional application with a filing date of February 11, 2019, application number 201910110399.1, and invention name “Secure Decentralized Video Game Trading Platform”. Technical Field

[0002] Aspects of the subject technology relate to blockchain-based video game management, and in particular to a distributed blockchain-based platform for automatically and securely managing and tracking transactions of in-game assets, currencies, entitlements, and other video game data. Background Art

[0003] A video game is an electronic game in which a player interacts with a user interface coupled to a computing device, causing the computing device to generate visual feedback via a visual output device such as a television screen or computer monitor. Common user interfaces for video games include joysticks, video game console controllers, computer keyboards, computer mice, and touch-sensitive surfaces.

[0004] Some video games feature competitive or cooperative multiplayer game play, meaning that multiple players play the same video game simultaneously, typically with each player having their own user interface. During "local" multiplayer, the different user interfaces of the different players are all connected to a single computing device. During local area network (LAN) multiplayer or online multiplayer, the different players each use different computing devices, which then interact via the LAN or over the Internet.

[0005] Players playing video games can often progress through the game, for example, by exploring the environment or completing various objectives. Players can then save their game play to an account corresponding to the player so that their progress is not lost when the player returns to play again. In some video games, players can acquire virtual in-game assets, which are then saved to the player's account. For example, a player can unlock specific weapons, equipment, environments, or vehicles during game play. Some games also allow players to acquire virtual in-game currency during game play, which players can then trade for in-game assets during game play.

[0006] Traditionally, the transfer of in-game assets and in-game currency from one player to another player is impossible. Recently, a few video games with online multiplayer functions have begun to allow limited transfer of in-game assets, generally using centralized servers associated with individual games as intermediaries to ensure that transactions are valid and fair. However, there are considerable problems with these transfer methods. Centralized servers represent single points of failure that affect reliability and security, and are affected by competition conditions and performance issues. Centralized server crashes or goes offline at the wrong time or insufficient network bandwidth at the wrong time may mean that the transfer fails or the in-game assets are lost in the middle of the transfer. Similarly, centralized servers compromised by hackers or malicious parties may deceive users and become a medium for theft and cyberattacks. Managing the authenticity and ownership of virtual game content assets may also be a challenge, and different centralized servers may not store the same records or may have mismatched records. Data storage involves centralized servers, and may also cause records of past transactions to be intentionally lost over time in order to clear space or accidentally lost due to data destruction or server failure. Poor record keeping exacerbates the problem of fraudulent activities.

[0007] Cryptocurrencies are based on the recently developed blockchain ledger technology, which maintains a distributed ledger of all transactions and provides increased security between parties. So far, blockchain ledger technology has largely remained in the world of finance.

[0008] Therefore, there is a need for more secure, reliable and distributed technologies for in-game assets, in-game currency and other video game data. BRIEF DESCRIPTION OF THE DRAWINGS

[0009] Figure 1A A network environment is shown that maintains a distributed blockchain ledger on a per-game basis.

[0010] Figure 1B Shows a network environment that maintains a distributed blockchain ledger on a full platform basis.

[0011] Figure 1C A network environment is shown in which different types of distributed blockchain ledgers are maintained and managed via a platform management server.

[0012] Figure 2A A blockchain transaction conveying the transfer of in-game assets from one player account to another player account is shown.

[0013] Figure 2B A blockchain transaction conveying the transfer of an amount of in-game currency from one player account to another player account is shown.

[0014] Figure 2CA blockchain transaction conveying the transfer of rights from a platform server to a player account is shown.

[0015] Figure 2D A blockchain transaction conveying an in-game movement of an in-game asset from a first location in an in-game environment to a second location in the in-game environment is shown.

[0016] Figure 2E Blockchain transactions conveying the win / loss history of players in a tournament are shown.

[0017] Figure 2F Blockchain transactions conveying in-game values ​​unique to a particular player, such as amount of health or coins, are shown.

[0018] Figure 3 A portion of a blockchain ledger is shown that implements distributed in-game transfer functionality.

[0019] Figure 4 is a flow diagram illustrating operations for implementing an in-game transfer transaction and adding the transaction to a blockchain ledger.

[0020] Figure 5 A graph of Merkle trees used to secure in-game transfer transactions using a blockchain ledger.

[0021] Figure 6 A distributed directed acyclic graph (DAG) ledger is shown.

[0022] Figure 7 A network environment showing different types of client devices participating in in-game transfers via a distributed blockchain ledger.

[0023] Figure 8 is a block diagram of an exemplary computing device that can be used to implement some aspects of the subject technology. DETAILED DESCRIPTION

[0024] A plurality of video game consoles each store a blockchain ledger having a plurality of blocks associated with a particular video game or with a particular type of video game console each characterized by the video game consoles. One of the consoles receives a message identifying an expected transaction corresponding to a transfer of an identified amount of in-game virtual assets from a transferor account to a transferee account. The console verifies that the expected transaction is valid and generates a new block including the transaction, optionally one or more additional verified expected transactions, and a block header including a hash of the header of the most recent block included in the blockchain ledger (or optionally / in addition, 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 copies of the blockchain ledger, thereby completing the transaction.

[0025] Figure 1A A network environment is shown that maintains a distributed blockchain ledger on a per-game basis.

[0026] Figure 1A The network environment includes three client devices 110 , specifically, a first client device 110A, a second client device 110B, and a third client device 110C. Figure 1A Each of the three client devices 110 stores a video game A 120A and a video game A-specific blockchain ledger 125A.

[0027] Figure 1A Each of the three client devices 110 is a specific type of video game console that is compatible with video game A 120A and optionally multiple other video games. The specific type of video game console includes, for example, Figure 8 shown in or about Figure 8 The one or more computing devices 800 discussed may include at least a subset of the components of one or more computing devices 800 .

[0028] Figure 1A The network environment optionally includes network hardware 105, 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.

[0029] The first client device 110A and the second client device 110B may communicate via a communication path 160. The second client device 110B and the third client device 110C may communicate via a communication path 165. The first client device 110A and the third client device 110C may communicate via a communication path 170. Each of the communication paths 160, 165, and 170 may be a direct communication from one client device 110 to another client device 110, or may optionally pass through the network hardware 105. Each of the communication paths 160, 165, and 170 may pass through the public Internet, may be limited to a local area network (LAN) that is wireless or wired or some combination thereof, or may be limited to a personal area network (PAN) that is wireless or wired or some combination thereof.

[0030] The blockchain ledger consists of a digital ledger shared among public and private peer-to-peer networks. These digital ledgers are tamper-proof and record transactions in which a transferor sends a virtual asset to a transferee. The ledgers distributed to all nodes in the network permanently store a verified history of transactions that are made available through the Figure 4 Shown in and about Figure 4 The discussion process takes place among all peers in the network.

[0031] The blockchain ledger includes multiple blocks, each block identifying one or more transactions and also referencing a previous block in the blockchain, for example by including a hash of the header of the previous block in the blockchain in the header of each block, as in Figure 3 Shown in and about Figure 3 Including the hash of the previous block's header makes the blockchain ledger secure by preventing modification of any block of the blockchain after the block enters the blockchain, because any change to a particular block will make the hash of that block in the next block incorrect. Furthermore, modification of the hash of that block in the next block will make the hash of the next block after the next block incorrect, and so on.

[0032] Can be used as in Figure 5 Shown in and about Figure 5 The same or different hashing algorithm in question is used to generate the Merkle root of one or more transactions of a block to prevent modification of transactions in new blocks.

[0033] A hash algorithm is used to generate a hash of the previous block and a Merkle root hash, which hash algorithm can 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 variations or combinations thereof.

[0034] Figure 1A The game-specific blockchain ledger 125A is specific to video game A 120A. That is, Figure 1AThe game-specific blockchain ledger 125A stores transactions involving in-game virtual assets of the video game A 120A. In-game virtual assets involving the video game A 120A may be defined as virtual assets earned during game play of the video game A 120A, acquired in exchange for in-game virtual currency within the video game A 120A, purchased or acquired through the video game A 120A via in-app purchases (IAP) or downloadable content (DLC), that can be used to modify the game play of the video game A 120A, or a combination thereof. The game-specific blockchain 125A may be limited to identifying / listing / tracking only transactions involving in-game virtual assets of the video game A 120A, or may in some cases identify / list / track other types of transactions, such as purchases or transfers of copies of the video game A 120A itself, transactions involving the purchase or use of gift cards or other virtual currencies tied to a video game platform rather than a separate video game A 120A, transactions involving in-game virtual assets of games related to the video game A 120A, such as sequels or prequels, or a combination thereof.

[0035] Figure 1A The game-specific blockchain ledger 125A may, in some cases, be stored and / or maintained only by client devices 110 / user accounts that store / own a copy of video game A 120A, client devices 110 / user accounts that are authorized to access a copy of video game A 120A, client devices 110 / user accounts that are authorized to run a copy of video game A 120A, client devices 110 / user accounts that have run a copy of video game A 120A at least a predetermined number of times (e.g., at least once), or a combination thereof.

[0036] In such a case, the “miner” client device 110 is, for example, Figure 4The client device discussed in steps 420 and 425 of can verify that the transaction is valid in part by verifying that the transferor account stores / possesses a copy of video game A 120A, is authorized to access a copy of video game A 120A, is authorized to play a copy of video game A 120A, has played a copy of video game A 120A at least a predetermined number of times, or a combination thereof. Such a "miner" client device 110 can verify that the transaction is valid in part by verifying that the transferee account stores / possesses a copy of video game A 120A, is authorized to access a copy of video game A 120A, is authorized to play a copy of video game A 120A, has played a copy of video game A 120A at least a predetermined number of times, or a combination thereof. Finally, such a “miner” client device 110 may in some cases only be allowed to participate in verification transactions if the “miner” client device 110 and / or a user account associated with the “miner” client device 110 stores / owns a copy of video game A 120A, is authorized to access a copy of video game A 120A, is authorized to run a copy of video game A 120A, runs a copy of video game A 120A at least a predetermined number of times, or a combination thereof.

[0037] Different game-specific blockchain ledgers 125 may be generated to correspond to, for example, Figure 1C Each game-specific blockchain ledger 125B may be visible to different games in the video game B 120B. Figures 2A-2F A ledger containing any type of transaction identified in the ledger, or can optionally be restricted to a subset of those types of transactions.

[0038] Figure 1B Shows a network environment that maintains a distributed blockchain ledger on a full platform basis.

[0039] Figure 1B The platform-specific blockchain ledger 115 is similar to Figure 1A 12, but it can identify transactions associated with multiple games running on a specific video game platform. Figure 1B , client devices 110D and 110F store video game A 120A, but client device 110E instead stores video game B 120B. Nonetheless, client devices 110D, 110E, and 110F all store platform blockchain 115 because both video game A 120A and video game B 120B are compatible with the same video game platform that includes client devices 110D, 110E, and 110F. A video game platform as discussed herein may include multiple instances of a particular type of video game console, optionally along with associated network hardware 105.

[0040] For example, the platform-specific blockchain ledger 115 may be stored in multiple 4 console systems and multiple 4. Console system management, 4 console system in Figure 1B In the context of , the client device 110. The platform-specific blockchain ledger 115 may optionally be stored on a server (which is Figure 1B In the context of 4 Network services associated with the console system (such as 4 of Plus online network service) and is managed by the server and other network hardware. Other types of client devices 100, such as older 3-console system or portable The Vita console system could be specifically excluded from participation Figure 1B The platform-specific blockchain ledger 115 may also include and / or be limited to certain client devices 100 of certain brands or manufacturers, such as Client device 100, supporting blockchain ledger function Home and / or portable consoles, support The platform-specific blockchain ledger 115 may further include and / or be limited to certain client devices 100 based on location or purchase method, such as client devices 100 sold at a specific store type, client devices 100 sold at a specific store location, client devices 100 purchased online generally, client devices 100 purchased online through a specific website, client devices 100 located in a specific region, client devices 100 purchased / sold in a specific region, or a combination thereof. A region may be defined by a country, city, county, state, continent, constituency, other predetermined boundaries, or a combination thereof.

[0041] The platform-specific blockchain ledger 115 may explicitly exclude certain types of client devices 100. For example, the platform-specific blockchain ledger 115 may exclude a class of devices, such as portable video game console devices or home video game console devices. The platform-specific blockchain ledger 115 may further exclude certain brands or manufacturers of client devices 100, such as or A video game console client device 100, a client device 100 that is too old to support blockchain ledger functionality or that otherwise does not support blockchain ledger functionality, does not access or does not support access to certain online network services such as The platform-specific blockchain ledger 115 may further exclude certain client devices 100 based on location or purchase method, such as client devices 100 sold at a specific store type, client devices 100 sold at a specific store location, client devices 100 purchased online in general, client devices 100 purchased online through a specific website, client devices 100 located in a specific region, client devices 100 purchased / sold in a specific region, or a combination thereof. A region may be defined by a country, city, county, state, continent, constituency, other predetermined boundaries, or a combination thereof.

[0042] It should be noted that the above paragraphs identifying which client devices 100 may be included or excluded from participation in or storage of the blockchain ledger 115 may also apply to the game-specific blockchain ledger 125. Participation in this context may involve participation as a transferor, participation as a transferee, participation as a miner / validator, participation as a client device 100 that simply stores at least a portion of the blockchain ledger 125 / 115, or a combination thereof.

[0043] In such a case, the “miner” client device 110 is, for example, Figure 4 The client device discussed in steps 420 and 425 may verify that the transaction is valid in part by verifying that the transferor account and / or the client device 100 associated with the transferor account are allowed to use / access the platform as discussed above, by verifying that the transferee account and / or the client device 100 associated with the transferee account are allowed to use / access the platform as discussed above, by verifying that the "miner" client device 110 and / or the user account associated with the "miner" client device 110 are allowed to use / access the platform as discussed above, or a combination thereof.

[0044] The platform-specific blockchain ledger 115 may store / manage the same types of transactions as discussed with respect to the game-specific blockchain ledger 125. However, the platform-specific blockchain ledger 115 may in some cases be limited to transactions of virtual assets other than in-game assets that are specific to a game that already has a game-specific blockchain ledger 125. For example, if the client device 100 detects that video game A 120A uses a corresponding game-specific blockchain ledger 125A, it may use the game-specific blockchain ledger 125A to store and manage video game A 120A instead of the platform-specific blockchain ledger 115. If the client device 100 detects that video game C 120C does not have a corresponding game-specific blockchain ledger 125C, it may use the platform-specific blockchain ledger 115 to store and manage video game C 120C. The platform-specific blockchain ledger 115 may also be used for virtual asset transactions that do not involve any specific video game but instead involve virtual assets of the video game platform, such as the purchase or transfer of video games, the purchase or transfer of services such as online multiplayer, the purchase or transfer of media such as music or movies played via the client device 100, the purchase or transfer of gift cards or credits earned through the platform rather than through any individual game, or a combination thereof.

[0045] Figure 1C A network environment is shown in which different types of distributed blockchain ledgers are maintained and managed via a platform management server.

[0046] Figure 1C The network environment includes Figure 1A The client devices 110A and 110B and Figure 1B The client devices 110D and 110E. Figure 1C The network environment also includes one or more platform management servers 150 and one or more rights servers 140. Further references herein to a single platform management server 150 or a single rights server 140 should be understood to alternatively refer to multiple platform management servers 150 or multiple rights servers 140, respectively. Some servers can optionally be used as platform management servers 150 or rights servers 140.

[0047] Each platform management server 150 includes one or more blockchain ledgers, including a game-specific blockchain ledger 125 and / or a platform-specific blockchain ledger 115. For example, Figure 1C The platform management server 150 stores a game-specific blockchain ledger 125A corresponding to video game A 120A, a game-specific blockchain ledger 125B corresponding to video game B 120B, and a platform-specific blockchain ledger 115. These ledgers are respectively as shown in FIG. Figure 1A and Figure 1B What is shown and described works.

[0048] Figure 1C The platform management server 150 also includes an application programming interface (API) 130 / 135 corresponding to the blockchain ledger 115 / 125.

[0049] In particular, the game-callable blockchain ledger API 130 may be called by an operating system, video game, or other software running on client devices 110A and 110B to implement a game-centric blockchain ledger 125, such as Figure 1C The game-callable API 130 allows the game-centric blockchain ledger 125 to operate between different client devices 110 in a standardized manner and allows updates to be instant. It also provides a certain degree of control and centralization for one party, such as the manufacturer or developer of the client device 110, to regulate and control certain aspects of each game-centric blockchain ledger 125. Such control and centralization are generally otherwise lost due to decentralization, which is the focus of blockchain technology.

[0050] Similarly, the platform-callable blockchain ledger API 135 may be called by an operating system, video game, or other software running on client devices 110D and 110E to implement Figure 1C The platform-callable API 135 allows one or more platform-centric blockchain ledgers 115 to operate in a standardized manner between different client devices 110, and allows updates to be instant. It also provides a degree of control and centralization for one party, such as the manufacturer or developer of the client device 110, to regulate and control certain aspects of each platform-centric blockchain ledger 115. Such control and centralization are generally otherwise lost due to decentralization, which is the focus of blockchain technology.

[0051] The rights server 140 may be a server associated with a developer, publisher, manufacturer, social media influencer, or other entity associated with the client device 110 or with a particular video game 120. The rights server 140 may be associated with certain "rights" such as discounts, coupons, promotions, multi-player gaming tournament prizes, rewards for certain gaming achievements, or a combination thereof. "Rights" may alternatively or additionally define ownership or rental of digital content such as subscriptions, games, gift cards / vouchers, movies, and television shows. A user may acquire rights when they purchase, rent, receive as a gift, or otherwise acquire an item, game, gift card / voucher, video, or subscription to a service, or any of the foregoing. These rights may also be transferred via the blockchain ledger. Figure 1C, the rights server 140 is shown as calling the platform callable API 135 to use the platform specific blockchain ledger 115, but it may alternatively call the game callable API 130 to use the game specific blockchain ledger 130 instead or alternatively.

[0052] For example, a game publisher may obtain one hundred 10% discount coupons in exchange for publishing a particular video game 120 via the platform, optionally via the platform management server 150, to be played by a particular type of client device 110. These one hundred 10% discount coupons may be tied to one or more user accounts associated with the publisher and / or to specific hardware of one or more rights servers 140 associated with the publisher. The publisher may distribute 40 of its coupons to user accounts / client devices 100 associated with players who win tournaments. The publisher may distribute 30 of its coupons to user accounts / client devices 100 / rights servers 140 associated with social media influencers, such as celebrity gamers or game news releases, for use and / or further distribution as they choose. The publisher may distribute 20 of its coupons to user accounts / client devices 100 associated with randomly selected, optionally restricted based on geographic regions. The publisher may distribute 20 of its coupons to user accounts / client devices 100 associated with players who achieve certain achievements in the video game 120, such as the first player to pass a level or achieve a high score or fastest completion time.

[0053] In some cases, the rights server 140 and / or platform management server 150 or one or more accounts associated with such servers may include an unlimited number of one or more rights or other virtual assets. This may be useful for companies that own the platform to be able to grant rights to publishers, social media influencers, players, etc. This may also be useful where a blockchain ledger is used to track certain virtual assets gained or lost by players due to actions other than transfers of virtual assets between players.

[0054] For example, Figure 2E Tracking tournament wins and losses associated with a particular player, which can be incremented as needed based on the player's performance in one or more tournaments. Incrementing the win and loss counts can be performed by transferring a "win" or "loss" from a server 140 / 150 having an unlimited number of "wins" and "losses" to a particular player based on the player's performance. As another example, Figure 2FThe amount of health and coins of a player is tracked in a very similar manner. Actions that occur within the game that cause a decrease in a player's health or coins can cause the player's account to transfer a specific amount of health or coins from the player's account to the server 140 / 150. Actions that occur within the game that cause an increase in a player's health or coins can cause the server 140 to transfer a specific amount of health or coins to the player's account.

[0055] Although not in Figure 1C 105, but it should be understood that the additional network hardware 105 is not shown in FIG. Figure 1C or any other figure shown in or relating to Figure 1C Any communication or API call discussed in connection with or in connection with any other figure herein may be routed or communicated via additional network hardware 105, such as with respect to Figure 1A , Figure 1B and / or Figure 7 discussed.

[0056] Figure 1A , Figure 1B , Figure 1C , Figure 7 Each client device 110, platform management server 150, rights server 140, or element of network hardware 105 shown in any other figure herein may include as shown in Figure 8 shown in or about Figure 8 The one or more computing devices 800 discussed may include at least a subset of the components of one or more computing devices 800 .

[0057] As used herein, the term "user account" or "account" may refer to a user as visible to an entity associated with a particular blockchain ledger, i.e., a particular private / public key pair of a public key infrastructure (PKI). The key pair may be used to identify a user as visible to an entity associated with a particular blockchain ledger, i.e., a particular private / public key pair of a public key infrastructure (PKI). Figure 4 Transaction verification discussed. The private key for each user account may be stored on the client device 110 associated with the user account. The private key for each user account may optionally be stored on the platform management server 150, which may be less secure / dispersed than keeping it on the client device 110, but may be easier for players to use and provide a lower barrier to entry for players who are not familiar with PKI encryption and certificates. Public keys and their corresponding user account identifiers may be stored and verified via a certificate authority (CA). In some cases, the platform management server 150 may be a certificate authority (CA).

[0058] Figure 2A A blockchain transaction conveying the transfer of in-game assets from one player account to another player account is shown.

[0059] exist Figure 2A Transaction 210 before Figure 2AThe first state 205 of the blockchain ledger states that USER_123 owns one in-game virtual asset ITEM_ABC, while USER_456 owns zero in-game virtual assets ITEM_ABC.

[0060] Figure 2A Transaction 210 states that an in-game virtual asset ITEM_ABC will be transferred from USER_123 to USER_456.

[0061] exist Figure 2A After the transaction 210 Figure 2A The second state 215 of the blockchain ledger states that USER_123 now owns zero in-game virtual assets ITEM_ABC, while USER_456 now owns one in-game virtual asset ITEM_ABC.

[0062] Although used for Figure 2A The blockchain ledger of transactions is declared to be Figure 2A , but such transactions may alternatively use the platform-specific blockchain ledger 115 .

[0063] Figure 2B A blockchain transaction conveying the transfer of an amount of in-game currency from one player account to another player account is shown.

[0064] exist Figure 2B Transaction 225 before Figure 2B The first state 220 of the blockchain ledger states that USER_123 owns 50,000 in-game virtual currency GOLD, while USER_456 owns 200 in-game virtual currency GOLD.

[0065] Figure 2B Transaction 225 states that 1,000 GOLD, the in-game virtual currency, will be transferred from USER_123 to USER_456.

[0066] exist Figure 2B After the transaction 225 Figure 2B The second state 230 of the blockchain ledger states that USER_123 now owns 49,000 of the in-game virtual currency GOLD, while USER_456 now owns 1,200 of the in-game virtual currency GOLD.

[0067] Some of the technical benefits of tracking in-game virtual asset / or currency transactions via blockchain-based technology rather than via centralized servers are that virtual asset / currency transactions are more secure due to the identification / transaction verification and self-referential nature of each block's header within the blockchain structure itself, all records are reliably maintained without concerns about downtime or single points of failure, the blockchain ledger can be customized and personalized based on video game and / or video game platform and / or region, and the distributed architecture minimizes the 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 Figure 1C The server 140 / 150 combination shown also brings some of the benefits of a centralized server, such as a higher degree of control and management, into a decentralized environment, with the technical benefits of both network architectures.

[0068] Although used for Figure 2B The blockchain ledger of transactions is declared to be Figure 2B , but such transactions may alternatively use the platform-specific blockchain ledger 115 .

[0069] Figure 2C A blockchain transaction conveying the transfer of rights from a platform server to a player account is shown.

[0070] exist Figure 2C Transaction 240 before Figure 2C The first state 235 of the blockchain ledger of USER_123 states that USER_123 owns zero virtual rights asset ENTITLEMENT_XYZ. In an optional variation of this first state 235, a "slave" user account can be identified, such as "GAME_PUBLISHER:{ENTITLEMENT_XYZ:500}" or "GAME_PUBLISHER:{ENTITLEMENT_XYZ:infinite}".

[0071] Figure 2C Transaction 240 states that five virtual entitlement assets ENTITLEMENT_XYZ will be transferred to USER_123. No "from" user account is identified, suggesting that this amount will be generated, or that it will be transferred from server 140 / 150 to a user account associated with server 140 / 150. In an alternative variation of this transaction 240 corresponding to the alternative variation of the first state 235 discussed above, a "from" user account may be identified, such as "GAME_PUBLISHER".

[0072] exist Figure 2C After the transaction 240 Figure 2CThe second state 245 of the blockchain ledger states that USER_123 now owns five virtual rights assets ENTITLEMENT_XYZ. In the optional variation of this second state 245 corresponding to the first state 235 and the transaction 240 discussed above, a "from" user account can be identified, such as "GAME_PUBLISHER:{ENTITLEMENT_XYZ:495}" or "GAME_PUBLISHER:{ENTITLEMENT_XYZ:infinite}".

[0073] Some technical benefits of tracking virtual rights transactions via blockchain-based technology rather than via centralized servers are that game moves are now securely, reliably recorded and accessible, and decentralized.

[0074] Although used for Figure 2C The blockchain ledger of transactions is declared to be Figure 2C The platform-specific blockchain ledger 115 in FIG. 1 is used for the transaction, but such transactions may alternatively use the game-specific blockchain ledger 125 .

[0075] Figure 2D A blockchain transaction conveying an in-game movement of an in-game asset from a first location in an in-game environment to a second location in the in-game environment is shown.

[0076] Figure 2D The in-game environment of may be, for example, a chessboard with black and white pieces. Figure 2D The transaction in question represents the movement of the black knight chess piece from one position to another. In this transaction, the two account / key pairs actually represent different positions on the chessboard (or other in-game virtual environment) rather than different players.

[0077] exist Figure 2D Transaction 255 before Figure 2D The first state 250 of the blockchain ledger states that POSITION_G1 owns one in-game virtual asset CHARACTER_DARK_KNIGHT, while POSITION_F3 owns zero in-game virtual assets CHARACTER_DARK_KNIGHT.

[0078] Figure 2D Transaction 255 declares that an in-game virtual asset CHARACTER_DARK_KNIGHT will be transferred from POSITION_G1 to POSITION_F3.

[0079] Some benefits of tracking character movements via blockchain-based technology rather than via a centralized server are that game moves are now securely, reliably recorded and accessible, and decentralized.

[0080] exist Figure 2D After transaction 255 Figure 2D The second state 260 of the blockchain ledger states that POSITION_G1 now owns zero in-game virtual assets CHARACTER_DARK_KNIGHT, and POSITION_F3 now owns one in-game virtual asset CHARACTER_DARK_KNIGHT.

[0081] Although used for Figure 2D The blockchain ledger of transactions is declared to be Figure 2D , but such transactions may alternatively use the platform-specific blockchain ledger 115 .

[0082] Figure 2E Blockchain transactions conveying the win / loss history of players in a tournament are shown.

[0083] As about Figure 1C Discussed, Figure 2E Tournament wins and losses associated with a particular player are tracked and may be incremented as needed based on the player's performance in one or more tournaments. Incrementing the win and loss counts may be performed as a "win" or "loss" is transferred from a server 140 / 150 having an unlimited number of "wins" and "losses" to a particular player based on the player's performance.

[0084] exist Figure 2E In transactions, in particular, Figure 2E Transaction 270 before Figure 2E The first state 265 of the blockchain ledger states that USER_123 owns 52 virtual assets TOURNAMENT_WINS and 37 virtual assets TOURNAMENT_LOSSES.

[0085] Figure 2E Transaction 270 states that a virtual rights asset TOURNAMENT_WINS will be transferred to USER_123. No "from" user account is identified, suggesting that this amount will be generated, or that it will be transferred from a server 140 / 150 or a user account associated with a server 140 / 150, as discussed further below.

[0086] exist Figure 2E After the transaction 270 Figure 2E The second state 275 of the blockchain ledger states that USER_123 now owns 53 virtual assets TOURNAMENT_WINS and still 37 virtual assets TOURNAMENT_LOSSES.

[0087] Similar to what was discussed above Figure 2C Optional variations of the first state 235, the transaction 240 and the second state 245, Figure 2E The first state 265, transaction 270, and second state 275 of may list a "from" virtual entity, such as "GAME_PLATFORM" associated with a game, "TOURNAMENT_TRACKER" associated with a platform, or "GAME_LEAGUE" associated with a gaming league such as Major League Gaming. The same applies to Figure 2C .

[0088] Although used for Figure 2E The blockchain ledger of transactions is declared to be Figure 2E The platform-specific blockchain ledger 115 in FIG. 1 is used for the transaction, but such transactions may alternatively use the game-specific blockchain ledger 125 .

[0089] Figure 2F Blockchain transactions conveying in-game values ​​unique to a particular player, such as amount of health or coins, are shown.

[0090] As mentioned above Figure 1C Discussed, Figure 2F The amount of health and coins of a player is tracked in a very similar manner. Actions that occur within the game that cause a decrease in a player's health or coins can cause the player's account to transfer a specific amount of health or coins from the player's account to the server 140 / 150. Actions that occur within the game that cause an increase in a player's health or coins can cause the server 140 to transfer a specific amount of health or coins to the player's account.

[0091] exist Figure 2F In transactions, in particular, Figure 2F Transaction 285 before Figure 2F The first state 280 of the blockchain ledger states that USER_123 owns 90 virtual assets PLAYER_HEALTH and 5 virtual assets NUMBER_OF_COINS.

[0092] Figure 2F Transaction 285 states that 11 virtual rights assets NUMBER_OF_COINS will be transferred to USER_123 and 7 virtual assets PLAYER_HEALTH will be taken from USER_123. No second party is identified in transaction 285, suggesting that this amount will be adjusted without being transferred to or from another virtual entity, or that the amount will be transferred between USER_123 and server 140 / 150 (or a user account associated with server 140 / 150), as discussed further below.

[0093] exist Figure 2FAfter the transaction 285 Figure 2F The second state 290 of the blockchain ledger states that USER_123 now owns 83 virtual assets PLAYER_HEALTH and 16 virtual assets NUMBER_OF_COINS.

[0094] Similar to what was discussed above Figure 2C Optional variations of the first state 235, the transaction 240 and the second state 245, Figure 2F The first state 280, transaction 285, and second state 290 of a transaction may list a "from" virtual entity, such as a "GAME_PLATFORM" associated with a game, a "PLATFORM_TRACKER" associated with a platform, or a "GAME_LEAGUE" associated with a gaming league such as Major League Gaming. The player may optionally be in the "from" field and the virtual entity in the "to" field, particularly where the player is losing virtual assets, such as in Figure 2F Transaction 285 in PLAYER_HEALTH.

[0095] Although used for Figure 2F The blockchain ledger of transactions is declared to be Figure 2F The platform-specific blockchain ledger 115 in FIG. 1 is used for the transaction, but such transactions may alternatively use the game-specific blockchain ledger 125 .

[0096] Figures 2A-2F Transactions 210, 225, 240, 255, 270, and 285 are shown as including "sig" and "signature" values, which are hash values ​​generated before, during, or after the transaction is passed. The hash can be generated in conjunction with Figure 5 Shown in and about Figure 5 The transaction hash or Merkle root 546 of several transactions within the same block in question.

[0097] Figure 3 A portion of a blockchain ledger is shown that implements distributed in-game transfer functionality.

[0098] exist Figure 3 Three blocks of the blockchain ledger 300 are shown: block A 305, block B 335, and block C 365.

[0099] Each block includes a block header 310 / 340 / 370 and a list of one or more transactions 330 / 360 / 390. The block header 310 includes a hash of the block header of the previous block 315 / 345 / 375, which may optionally be replaced or supplemented by a hash of the entire previous block. For example, the header 370 of block C 365 includes a hash 375 of the header 340 of block B 335. The header 340 of block B 335 also includes a hash 345 of the header 310 of block A 305. The header 310 of block A 305 also includes a hash 315 of the header (not depicted) of the previous block (not depicted) before block A 305 in the blockchain 300. Including the hash of the header of the previous block makes the blockchain ledger 300 secure by preventing modification of any block of the blockchain 300 after the block enters the blockchain 300, because any change to a particular block will cause the hash of the block header in the next block to be incorrect. Furthermore, the modification of the hash of that block's header in the next block will make the hash of the next block's header in the block after that block incorrect, and so on.

[0100] The block header 310 / 340 / 370 of each block also includes a Merkle root 320 / 350 / 380, which is generated based on the hash of the transactions listed in the list of transactions 330 / 360 / 390 for that block, as described with respect to Figure 5 Any attempt to modify transactions after the block inputs have been altered will change the Merkle root 320 / 350 / 380, which will change the hash 315 / 345 / 375 of the block header 310 / 340 / 370, again allowing all nodes to see if any blocks have been tampered with.

[0101] The block header 310 / 340 / 370 of each block may also include various elements of metadata, such as a version number of the blockchain ledger platform, a version number of the block itself identifying how many nonces were tried, a timestamp of the verification of each transaction, a timestamp of the generation of the block, and other information such as the version number of the blockchain ledger platform, the version number of the block itself identifying how many nonces were tried, the timestamp of the verification of each transaction, the timestamp of the generation of the block, and other information such as the version number of the blockchain ledger platform, the version number of the block itself identifying how many nonces were tried, and the timestamp of the verification of each transaction. Figure 4 The difficult target values ​​discussed, such as Figure 4 The nonce value or combination thereof in question.

[0102] Each block 305 / 335 / 365 of the blockchain 300 also includes a list of one or more transactions 330 / 360 / 390. Each of these transactions can be used with Figures 2A-2F Transactions 210, 225, 240, 255, 270, and 285 are identified in a similar manner.

[0103] Although Figure 3 Only three blocks 305 / 335 / 365 of blockchain 300 are shown, it being understood that any blockchain discussed herein may be longer or shorter in that it may have more or less than three blocks.

[0104] Figure 4 is a flow diagram illustrating operations for implementing an in-game transfer transaction and adding the transaction to a blockchain ledger.

[0105] At step 405, device A associated with user account A receives user input conveying an intended transaction of an identified amount of virtual assets from a transferor account to a transferee account. In most cases, user account A must be the transferor account of the intended transaction to be conducted, but in some cases it may alternatively 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, adjudication entity for the transaction, or other entity with enhanced authority over the transaction.

[0106] At step 410 , device A associated with user account A encrypts at least a portion of an intended transaction using a private key associated with user account A to digitally sign the intended transaction.

[0107] At step 415, device A broadcasts or transmits the encrypted expected transaction to each device (node) of the 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 step 410. Nodes receiving the public key may verify it against a key stored via the CA, or may verify the hash of the public key against a hash of the public key stored via the CA. Alternatively, the node may simply obtain the public key from the CA. The node may thereby verify that the expected transaction broadcast at step 415 was in fact digitally signed at step 410 by user account A using the private key corresponding to user account A.

[0108] At step 420, a "miner" device B - a node in a distributed peer-to-peer network - verifies the intended transaction in one or more of three ways.

[0109] "Miner" device B can use the public key to decrypt the intended transaction to verify that it was actually digitally signed by user account A using the private key corresponding to user account A in step 410, and can optionally verify that user account A is the transferor account, transferee account, or another account authorized to request the transaction in question.

[0110] The "miner" device B can identify, based on existing records in the blockchain, that the transferor account owns at least the identified amount of assets to be transferred.

[0111] The "miner" device B can identify that the transferor account is not attempting to perform concurrent conflicting transfers, such as transfers that would leave the transferor account short of the identified amount of assets to be transferred. That is, the "miner" device B can check whether all intended transactions involving the transferor account will be completed and the transferor will be left with a non-negative (greater than or equal to zero) amount of virtual assets.

[0112] In step 425, once the expected transaction (and optionally other transactions in the same predetermined time period) is verified as in step 420, the "miner" device B generates a block recording the verified transaction (and optionally other verified transactions in the 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.

[0113] At step 430, each device (node) of the distributed peer-to-peer network updates its copy of the blockchain ledger by appending the new block as it is received from the "miner" device B. The transaction is now complete.

[0114] The Practical Byzantine Fault Tolerance (PBFT) algorithm, the Proof of Work (PoW) algorithm, the Proof of Stake (PoS) algorithm, the Delegated Proof of Stake (DPoS) algorithm, the Proof of Activity (PoA) algorithm, the Proof of Burn (PoB) algorithm, the Proof of Capacity (PoC) algorithm, the Proof of Storage (PoSt) algorithm, the Proof of Space (PoSp) algorithm, the Proof of Elapsed Time (PoET) algorithm and their combinations may be used to reach consensus on new blocks among the nodes of a distributed network.

[0115] Optional steps 440 , 445 and 450 further elaborate on steps 420 , 425 and 435 .

[0116] At step 440, "miner" device B is rewarded with cryptocurrency, for example, for generating a new block. The cryptocurrency may have real value and may be exchanged for real legal currency, may be used as a virtual in-game currency, or both. The generation and transfer of the cryptocurrency that rewards "miner" device B may be identified as a transaction in the next block after the block generated by "miner" device B at step 425. Similarly, the block generated by "miner" device B at step 425 may identify the "miner" device that generated the previous block in the blockchain, and a similar reward to that "miner" device may be generated and transferred.

[0117] Step 445 explains that generating new blocks to add to the blockchain may be intentionally difficult if "miner" devices / nodes are rewarded as in step 440. A predetermined numerical (decimal or hexadecimal) difficulty target value may be used. In order to successfully generate a new block, the hash of the block (or block header) should be numerically less than the difficulty target value for the new block to succeed. Each "miner" device / node may try to hash the new block with various different nonce values ​​in the metadata 325 / 355 / 385 of the block header in an effort to find a nonce value that causes the hash of the entire block (or block header) to become numerically less than the difficulty target value.

[0118] Step 450 explains that the difficulty target value may remain constant during a predetermined time period, such as 2 weeks. Just before the end of the predetermined time period and before the beginning of the next time period, the difficulty target value is potentially adjusted slightly up or down using the formula identified in block 455 or a similar formula. In some cases, predetermined upper and lower limits may be set as to how much the difficulty target value may be adjusted.

[0119] The formula identified in block 455 identifies (new adjusted difficulty target value) = (previous difficulty target value) x ((predetermined time period) / (total transaction time for N transactions during the predetermined time period)). N is defined as ((predetermined time period) / (expected block generation time)).

[0120] If the time period is 2 weeks (20160 minutes) and each block should take about 10 minutes to generate, then N is ((20160 minutes) / (10 minutes))=2016. Therefore, we can calculate the newly adjusted difficulty target value as (newly adjusted difficulty target value)=(previous difficulty target value)×((20160 minutes) / (total transaction time of 2016 transactions during the predetermined time period)).

[0121] Figure 5 A graph of Merkle trees used to secure in-game transfer transactions using a blockchain ledger.

[0122] Figure 5 The Merkle tree of is used to generate a Merkle root 546 of a block with 8 transactions: transaction A 502, transaction B 504, transaction C 506, transaction D 508, transaction E 510, transaction F 512, transaction G 514, and transaction H 516.

[0123] A hash is generated for each transaction. Transaction A 502 is hashed into hash A 518, transaction B 504 is hashed into hash B 520, transaction C 506 is hashed into hash C 522, transaction D 508 is hashed into hash D 524, transaction E 510 is hashed into hash E 526, transaction F 512 is hashed into hash F 528, transaction G 514 is hashed into hash G 530, and transaction H 516 is hashed into hash H 532.

[0124] Each of hashes A 518 to H 532 is hashed after being paired with another hash. That is, hash A 518 and hash B 520 are hashed together into hash AB 534, hash C 522 and hash D 524 are hashed together into hash CD 536, hash E 526 and hash F 528 are hashed together into hash EF 538, and hash G 530 and hash H 532 are hashed together into hash GH 540.

[0125] This process repeats until a single hash is produced. That is, hash AB 534 and hash CD 536 are hashed together into hash ABCD 542, and hash EF 538 and hash GH 540 are hashed together into hash EFGH 544. Hash ABCD 542 and hash EFGH 544 are hashed together into hash ABCDEFGH 546. Hash ABCDEFGH 546 is also referred to as the Merkle root 546 of the eight transactions: transaction A 502, transaction B 504, transaction C 506, transaction D 508, transaction E 510, transaction F 512, transaction G 514, and transaction H 516. Any modification to any of the eight transactions must also change the Merkle root 546, which can be verified by any node to ensure that no changes are made to the transactions in any given block.

[0126] Figure 6 A distributed directed acyclic graph (DAG) ledger is shown.

[0127] Although Figure 3 and Figure 4 The use of a blockchain ledger is discussed, but it should be understood that non-linear ledger structures may be used, e.g. Figure 6Instead of the blockchain ledger discussed herein, a directed acyclic graph (DAG) ledger structure is used. In a DAG ledger, each block header includes the hash of the block headers of a predetermined number of other "parent" blocks in the DAG ledger, selected randomly or in some other non-linear manner, rather than the hash of a single previous block in the blockchain. Each block header may alternatively or additionally include the hash of the entire parent block rather than just the hash of the parent block's header. Where each block header includes multiple hashes corresponding to different parent blocks or other headers, these hashes may be combined together into a Merkle root, like Figure 5 The hashes A 518 , B 520 , C 522 , D 524 , E 526 , F 528 , G 530 , and H 532 are the same.

[0128] For example, in Figure 6 In the DAG ledger, at least after the first two blocks are generated, the predetermined number is two. Figure 6 In a network DAG ledger of , arrows are used to indicate parent blocks. Block 610 includes a hash of the block headers of parent blocks 620 and 650. Block 620 includes a hash of the block headers of parent blocks 640 and 660. Block 630 includes a hash of the block headers of parent blocks 620 and 660. Block 640 includes a hash of the block headers of parent blocks 610 and 630. Block 650 includes a hash of the block headers of parent blocks 610 and 620. Block 660 includes a hash of the block headers of parent blocks 610 and 650. The resulting structure is a directed acyclic graph (DAG) of blocks, where each vertex block includes a hash of its parent vertex block rather than a linear stream of blocks as in a blockchain. A DAG ledger may sometimes be referred to as a "web," "tangle," or "hashgraph."

[0129] In some cases, the number of parent blocks in a DAG ledger is not strictly determined, but there is a predetermined minimum number of blocks, such as a dual-parent minimum and a single-parent minimum, meaning that each block has at least a predetermined minimum number of parent blocks. In some cases, each block in a DAG ledger may only identify only a single transaction instead of multiple transactions, and the Merkle root may therefore be abandoned and / or replaced with a hash of a single transaction. In other implementations, each block may identify multiple transactions associated with a predetermined time period as discussed herein.

[0130] Figure 7 A network environment showing different types of client devices participating in in-game transfers via a distributed blockchain ledger.

[0131] Although Figure 1A , Figure 1B and Figure 1CClient devices 110A-110F are shown as each being the same particular type of video game console, but they need not be identical. There may be small differences between different client devices 110, such as firmware, firmware versions, operating systems, operating system versions, hardware, hardware versions, or a combination thereof. For example, different client devices may include hard drives or flash memory chips with subtly or widely different storage capacities. Later-produced client devices 110 may include faster processors or additional cores. Some client devices 110 may include additional hardware that may be missing from other client devices (even if they are missing).

[0132] In addition, although Figure 1A , Figure 1B and Figure 1C Client devices 110A-110F are shown as each being the same particular type of video game console, but this need not be the case at all. Figure 7 Four client devices 110 are shown, including client device 110J as a laptop computer, client device 110K as a home video game console, client device 110L as a desktop computer, and client device 110M as a portable device / mobile device such as a smart phone, a tablet computing device, a media player device, a portable video game console, a wearable device, or a combination thereof. Figure 7 The client device 110 may communicate directly or via the network hardware 105, as described with respect to Figure 1A , Figure 1B As discussed in Figure C.

[0133] Figure 7 The client device 110 may run a game-specific blockchain ledger 125, such as Figure 1A This is particularly useful if the game is distributed on multiple platforms (multiple types of computing devices) or ported from one platform (one type of computing device) to one or more other platforms (multiple types of computing devices). Even so, the client device 110 need not be compatible with or able to play the video game to which the game-specific blockchain ledger 125 corresponds.

[0134] Figure 7 The client device 110 may run a platform-specific blockchain ledger 115, such as Figure 1BThis is particularly useful if the game is distributed on multiple platforms (multiple types of computing devices) or ported from one platform (one type of computing device) to one or more other platforms (multiple types of computing devices), thereby expanding the effective platform of the game to include platforms of multiple types of computing devices. Even so, the client device 110 need not be compatible with or able to play any video game associated with the platform to which the platform-specific blockchain ledger 115 corresponds.

[0135] The use of various client devices 110 may be useful to help relieve the burden on the video game console by allowing the remote server to take on some of the work of verifying transactions and generating blocks (if necessary). This may be particularly useful when new video game consoles are released to ensure that transactions can be verified in a timely manner even for the first few new video game consoles that attempt to conduct transactions using the blockchain ledger.

[0136] Figure 8 800 is a block diagram of an exemplary computing device 800 that can 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 circuits described herein may include at least one computing system 800, or may include a computing device 800 in a manner similar to that described herein. Figure 8 At least one component of the computing system 800 identified in . Figure 8 The computing system 800 includes one or more processors 810 and a memory 820. Each of the processors 810 may 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 a combination thereof. Each of the processors 810 may include one or more cores integrated into a single chip or distributed among multiple chips connected or coupled together. The memory 820 partially stores instructions and data for execution by the processor 810. The memory 820 may store executable code when in operation. Figure 8 The system 800 also includes a mass storage device 830 , a portable storage media drive 840 , an output device 850 , a user input device 860 , a graphics display 880 , and peripheral devices 880 .

[0137] Figure 8The components shown are depicted as being connected via a single bus 890. However, the components may be connected via one or more data transfer devices. For example, the processor unit 810 and memory 820 may be connected via a local microprocessor bus, and the mass storage device 830, peripheral devices 880, portable storage devices 840, and display system 880 may be connected via one or more input / output (I / O) buses.

[0138] Mass storage 830, which may be implemented using a magnetic disk drive or optical disk drive, is a non-volatile storage device used to store data and instructions for use by processor unit 810. In order to load system software into memory 820, mass storage 830 may store that software for implementing some aspects of the subject technology.

[0139] Portable storage device 840 operates in conjunction with a portable non-volatile storage medium such as a floppy disk, compact disk, or digital video disk to input data and code to the Figure 8 The computer system 800 of the present invention is configured to store data and code from the computer system 800. System software for implementing aspects of the subject technology may be stored on such portable media and input to the computer system 800 via the portable storage device 840.

[0140] The memory 820, the mass storage device 830, or the portable storage device 840 may store sensitive information, such as transaction information, health information, or encryption keys in some cases, and may encrypt or decrypt such information with the aid of the processor 810 in some cases. The memory 820, the mass storage device 830, or the portable storage device 840 may store, at least in part, instructions, executable code, or other data for execution or processing by the processor 810 in some cases.

[0141] Output device 850 may include, for example, communication circuitry for outputting data by wired or wireless means, display circuitry for displaying data via a display screen, audio circuitry for outputting audio via headphones or speakers, 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 display system 880. The printer may be an inkjet printer, a laser printer, a thermal printer, or some combination thereof. In some cases, output device circuitry 850 may allow data to be output via an audio jack / plug, a microphone jack / plug, a universal serial bus (USB) port / plug, Ports / plugs, Ethernet ports / plugs, Fiber optic ports / plugs, Dedicated wired ports / plugs, Wireless signal transmission, The output device 850 may include any port, plug, antenna, or any other component necessary for the types of communication listed above, such as a cellular subscriber identity module (SIM) card.

[0142] Input device 860 may include circuitry that provides a portion of a user interface. Input device 860 may include an alphanumeric keypad such as a keyboard or a pointing device such as a mouse, trackball, stylus, or cursor direction keys for entering alphanumeric and other information. Input device 860 may also include a touch-sensitive surface that is integrated with the display as in a touch screen or separate from the display as in a trackpad. The touch-sensitive surface may detect localized variable pressure or force detection in some cases. In some cases, the input device circuitry may allow input through an audio jack, a microphone jack, a Universal Serial Bus (USB) port / plug, Ports / plugs, Ethernet ports / plugs, Fiber optic ports / plugs, Dedicated wired ports / plugs, Wireless signal transmission, Low Energy (BLE) wireless signal transmission, Radio Frequency Identification (RFID) wireless signal transmission, Near Field Communication (NFC) wireless signal transmission, 802.11 Wi-Fi wireless signal transmission, cellular data network wireless signal transmission, radio wave signal transmission, microwave signal transmission, infrared signal transmission, visible light signal transmission, ultraviolet signal transmission, wireless signal transmission along the electromagnetic spectrum, or some combination thereof to receive data. Input device 860 may include any port, plug, antenna, or any other component necessary for the communication types listed above, such as a cellular SIM card.

[0143] The display device 880 may include a liquid crystal display (LCD), a plasma display, an organic light emitting diode (OLED) display, an electronic ink or "electronic paper" display, a projector-based display, a holographic display, or another suitable display device. The display system 880 receives text and graphical information and processes the information for output to the display device. The display system 880 may include multi-touch touch screen input capabilities, such as capacitive touch detection, resistive touch detection, surface acoustic wave touch detection, or infrared touch detection. Such touch screen input capabilities may or may not allow variable pressure or force detection.

[0144] Peripheral devices 880 may include any type of computer support device to add additional functionality to a computing system. For example, peripheral devices 880 may include a modem, a router, an antenna, a printer, a barcode 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.

[0145] Included in Figure 8 The components in computer system 800 are 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 known in the art. Figure 8 The computer system 800 may be a personal computer, a handheld computing device, a phone ("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 (e.g., 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 system 800 may in some cases be a virtual computer system executed by another computer system. The computer may also include different bus configurations, networking platforms, multi-processor platforms, etc. Various operating systems may be used, including Unix, Linux, Windows, Macintosh OS, Palm OS, Android, iOS, and other appropriate operating systems.

[0146] In some cases, the computer system 800 may be part of a multi-computer system that uses multiple computer systems 800, each for one or more specific tasks or purposes. For example, the multi-computer system may include multiple computer systems 800 that are communicatively coupled together via at least one of a personal area network (PAN), a local area network (LAN), a wireless local area network (WLAN), a metropolitan area network (MAN), a wide area network (WAN), or some combination thereof. The multi-computer system may also include multiple computer systems 800 from different networks that are communicatively coupled together via the Internet (also referred to as a "distributed" system).

[0147] Some aspects of the subject computing may be implemented in applications operable using a variety of devices. Non-transitory computer-readable storage media refers to any one or more media that participate in providing instructions to a central processing unit (CPU) for execution and may be used in memory 820, mass storage device 830, portable storage device 840, or some combination thereof. Such media may take various 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, floppy disks, flexible disks, hard disks, magnetic tapes, magnetic sheets / strips, any other magnetic storage media, flash memory, memristor memory, any other solid-state memory, compact disk read-only memory (CD-ROM) optical disks, rewritable compact disk (CD) optical disks, digital video disk (DVD) optical disks, Blu-ray disc (BDD) optical disks, holographic optical disks, another optical medium, secure digital (SD) card, micro secure digital (microSD) card, Memory Cards, smart card chips, (EMV) chip, subscriber identity module (SIM) card, 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 box or a combination thereof.

[0148] Various forms of transmission media may be involved in carrying one or more sequences of one or more instructions to the processor 810 for execution. The bus 890 carries the data to the system RAM or another memory 820, from which the processor 810 retrieves and executes the instructions. The instructions received by the system RAM or another memory 820 may optionally be stored on a fixed disk (mass storage device 830 / portable storage device 840) before or after execution by the processor 810. Various forms of storage may also be implemented, as well as implementing the necessary network interfaces and network technologies to implement various forms of storage.

[0149] Although the various flow charts provided and described above may show a specific order of operations performed by some embodiments of the subject technology, it should be understood that such an order is exemplary. Alternative embodiments may perform operations in a different order, combine certain operations, overlap certain operations, or some combination thereof.

[0150] The foregoing detailed description of the technology is 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 teachings. The described embodiments are selected so as to best explain the principles of the technology, its practical application and enable those skilled in the art to utilize the technology in various embodiments and with various modifications as appropriate for the particular use contemplated. It is intended that the scope of the technology be defined by the claims.

Claims

1. A method for playing a video game via a distributed architecture comprising a plurality of computing devices, the method include: tracking, within a game session of the video game in which a plurality of players of the video game play at least one tournament of the video game on a plurality of video game consoles via an online video game platform, a win history indicating respective win counts of the plurality of players in the at least one tournament, the online video game platform facilitating game session of the video game on the plurality of video game consoles; storing a distributed ledger associated with virtual assets associated with respective win counts of the plurality of players of the video game in the at least one tournament via the online video game platform, the distributed ledger comprising a plurality of blocks tracking the win histories; identifying a change in a win count of a player of the video game during the at least one tournament of the video game based on data associated with the gaming progress of the plurality of players in the video game in the at least one tournament via the online video gaming platform, wherein the player is one of the plurality of players; identifying an intended transaction corresponding to a transfer of an identified amount of a virtual asset from a transferor account to a transferee account, wherein the transfer of the identified amount of the virtual asset is associated with a change in a win count of the player of the video game during tracking of the at least one tournament of the video game; generating a new block, wherein the new block includes the expected transaction, wherein a header of the new block includes a hash of a leading block of the distributed ledger; and appending the new block to the plurality of blocks of the distributed ledger to update the win history tracked within the distributed ledger, wherein updating the win history tracked within the distributed ledger also modifies at least one counter in the video game that tracks at least one win count in the video game during the at least one tournament.

2. The method according to claim 1, in, The virtual asset is associated with at least one tournament prize, the at least one tournament prize being associated with a win in the at least one tournament.

3. The method according to claim 1, in, After appending the new block to the plurality of blocks of the distributed ledger, the virtual asset may be used by the player in the video game via the transferee account.

4. The method according to claim 1, further comprising: include: Verifying whether the intended transaction is valid is performed by identifying that the transferor account has at least the identified amount of the virtual asset based on at least one of the plurality of blocks in the distributed ledger.

5. The method according to claim 1, in, The new block includes one or more additional transactions in addition to the intended transaction.

6. The method according to claim 5, further comprising: include: A Merkle root is generated using the intended transaction and the one or more additional transactions, wherein the new block header also includes the Merkle root.

7. The method according to claim 5, further comprising: include: Verifying that none of the one or more additional transactions conflicts with the intended transaction by identifying that the transferor account will retain a non-negative amount of the virtual asset after completion of the intended transaction and the one or more additional transactions.

8. The method according to claim 1, in, The transferor account is associated with the gaming alliance.

9. The method according to claim 1, in, The transferor account is associated with the video game.

10. The method according to claim 1, in, The transferor account is associated with at least one video game console of the plurality of video game consoles running the video game.

11. The method according to claim 1, in, The transferor account is associated with the online video gaming platform running the at least one tournament.

12. The method according to claim 1, in, The transferor account is associated with the second player.

13. A distributed computing system for playing a video game, the distributed computing system include: a memory storing instructions; Network communication transceiver; as well as one or more processors that execute instructions stored in the memory, wherein the one or more processors execute the instructions to: tracking, within a game session of the video game in which a plurality of players of the video game play at least one tournament of the video game on a plurality of video game consoles via an online video game platform, a win history indicating respective win counts of the plurality of players in the at least one tournament, the online video game platform facilitating game session of the video game on the plurality of video game consoles; storing a distributed ledger associated with virtual assets associated with respective win counts of the plurality of players of the video game in the at least one tournament via the online video game platform, the distributed ledger comprising a plurality of blocks tracking the win histories; identifying a change in a win count of a player of the video game during the at least one tournament of the video game based on data associated with the gaming progress of the plurality of players in the video game in the at least one tournament via the online video gaming platform, wherein the player is one of the plurality of players; identifying an intended transaction corresponding to a transfer of an identified amount of a virtual asset from a transferor account to a transferee account, wherein the transfer of the identified amount of the virtual asset is associated with a change in a win count of the player of the video game during tracking of the at least one tournament of the video game; generating a new block, the new block including the expected transaction, wherein the new block header includes a hash of a leading block of the distributed ledger, and appending the new block to the plurality of blocks of the distributed ledger to update the win history tracked within the distributed ledger, wherein updating the win history tracked within the distributed ledger also modifies at least one counter in the video game that tracks at least one win count in the video game during the at least one tournament.

14. The distributed computing system according to claim 13, It is characterized in that The virtual asset is associated with at least one tournament prize, the at least one tournament prize being associated with a win in the at least one tournament.

15. The distributed computing system according to claim 13, in, After appending the new block to the plurality of blocks of the distributed ledger, the virtual asset may be used by the player in the video game via the transferee account.

16. A method for playing a video game via a distributed architecture comprising a plurality of computing devices, the method include: tracking, within a game session of the video game in which a plurality of players of the video game play at least one tournament of the video game on a plurality of video game consoles via an online video game platform, a win history indicating respective win counts of the plurality of players in the at least one tournament, the online video game platform facilitating game session of the video game on the plurality of video game consoles; storing a distributed ledger associated with virtual assets associated with respective win counts of the plurality of players of the video game in the at least one tournament via the online video game platform, the distributed ledger comprising a plurality of blocks tracking the win histories; identifying a change in a win count of a player of the video game during the at least one tournament of the video game based on data associated with the gaming progress of the plurality of players in the video game in the at least one tournament via the online video gaming platform, wherein the player is one of the plurality of players; identifying an intended transaction corresponding to a transfer of an identified amount of a virtual asset from a transferor account to a transferee account, wherein the transfer of the identified amount of the virtual asset is associated with a change in a win count of the player of the video game during tracking of the at least one tournament of the video game; generating a message identifying the intended transaction; sending the message to one or more of the plurality of computing devices; receiving a new block, the new block including the expected transaction, wherein a header of the new block includes a hash of a preceding block of the distributed ledger; and appending the new block to the plurality of blocks of the distributed ledger to update the win history tracked within the distributed ledger, wherein updating the win history tracked within the distributed ledger also modifies at least one counter in the video game that tracks at least one win count in the video game during the at least one tournament.

Images