Tracking unique in-game digital assets with tokens on a distributed ledger

Abstract

The digital asset may be an in-game digital asset, such as an in-game item or character. The digital asset may be a video game digital media asset, such as a video clip or image, that represents a gameplay moment of the video game. The digital asset is created and a distributed ledger that tracks the history of the digital asset is created and stored across devices. A unique token for the digital asset may include a unique identifier and metadata that identifies the properties of the digital asset. Changes to the properties of the digital asset, such as ownership, appearance, or metadata, may be identified in a request to update the history. A new block may be generated and added to the distributed ledger that identifies the changes to the history of the digital asset. The new block may include a hash of the previous block.

Description

[Technical field]

[0001] The present technology relates to tracking digital assets. More particularly, the present technology can provide various techniques for tracking the creation, use, modification, and / or transfer of digital assets created within and / or based on gameplay of a video game. [Background technology]

[0002] Many people find meaning in owning or using a unique physical item associated with a respected celebrity or activity. For example, fans of the accomplished baseball player Babe Ruth, or baseball in general, often seek to purchase and own a baseball autographed by Babe Ruth, a baseball hit by Babe Ruth in an important baseball game, a trading card depicting Babe Ruth, etc.

[0003] Video gaming is an increasingly popular activity around the world. Skilled players of multiplayer video games often gain popularity in multiplayer matches or tournaments that are live-streamed or otherwise broadcast to large audiences. Similarly, famous players often live-stream or otherwise broadcast their gameplay of single-player or multiplayer video games, for example, players performing or attempting speed runs, in-game challenges, multiplayer matches, or other gameplay activities. Some players, especially those with great skill or charisma, can garner large followings of devoted fans, similar to the fans of famous athletes, singers, actors, or other celebrities. Summary of the Invention [Problem to be solved by the invention]

[0004] In some video games, players may use digital assets during gameplay. Such digital assets may include, for example, a particular character, costume, or item. In conventional video games, multiple instances of the same in-game item exist within the same copy of the video game and / or within different copies of the video game. These different instances of the same in-game item are traditionally fungible because they are indistinguishable from one another. For example, even if a particular in-game item is hard to come by within a video game, the in-game item is represented within the video game as a code string that is identical to the representation of other instances of the same in-game item within the same video game and / or other copies of the same video game. Thus, in conventional video games, no digital asset is unique compared to other instances of the same in-game item. As a result, in conventional video games, there is no way to know, track, or authenticate the history of a particular instance of an in-game item. For example, in conventional video games, there is no way to distinguish a particular instance of an in-game item that a famous player of the video game used to win a famous tournament from other instances of the in-game item. [Means for solving the problem]

[0005] Aspects of the present technology include systems and methods for the creation, modification, tracking, authentication, and / or transfer of unique digital assets associated with a video game. The digital assets may be in-game digital assets, such as in-game items or characters. The digital assets may be video game digital media assets, such as video clips, images, or audio clips, that include media representations of gameplay moments of the video game. Digital assets are created and a distributed ledger that tracks the history of the digital assets is created and stored across multiple devices. A unique token can be created for the digital asset using a unique identifier for the digital asset and metadata that identifies the properties of the digital asset. Pending or completed changes to the properties of the digital asset, such as ownership, appearance, or metadata, can be identified as a request to update the history of the digital asset. A new block can be generated and added to the distributed ledger that identifies the changes to the history of the digital asset. The new block can include one or more hashes of one or more previous blocks in the distributed ledger.

[0006] In one example, a system for tracking an in-game digital asset is provided. The system includes a memory and one or more processors (e.g., implemented in a circuit) coupled to the memory. The one or more processors are configured and capable of: receiving a request to update a history of the in-game digital asset, where the in-game digital asset is usable in a video game; identifying a distributed ledger that stores a token representing the in-game digital asset, where the distributed ledger includes a plurality of blocks that store at least a portion of the history of the in-game digital asset represented as interactions with the token; automatically generating a new block of the distributed ledger in response to receiving the request to update the history of the in-game digital asset, where the new block includes a payload identifying one or more updates to the history of the in-game digital asset represented as one or more new interactions with the token, where the new block also includes a hash of at least a portion of a previous block of the distributed ledger; and adding the new block to the plurality of blocks of the distributed ledger.

[0007] In another example, a method for tracking an in-game digital asset is provided. The method includes receiving a request to update a history of an in-game digital asset, where the in-game digital asset is usable in a video game; identifying a distributed ledger that stores a token representing the in-game digital asset, where the distributed ledger includes a plurality of blocks that store at least a portion of the history of the in-game digital asset represented as an interaction with the token; automatically generating a new block of the distributed ledger in response to receiving the request to update the history of the in-game digital asset, where the new block includes a payload that identifies one or more updates to the history of the in-game digital asset represented as one or more new interactions with the token, and where the new block also includes a hash of at least a portion of a previous block of the distributed ledger; and adding the new block to the plurality of blocks of the distributed ledger. In another example, a system for tracking an in-game digital asset is provided, the system including means for performing each of the operations of the method. In another example, a non-transitory computer-readable medium is provided having instructions stored thereon that, when executed by one or more processors, cause the one or more processors to perform the method.

[0008] In one example, a system for tracking in-game digital assets is provided. The system includes a memory and one or more processors (e.g., implemented in a circuit) coupled to the memory. The one or more processors are configured and capable of: receiving a request to update a history of a video game digital media asset, where the video game digital media asset includes a media representation of one or more moments of gameplay of a video game; identifying a distributed ledger that stores tokens representing the video game digital media asset, where the distributed ledger includes a plurality of blocks that store at least a portion of the history of the video game digital media asset represented as interactions with the token; automatically generating a new block of the distributed ledger in response to receiving the request to update the history of the video game digital media asset, where the new block includes a payload that identifies one or more updates to the history of the video game digital media asset represented as one or more new interactions with the token, and where the new block also includes a hash of at least a portion of a previous block of the distributed ledger; and adding the new block to the plurality of blocks of the distributed ledger.

[0009] In another example, a method for tracking an in-game digital asset is provided, the method including: receiving a request to update a history of a video game digital media asset, the video game digital media asset including a media representation of one or more moments of gameplay of a video game; identifying a distributed ledger that stores a token representing the video game digital media asset, the distributed ledger including a plurality of blocks that store at least a portion of the history of the video game digital media asset represented as interactions with the token; automatically generating a new block of the distributed ledger in response to receiving the request to update the history of the video game digital media asset, the new block including a payload that identifies one or more updates to the history of the video game digital media asset represented as one or more new interactions with the token, the new block also including a hash of at least a portion of a previous block of the distributed ledger; and adding the new block to the plurality of blocks of the distributed ledger. In another example, an apparatus for tracking an in-game digital asset is provided, the apparatus including means for performing each of the operations of the method. In another example, a non-transitory computer-readable medium is provided having instructions stored thereon that, when executed by one or more processors, cause the one or more processors to perform the method. [Brief description of the drawings]

[0010] [Figure 1] FIG. 1 is a block diagram illustrating an example of a network environment in which a system for tracking digital assets related to a video game using a distributed ledger may be implemented, according to aspects of the present disclosure. [Figure 2A] FIG. 1 is a block diagram illustrating an example of a network environment in which a system for binding object data from a universal data system to media content may be implemented in accordance with aspects of the present disclosure. [Figure 2B] 1 is a conceptual diagram illustrating an example table of various objects and associated events according to an aspect of the present disclosure. [Diagram 3] FIG. 1 is a block diagram illustrating three successive blocks of a distributed ledger that may be used to track digital assets related to a video game, according to an aspect of the disclosure. [Figure 4] FIG. 1 is a block diagram illustrating an example of a token that may be non-fungible and that may represent a digital asset associated with a video game that is tracked on a distributed ledger, according to an aspect of the disclosure. [Figure 5A] FIG. 1 is a conceptual diagram illustrating an example of a video game interface in which a player character is in an environment with several in-game items, according to aspects of the present disclosure. [Figure 5B] FIG. 5B is a conceptual diagram illustrating an example of a video game interface highlighting an in-game item displayed in the video game interface of FIG. 5A, according to an aspect of the present disclosure. [Figure 6A] FIG. 13 is a conceptual diagram illustrating an example of an item customization interface that identifies various instances of an in-game item, each of which includes different customizations, in accordance with aspects of the present disclosure. [Figure 6B] FIG. 13 is a conceptual diagram illustrating an example of an item history interface that identifies the history of a particular instance of an in-game item, according to aspects of the present disclosure. [Figure 7A] 1 is a conceptual diagram illustrating an example of a video game interface in which a first player character corresponding to a first user encounters a second player character corresponding to a second user, according to aspects of the present disclosure. [Figure 7B] 1 is a conceptual diagram illustrating an example of a player list interface identifying users whose corresponding player characters have encountered a first player character corresponding to the first user, according to aspects of the present disclosure. [Figure 8A] FIG. 1 is a conceptual diagram illustrating an example of a marketplace interface for trading in-game digital assets, according to an aspect of the present disclosure. [Figure 8B] FIG. 1 is a conceptual diagram illustrating an example of a marketplace interface for trading video game digital media assets according to an aspect of the present disclosure. [Figure 9] FIG. 1 is a block diagram illustrating an example of a network environment for managing digital assets related to a video game. [Figure 10A] FIG. 1 is a conceptual diagram illustrating the creation of a smart contract and entering the smart contract into a distributed ledger, according to an aspect of the present disclosure. [Figure 10B] FIG. 1 is a conceptual diagram illustrating execution of a smart contract, according to an aspect of the present disclosure. [Figure 11] FIG. 1 is a block diagram illustrating a directed acyclic graph (DAG) ledger configured to track digital assets associated with a video game, according to an aspect of the present disclosure. [Figure 12] FIG. 1 is a block diagram illustrating an example of a network environment in which a video game digital media importance engine may be implemented, according to aspects of the present disclosure. [Figure 13] FIG. 13 is a block diagram illustrating an example of a pointer element that can indicate to a user digital assets, associated tokens, and / or an associated distributed ledger associated with a video game, according to an aspect of the present disclosure. [Figure 14A] FIG. 1 is a flow diagram illustrating operations for tracking in-game digital assets using a distributed ledger according to aspects of the present disclosure. [Figure 14B] FIG. 1 is a flow diagram illustrating operations for tracking video game digital media assets using a distributed ledger according to aspects of the disclosure. [Figure 15] 1 illustrates an example electronic entertainment system that can be used for media-object binding according to an embodiment of the present disclosure and displays real-time play data of streaming media based on one or more objects displayed thereon. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0011] The following detailed description is intended as a description of various configurations of the subject technology, and is not intended to represent the only configurations in which the technology may be practiced. The accompanying drawings are incorporated in this specification and constitute a part of the detailed description. The detailed description includes specific details to provide a more thorough understanding of the technology. However, it is clear and apparent that the technology is not limited to the specific details set forth herein, and may be practiced without these details. In some instances, structures and components are shown in block diagram form in order to avoid obscuring the concepts of the subject technology.

[0012] Techniques and technologies are described for the creation, modification, tracking, authentication, and / or transfer of unique digital assets related to video games. The digital assets may be in-game digital assets, such as in-game items or characters. The digital assets may be video game digital media assets, such as video clips, images, or audio clips, that include media representations of gameplay moments of the video game. Digital assets are created and a distributed ledger that tracks the history of the digital assets is created and stored across multiple devices. A unique token can be created for the digital asset using a unique identifier for the digital asset and metadata that identifies properties of the digital asset. Pending or completed changes to properties of the digital asset, such as ownership, appearance, or metadata, can be identified as a request to update the history of the digital asset. A new block can be generated and added to the distributed ledger that identifies the changes to the history of the digital asset. The new block can include one or more hashes of one or more previous blocks in the distributed ledger.

[0013] The techniques and technologies described herein extend the capabilities of digital assets associated with video games, and the capabilities of systems that create and manage such digital assets, by converting digital assets associated with video games from fungible to non-fungible. The techniques and technologies described herein extend the capabilities of digital assets associated with video games, and the capabilities of systems that create and manage such digital assets, by tracking the history of the digital assets. Tracking the history of a digital asset can include, for example, tracking when, how, and by whom the digital asset was created, used, modified, loaned, borrowed, sold, purchased, licensed, licensed, replaced, exchanged, and / or other actions were taken.

[0014] 1 illustrates an example of a network environment 100 in which a system for tracking digital assets related to a video game using a distributed ledger may be implemented, according to aspects of the present disclosure. The network environment 100 may include one or more interactive content servers 110 providing streaming content (e.g., interactive videos, podcasts, video game content, etc.), one or more platform servers 140, one or more user devices 130, one or more data structures 140, and one or more distributed ledgers 150. The one or more distributed ledgers 150 may be stored across a distributed network 115, which may include one or more interactive content servers 110, one or more platform servers 140, one or more user devices 130, one or more data structures 140, or a combination thereof.

[0015] The interactive content server 110 may maintain, stream, and host interactive media available for streaming on user devices 130 over a communications network. Such an interactive content server 110 may be implemented in the cloud (e.g., one or more cloud servers). Each media may include one or more object data sets that may be available for participation by a user (e.g., viewing or interacting with an activity). Data regarding objects shown in the media may be stored in object files 216 ("object files") by the interactive content server 110, the platform server 140, and / or the user devices 130.

[0016] The platform server 140 may be responsible for communication with the different interactive content servers 110, data structures 140, and user devices 130. Such platform servers 140 may be implemented on one or more cloud servers. The interactive content server 110 may communicate with multiple platform servers 140, while the media interactive content server 110 may be implemented on one or more platform servers 140. The platform server 140 may also execute instructions to, for example, receive a user request from a user to stream streaming media (i.e., video games, activities, videos, podcasts, user-generated content ("UGC"), publisher content, etc.). The platform server 140 may further execute instructions to, for example, stream streaming media content titles. Such streaming media may have at least one object set associated with at least a portion of the streaming media. Each set of object data may have data regarding an object displayed during at least a portion of the streaming media (e.g., activity information, zone information, actor information, mechanic information, game media information, etc.).

[0017] The streaming media and at least one associated object data set may be provided by an application programming interface (API) 160 that enables various types of interactive content servers 110 to communicate with different platform servers 140 and different user devices 130. The API 160 may be specific to the particular computer programming language, operating system, protocol, etc. of the interactive content server 110 providing the streaming media content title, the platform server 140 providing the media and at least one associated object data set, and the user device 130 receiving it. In a network environment 100 that includes multiple different types of interactive content servers 110 (or platform servers 140 or user devices 130), there may be a corresponding number of APIs 160 as well.

[0018] User device 130 may include multiple different types of computing devices. For example, user device 130 may include any number of different gaming consoles, mobile devices, laptops, and desktops. In another example, user device 130 may be implemented in the cloud (e.g., one or more cloud servers). Also, such a user device 130 may be, but is not limited to, a memory card or disk drive appropriate for downloaded services, and may be configured to access data from other storage media. Such a device 130 may include standard hardware computing components such as, but not limited to, a network interface, a media interface, a non-transitory computer-readable storage (memory), and a processor that executes instructions that may be stored in the memory. These user devices 130 may also be executed using various different operating systems (e.g., iOS, Android (registered trademark)), applications, or computing languages (e.g., C++, Java (registered trademark)Script). Exemplary user device 130 is described in detail herein with respect to FIG. 15.

[0019] Data structures 140 may include, for example, one or more databases (DB), one or more distributed hash tables (DHT), one or more Interplanetary File Systems (IPFS), one or more Interplanetary Link Data (IPLD) structures, one or more tables, one or more hash tables, one or more heaps, one or more trees, one or more lists, one or more arrays, one or more array lists, one or more dictionaries, one or more matrices, or combinations thereof. Data structures 140 may be stored on platform servers 140, on interactive content servers 110, on any of servers 218 (shown in FIG. 2A), across one or more different servers, on a single server, across different servers, on any of user devices 130, within distributed ledger 150, on a device identified by a network location identified by a pointer (e.g., uniform resource identifier) ​​stored in distributed ledger 150, or combinations thereof. Such data structures 140 may store digital assets related to a video game, such as streaming media, portions thereof, and / or associated set(s) of object data. Such streaming media may depict one or more objects (e.g., activities) in which a user may participate, and / or UGC (e.g., screenshots, videos, commentaries, mashups, etc.) created by peers, publishers of the media content titles, and / or third-party publishers. Portions of the streaming media may include images, video clips, audio clips, or combinations thereof. Such UGC may include metadata for searching such UGC. Such UGC may also include information about the media and / or peers. Such peer information may be derived from data collected during peers' interactions with objects of an interactive content title (e.g., video games, interactive books, etc.) and may be "bound" to and stored with the UGC.Such binding extends the UGC because the UGC can deep link (e.g., directly initiate) to the object, provide information about the object and / or peers of the UGC, and / or allow the user to interact with the UGC. One or more user profiles may also be stored in data structure 140. Each user profile may include information about a user (e.g., activities and / or user progress within a media content title, a user ID, the user's game character, etc.) and may be associated with media.

[0020] In some examples, objects and / or object files 216 are examples of digital assets associated with a video game that are tracked using one or more of the distributed ledger 150. In some examples, pieces of media, such as video clips or images or audio clips of one or more moments of gameplay, are examples of digital assets associated with a video game that are tracked using one or more of the distributed ledger 150. Pieces of media may be generated, recorded, and / or streamed using the interactive content server 110, the platform server 140, and / or the user device 130.

[0021] In some examples, the distributed ledger 150 may be public. In some examples, the distributed ledger 150 may be private. In some examples, the distributed ledger 150 may be partially public and partially private. In some examples, the distributed ledger 150 may be controlled by and limited to use for a single video game. In some examples, the distributed ledger 150 may be controlled by and limited to use for a set of video games, such as a particular video game series. In some examples, the distributed ledger 150 may be controlled by and limited to use for a single video game console or video game platform. In some examples, the distributed ledger 150 may be controlled by and limited to use for a set of video game consoles or video game platforms. In some examples, the set of video game consoles or video game platforms may be associated with a single manufacturer, device type, form factor, operating system (OS), or combinations thereof. For example, the distributed ledger 150 may be controlled by and restricted for use with one or more Sony® platforms and / or one or more Sony® PlayStation® platforms corresponding to one or more Sony® devices, such as a Sony® PlayStation4®, a Sony® PlayStation5®, a Sony® PlayStation® Vita®, another Sony® PlayStation® portable gaming console, another Sony® PlayStation® home gaming console, a Sony® PlayStationVR® virtual reality (VR) system, a Sony® PlayStationTV® home entertainment system, a Sony® tablet, a Sony® mobile handset, or a combination thereof.In some examples, a set of video game consoles or video game platforms may include video game consoles or video game platforms associated with multiple manufacturers, device types, form factors, operating systems (OS), or combinations thereof, enabling, for example, cross-platform support, cross-device type support, cross-OS support, or combinations thereof.

[0022] 2A is a block diagram illustrating an example of a network environment 200 in which a system for binding object data from a universal data system to media content according to aspects of the disclosure can be implemented. In the example network environment 200 of FIG. 2A, an example console 228 (e.g., a user device 130) and example servers 218 (e.g., a streaming server 220, an activity feed server 224, a UGC server 232, and an object server 226) are shown. The console 228 may be implemented in the platform server 140, a cloud server, or any of the servers 218. The console 228 may further include a content recorder 202 and an object recorder 210, described in more detail below, through which content (e.g., media) may be recorded and / or output via the console 228. A variety of interactive content titles 230 may be executed on the console 228. Alternatively or in addition, the content recorder 202 may be implemented in the platform server 140, a cloud server, or any of the servers 218. Such a content recorder 202 may receive content (e.g., media) from an interactive content title 230 (e.g., interactive content source server 110) and record it in a content ring buffer 208. Such a ring buffer 208 may store multiple content segments (e.g., v1, v2, and v3), a start time for each segment (e.g., V1_START_TS, V2_START_TS, V3_START_TS), and an end time for each segment (e.g., V1_END_TS, V2_END_TS, V3_END_TS). Such segments may be stored by a console 228 as a media file 212 (e.g., MP4, WebM, etc.). Such media files 212 (e.g., portions of streaming media) may be uploaded to a streaming server 220 for storage and subsequent streaming or use, although the media files 212 may be stored on any server, cloud server, any console 228, or any user device 130.The media files 212 may be uploaded periodically and / or in real-time or near real-time. The start and end times for each such segment may be stored by the console 228 as a content timestamp file 214. Such content timestamp file 214 may also include a stream ID that matches the stream ID of the media file 212, thereby associating the content timestamp file 214 with the media file 212. Such content timestamp file 214 may be uploaded and stored on the activity feed server 224 and / or the UGC server 232, although the content timestamp file 214 may be stored on any server, cloud server, any console 228, or any user device 130.

[0023] In some examples, the media file 212 may be converted by the console 228 and / or the server 218 into a non-fungible video game digital media asset using a non-fungible token, such as the token 400 of FIG. 4. The asset may be stored in one or more of the distributed ledgers 150 and its history tracked across one or more of the distributed ledgers 150. The token corresponding to the media file 212 may include metadata associated with the streaming service 220, the content timestamp file 214, the activity feed 224, the UGC server 232, and / or the object server 226. In some examples, at least a portion of the actions or activities identified in the activity feed 224 and / or the content timestamp file 214 may be identified in the history of the non-fungible video game digital media asset tracked in the distributed ledger 150.

[0024] At the same time that the content recorder 202 receives and records content from the interactive content title 230, the object library 204 receives object data from the interactive content title 230, and the object recorder 206 tracks the object data to determine the start and end times of the objects. Such object data may be uploaded periodically and / or in real-time or near real-time. The object library 204 and the object recorder 206 may be implemented on the platform server 140, a cloud server, or any server 218. When the object recorder 206 detects the start of an object, it receives the object data (e.g., data if the object is an activity, user interaction with the activity, activity ID, activity start time, activity end time, activity result, activity type, etc.) from the object library 204 and records this activity data (e.g., ActivityID1, START_TS; ActivityID2, START_TS; ActivityID3, START_TS) in the object ring buffer 210. Such activity data recorded in the object ring buffer 210 may be stored in an object file 216. Such object file 216 may also include activity start time, activity end time, activity ID, activity result, activity type (e.g., competitive match, quest, task, etc.), user or peer data associated with the activity. For example, the object file 216 may store data regarding items used during the activity. Such object file 216 may be stored on the object server 226, although the object file 216 may be stored on any server, cloud server, any console 228, or any user device 130.

[0025] Such object data (e.g., object files 216) may be associated with content data (e.g., media files 212 and / or content timestamp files 214). In one example, the object server 226 stores and associates the content timestamp files 214 with the object files 216 based on a match between the streaming ID of the content timestamp files 214 and the corresponding activity ID of the object files 216. In another example, the object server 226 may store the object files 216 and receive queries for the object files 216 from the UGC server 232. Such queries may be performed by searching for an activity ID of the object files 216 that matches the streaming ID of the content timestamp files 214 sent with the query. In yet another example, queries of the stored content timestamp files 214 may be performed by matching the start and end times of the content timestamp files 214 with the start and end times of the corresponding object files 216 sent with the query. Such object files 216 may also be associated with matching content timestamp files 214 by the UGC server 232, although this association may be performed by any server, cloud server, any console 228, or any user device 130. In another example, the object files 216 and content timestamp files 214 may be associated by the console 228 during the creation of each file 216, 214.

[0026] In some examples, objects identified by the object library 204, object recorder 206, object ring buffer 210, object file 216, and / or object server 226 may be converted by the console 228 and / or server 218 into a non-fungible in-game digital asset using a non-fungible token, such as token 400 of FIG. 4. The asset may be stored in one or more of the distributed ledgers 150 and its history tracked across one or more of the distributed ledgers 150. A token corresponding to a media file 212 may include metadata associated with the object recorder 206, object ring buffer 210, object file 216, object server 226, UGC server 232, streaming service 220, content timestamp file 214, and / or activity feed 224. In some examples, at least a portion of the actions or activities identified in the activity feed 224, content timestamp file 214, and / or object file 216 may be identified in the history of the non-fungible in-game digital asset tracked in the distributed ledger 150.

[0027] FIG. 2B is a conceptual diagram illustrating an example table of various objects and associated events, according to an aspect of the disclosure. As shown in the example table 250 of FIG. 2B, such object data (e.g., object files 216) may be associated with event information related to activity availability changes and may be associated with other objects having associated object information. Media-object binding may form telemetry between objects displayed in at least a portion of the streaming media and the streaming media. For example, such object data may be activity data files 251, zone data files 252, actor data files 254, mechanic data files 256, game media data files 258, and other gameplay related data files.

[0028] Such activity data files 251 (e.g., object files 216) may be classified as in-progress, open-ended, or competitive. Such activity data files 251 may include optional properties such as a more detailed description of the activity, an image associated with the activity, if the activity is available to the player before starting the game, whether completion of the activity is required to complete the game, whether the activity can be played repeatedly within the game, whether there are nested tasks or associated child activities, etc. Such activity data files 251 may include an activity availability change event that may indicate a list or array of activities currently available to the player. For example, this may be used to determine which activities to display in the game plan.

[0029] Such a zone data file 252 may indicate an area of ​​the relevant game world with a single coordinate system, and the zone may have a 2D map associated with it and may be used to display locations on the zone. If applicable, each zone may include a zone ID and a short, localizable name for the zone. Such a zone data file 252 may be associated with a view projection matrix (4x4) to convert from 3D world coordinates to 2D map locations. Such a zone data file 252 may be associated with position change events indicating updates to the player's current in-game location. Such position change events may be posted periodically or whenever the player's in-game location has changed significantly. The platform server 140 may store the latest values ​​in a "state". Such a zone data file 252 may include the x, y, z location of the player's character within the zone, and a, b, c vectors indicating the player's character's orientation or direction. Such zone data files 252 may be associated with activity start events and / or activity end events, where in the case of activity end events, a completion, failure, or abandon outcome may be associated with the activity (eg, activity ID).

[0030] Such actor data files 254 may be associated with entities with in-game behaviors, may be player controllers, or may be game controlled, and may change dynamically during gameplay. Such actor data files 254 may include the actor's actor ID, the actor's localizable name, the actor's image, and / or a brief description of the actor. Such actor data files 254 may be associated with an actor selection event that indicates that the player's selected actor(s) have changed. The selected actor(s) may represent the actor the player is controlling in the game, and may be displayed in the player's profile and other spaces via the platform server 140. Multiple actors may be selected at a time, and each game may replace the list of actors when save data is loaded.

[0031] Such mechanic data files 256 may be associated with items, skills, or effects that may be used by a player or game to affect gameplay (e.g., bows, arrows, stealth attacks, fire damage) and may exclude items that do not affect gameplay (e.g., collectibles). Such mechanic data files 256 may include the mechanic ID of the mechanic, the short name of the mechanic, an image of the mechanic, and / or a brief description of the mechanic. Such mechanic data files 256 may be associated with a mechanic availability change event that indicates that a mechanic available to the player has changed. Available may mean that the mechanic is available to the player in the game world, but the player may need to take some steps to get it in their inventory (e.g., buy from a shop, receive from the world) before it can be used. Each game may replace its list of mechanics when loading save data.

[0032] Such mechanic data files 256 may be associated with a mechanic inventory change event that indicates that a player's inventory has changed. Inventory may refer to mechanics that are immediately available to a player without the need to take additional steps in the game before using the mechanic. Inventory information is used to estimate a player's readiness for various activities that may be transferred to the platform server 140. A game may replace the list of mechanic inventory when loading a save. Cooldown mechanics may be considered part of the inventory. Mechanic counts with any non-zero value (e.g., ammo, recovery points, etc.) may be treated as "in inventory". Inventory mechanics may be considered a subset of available mechanics.

[0033] Such mechanic data files 256 may be associated with a mechanic use event indicating that a mechanic has been used by or against a player and may be used to display as a mechanic use in a UGC context. Such mechanic data files 256 may include a list or sequence of mechanics used (e.g., fire arrow, fire damage), or whether the initiator is a player, whether the mechanic was used by or against a player, etc. Such mechanic data files 256 may include an initiator actor ID, a current zone ID of the initiator actor, and / or a current x, y, z position of the initiator actor. Such mechanic data files 256 may be associated with a mechanic impact event indicating that a mechanic has affected gameplay (e.g., an arrow hits an enemy) and may be used to display a mechanic image in a UGC context. Mechanic use and mechanic image events may not be linked. Such a mechanics data file 256 may include an initiator action ID, the initiator actor's current zone ID, the initiator actor's current x, y, z position, the target actor ID, the target actor's current zone ID, the target actor's current x, y, z position, and a mitigation mechanic that may mitigate the initiator mechanic.

[0034] Such game media data files 258 may include the game media ID of the game media, a localizable name for the game media, the media format (e.g., image, audio, video, text, etc.), the category or type of media (cutscene, audio log, poster, developer commentary, etc.), a URL or server provisioned media file, and / or whether the game media is associated with a particular activity. Such game media data files 258 may be associated with a game media start event, which indicates that a particular piece of game media has just started in the game, and a game media end event, which indicates that a particular piece of game media has ended.

[0035] In some examples, the object data files 216, the activity data files 251, the zone data files 252, the actor data files 254, the mechanic data files 256, and / or the game media data files 258 may be converted into a non-fungible in-game digital asset using a non-fungible token, such as the token 400 of FIG. 4. The asset is stored in one or more of the distributed ledgers 150 and its history is tracked across one or more of the distributed ledgers 150. The token may include metadata associated with the object data files 216, the activity data files 251, the zone data files 252, the actor data files 254, the mechanic data files 256, and / or the game media data files 258. In some examples, at least some of the events identified in table 250 that are associated with at least one of object data files 216, activity data files 251, zone data files 252, actor data files 254, mechanic data files 256, and / or game media data files 258 may be identified in the history of non-fungible in-game digital assets tracked in distributed ledger 150.

[0036] 3 is a block diagram illustrating three successive blocks of a blockchain ledger 300 that may be used to track digital assets related to a video game, according to an embodiment of the present disclosure. Three blocks of the blockchain ledger 300 are shown in FIG. 3, including block A 305, block B 335, and block C 365.

[0037] Each block includes a block header 310 / 340 / 370 and a list of one or more payloads 330 / 360 / 390. In some examples, the block header 310 / 340 / 370 includes a hash 315 / 345 / 375 of a previous block and / or a hash 310 / 340 / 370 of the block header of the 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 similarly includes a hash 345 of the header 310 of block A 305. The header 310 of block A 305 similarly includes a hash 315 of the header (not shown) of a previous block (not shown) that precedes block A 305 in the blockchain 300. The inclusion of the hash of the previous block's header secures the blockchain ledger 300 by preventing any block of the blockchain 300 from being modified after the block is entered into the blockchain 300, since if a particular block is altered, the hash 315 / 345 / 375 of its block header in the next block will be incorrect. Furthermore, if the hash of its block header is modified in the next block, the hash 315 / 345 / 375 of the next block header will be incorrect in the block after the next block, and so on. A validating device can verify that a block has not been modified by computing the hash of the block and / or block header and then comparing the computed hash to the stored hash 315 / 345 / 375 stored in the next block. In some distributed ledgers, such as the distributed acyclic graph (DAG) ledger 1100 of FIG. 11, the block header 310 / 340 / 370 can include hashes of multiple previous blocks and / or hashes of the block headers of multiple previous blocks.

[0038] The block header 310 / 340 / 370 of each block may include a Merkle root 320 / 350 / 380. The Merkle root 320 / 350 / 380 may be generated based on the hash of each of the tokens, transactions, smart contracts, and / or other elements identified in the payload 330 / 360 / 390 of that block. Any attempt to modify the payload after the block has been entered will change the Merkle root. A validating device may verify that the payload(s) 330 / 360 / 390 have not been modified by calculating the Merkle root and then comparing the calculated Merkle root to the stored Merkle root 320 / 350 / 380 stored in the block header 310 / 340 / 370. Changing the payload 330 / 360 / 390 and / or the Merkle root 320 / 350 / 380 will also change the hash of the block and / or the hash of the block header, and the value will be stored in the next block as the hash 315 / 345 / 375. Each payload in each block may contain one or more tokens, one or more transactions, one or more smart contracts, other content, or any combination thereof.

[0039] 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, a timestamp for the validation of each payload, a timestamp for the creation of the block, a timestamp for the entry of the block into the blockchain ledger 300, a timestamp for the request to create the block, a difficulty target value (e.g., an adjustment to the mining difficulty), one or more randomized nonce values, a counter identifying the number of nonce attempts, the title of the blockchain ledger 300, an identifier for what the blockchain ledger 300 is tracking (e.g., a history of digital assets related to a video game), or a combination thereof. Each added element may further serve as information that can be verified by a validating device to identify whether the block and the payload therein are accurate and authorized. The one or more randomized nonce values ​​may help to further complicate the hashing and improve security.

[0040] Each block 305 / 335 / 365 of the blockchain 300 also includes a payload 330 / 360 / 390. The payload 330 / 360 / 390 of each block 305 / 335 / 365 may include one or more tokens, one or more transactions, one or more smart contracts, one or more other elements, metadata related to any of the previously enumerated elements, or a combination thereof. The token may be, for example, a non-fungible token. The token 400 may be an example of a token stored in the payload 330 / 360 / 390 of a block 305 / 335 / 365. As described with respect to the token 400, certain portions of the token 400 are stored within the payload 330 / 360 / 390 of the blockchain ledger 300 and are therefore stored "on-chain." As described with respect to the token 400, certain portions of the token 400 include an on-chain pointer that points to data outside of the blockchain ledger 300, such as the data structure 140, and such data is stored "off-chain." The payload 330 / 360 / 390 of the blockchain ledger 300 may store a hash of the off-chain data such that a verification device may calculate a hash of the off-chain data and compare the calculated hash to a stored hash stored on-chain to verify that the off-chain data is accurate. In some examples, the payload 330 / 360 / 390 includes one or more smart contracts. A block may include code of the smart contract stored in the payload 330 / 360 / 390 of the blockchain ledger 300, and thus the code may be stored on-chain. If the payload 330 / 360 / 390 includes a smart contract, the block may include a hash of the code of the smart contract and / or a pointer to an off-chain data structure 140 that stores the code of the smart contract, and thus the code may be stored off-chain. In some examples, some of the code of the smart contract may be stored on-chain, while some of the code of the smart contract may be stored off-chain.In some examples, smart contracts may be used to create, modify, transfer, or otherwise manage tokens. In some examples, the payload 330 / 360 / 390 includes a transaction. In some examples, the transaction may include transferring tokens from one account to another account. In some examples, the transaction may include modifying certain properties of the token or associated digital asset, such as changes to ownership, in-game appearance, in-game attributes, authorship, use license, rental, or a combination thereof.

[0041] While FIG. 3 only shows three blocks 305 / 335 / 365 of the blockchain 300, it should be understood that any blockchain discussed herein may be longer or shorter in that it may have more or fewer blocks than three.

[0042] In one illustrative example, a first computing device can store a blockchain ledger including a plurality of blocks. Each of a plurality of computing devices (e.g., in a distributed architecture) also stores a copy of the blockchain ledger. The first computing device can receive a message identifying an intended payload element (e.g., a token and / or a transaction and / or a smart contract). For example, the intended payload element may be a token associated with one of the digital assets associated with one or more video games described herein. The first computing device can verify that the intended payload element is valid. In some blockchain ledger 300 implementations, the first computing device can verify that sufficient funds have been allocated to pay an execution fee fee for the intended payload element, e.g., in the form of gas on an Ethereum blockchain ledger. In the case of a transaction, the first computing device can verify whether the transferor owns a sufficient amount of assets to make the transaction (e.g., whether the transferor owns the tokens to be transferred). In the case of a smart contract, the first computing device may verify that the smart contract references a valid account that includes a sufficient amount of assets (e.g., tokens) to execute the smart contract (e.g., transfer tokens), verify that the code of the smart contract is executable (e.g., does not contain syntax or other errors), verify that all parties involved in the smart contract have submitted their agreement to the terms of the smart contract, or any combination thereof. In the case of a token, the first computing device may verify that the token references a valid digital asset, e.g., a valid type of digital asset.

[0043] The first computing device may generate a hash of the latest block or block header of the blockchain ledger 300. The first computing device may generate a new block header for the new block. The new block header may include a hash of at least the latest block or block header of the blockchain ledger 300. The first computing device may generate a new block, the new block including a new block header and a payload having one or more payload elements. The one or more payload elements include at least the intended payload elements (e.g., tokens, smart contracts, transactions) discussed above. The first computing device may generate a Merkle root based on the payload elements and include the Merkle root in the new block header. The first computing device may generate metadata and a nonce value based on the payload elements and include the metadata and nonce value in the new block header. The first computing device may add the new block to a plurality of blocks of the blockchain ledger 300 in response to verifying the intended payload element. The first computing device may transmit the new block to a plurality of computing devices that each store the blockchain ledger 300 in response to verifying the intended payload element. Each of the multiple computing devices also adds the new block to its respective copy of the blockchain ledger 300.

[0044] In another illustrative example, a first computing device may store a blockchain ledger 300 including a plurality of blocks. Each of a plurality of computing devices (e.g., in a distributed architecture) also stores a copy of the blockchain ledger 300. The first computing device may receive a UI input identifying an intended payload element (e.g., a transaction and / or a smart contract). The first computing device may generate a message identifying the intended payload element. The first computing device may obtain a private key associated with an account corresponding to the first computing device. The first computing device may modify the message by encrypting at least a portion of the message with the private key. The first computing device may send the message to a plurality of computing devices other than the first computing device. A second computing device of the plurality of computing devices verifies that the intended payload element is valid, e.g., as described in the previous paragraph. The first computing device receives a new block from the second computing device. The new block identifies and / or includes the intended payload element (e.g., an element within its payload). The first computing device adds the new block to the plurality of blocks of the blockchain ledger 300 at the first computing device.

[0045] 4 is a block diagram illustrating an example of a token 400 that may be non-fungible and may represent a digital asset 405 associated with a video game that is tracked on a distributed ledger, according to an embodiment of the disclosure. In some examples, the token 400 is a non-fungible token (NFT). In some examples, the token 400 is an ERC721 token, an ERC1155 token, an ERC-20 token, or a combination thereof. In some examples, the token 400 is tracked on a blockchain ledger 300. In some examples, the token 400 is tracked on an Ethereum-based blockchain ledger 300.

[0046] The digital assets 405 that the tokens 400 represent can be in-game items and in-game digital assets such as in-game characters (which may be referred to as in-game actors), in-game costumes for in-game characters, in-game areas, etc. The in-game digital assets can be referred to as in-game objects, such as the objects in FIGS. 2A-2B. The in-game characters may be referred to as in-game actors, such as actor 254 in FIG. 2B. The in-game areas can be referred to as in-game zones, such as zone 252 in FIG. 2B. In some examples, the in-game characters can be player characters that are controlled by the player, non-player characters (NPCs) that the player cannot control (but may interact with), or some combination thereof. In some examples, the in-game costumes can include in-game representations of clothing, outfits, armor, suits, hats, helmets, tops, shirts, jackets, bottoms, pants, skirts, gloves, mittens, shoes, boots, fins, glasses, hats, handwear, legwear, footwear, jewelry, accessories, other apparel, or combinations thereof. In some examples, in-game items may include ranged weapons, melee weapons, potions, food, consumables, armor, shields, ammunition, magical abilities, health recovery items, mana recovery items, vehicles, power-ups, extra lives, extra continues, items that modify the attributes of other items (e.g., an item that upgrades a bow and arrow to shoot fire arrows), or combinations thereof.

[0047] A digital asset may be a video game digital media asset that includes a media representation of one or more moments of gameplay of a video game, such as a video clip, an image, or an audio clip. For example, an image may be a representation of a moment in gameplay of a video game. An image may include, for example, a screenshot. A video clip or audio clip may represent a series of consecutive moments of gameplay of a video game. For example, each moment of a series of moments may be represented by an individual video frame of a video clip, or by a particular set of one or more frequencies and amplitudes of a sound in an audio clip. Not all moments need to be consecutive, as a video clip or audio clip may switch from one moment to another in a series, such as a highlight reel. In some examples, an image may represent multiple moments of gameplay of a video game, such as, for example, a collage of images or a long exposure style image that includes a representation of a path traveled by one or more characters or items over one or more time periods. The images, video clips, and / or audio clips may be captured from a view, vantage point, and / or vantage point that a particular player has during gameplay. Images, video clips, and / or audio clips may be captured from a different view, viewpoint, and / or vantage point than that possessed by the individual players.

[0048] In some examples, a digital asset may include a save file that saves the progress of a video game at a particular point in the progress (e.g., story) of the video game. The save file may be identified as an in-game digital asset because it can be used within the game. The save file may be identified as a video game digital media asset because the save file serves as a representation of the gameplay moment that was saved.

[0049] In some examples, the digital assets may include "ghosts" that can be imported into a game to be visible to a player of the game. The ghosts may follow the path of a previous player's gameplay. For example, in a racing game, a ghost may appear in a player's game retracing the route run by another player at the pace run by that player. Because ghosts can be used within a game, they may be identified as in-game digital assets. Because ghosts act as representations of moments (periods of time) of a previous player's gameplay, they may be identified as video game digital media assets.

[0050] One or more token smart contracts 445 may be associated with a token 400. For example, the one or more token smart contracts 445 may govern the creation (or “minting”) of the token 400. The one or more token smart contracts 445 may compensate a miner device that creates (“mints”) the token 400 or a batch of tokens for the computational time and resources it takes to mint the token 400. The one or more token smart contracts 445 may control how ownership of the token 400 is determined and / or transferred. For example, the one or more token smart contracts 445 may indicate an initial owner of the token 400 and / or identify conditions under which ownership is automatically transferred, such as an offer where the owner meets or exceeds a configurable threshold amount. The one or more token smart contracts 445 may indicate conditions under which the token 400 may be loaned or licensed for use by a licensee user / player, such as an offer where the owner meets or exceeds a configurable threshold amount. One or more token smart contracts 445 can control the conditions under which the token 400 can be burned or irreversibly destroyed and / or made private. The elements identified in FIG. 4 as part of the token 400 (including the token identifier 410, the token unit quantity 415, the token ownership 420, the on-chain immutable metadata 425, the on-chain mutable metadata 430, the on-chain pointer to the off-chain media 435, and the on-chain pointer to the off-chain metadata 440) can be stored as part of the token 400, can be part of the token smart contract 445, or can be both. In some examples, the code of the token smart contract 440 is stored at least partially on-chain. In some examples, the code of the token smart contract 440 is stored at least partially off-chain in off-chain location(s), such as the data structure 140, and the off-chain location(s) are identified by an on-chain pointer to the off-chain location(s).

[0051] The token 400 includes a token identifier 410, which may be referred to as a token ID. The token identifier 410 may be a unique identifier for the token 400 and / or the digital asset 405. The token identifier 410 may be used to distinguish the particular instance of the digital asset 405 to which the token 400 corresponds from any other instances of the digital asset 405. In some examples, the token identifier may be created by a computing system that creates (or "mints") the token 400 by sequentially incrementing it compared to the token identifiers of previously created tokens to ensure that each token identifier is unique.

[0052] The token 400 may include a token unit quantity 415. The token unit quantity 415 may identify the quantity of the token 400 that has been minted or is set to be minted. In some examples, the token unit quantity 415 is 1, in which case there is a single token 400 for a given digital asset 405. In some examples, the token unit quantity 415 is greater than 1. For example, if the token unit quantity 415 is 5, there are effectively five copies of this token 400 that represent this unique digital asset 405 that can be owned and / or transferred individually. These five copies may be fungible with one another or may be indistinguishable from one another. However, these five copies are still non-fungible, unique, separate, and / or distinguishable compared to any other instance, or version, or variant of the digital asset 405. The token unit quantity 415 may control how rare the token 400, and therefore the digital asset 405, is. If the token unit quantity 415 is 1, the token 400 and the corresponding digital asset 405 are unique. If the token unit quantity 415 is greater than one but less than a rarity threshold, the token 400 and corresponding digital asset 405 are rare. If the token unit quantity 415 is greater than one but greater than a rarity threshold, the token 400 and corresponding digital asset 405 are common. In some examples, there may be any number of ranges of rarity in addition to or instead of unique, rare, and common, such as legendary, very rare, slightly rare, uncommon, and other categories of rarity. In some cases, the token unit quantity 415 may be determined as part of the minting process and / or identified in one of the token smart contracts 445 that govern the minting process.

[0053] The token 400 can identify token ownership 420, which can identify who owns the token 400 and therefore the corresponding digital asset 405. Token ownership 420 may be initially assigned to the creator of the digital asset 405. A token smart contract 445 can control the rules for transfer of token ownership 420. Token ownership 420 can be transferred as a transaction recorded as a payload element in the payload of a block of a blockchain ledger or other distributed ledger.

[0054] The token 400 can include on-chain immutable metadata 425. The on-chain immutable metadata 425 can include, for example, a description of the token 400, a description of the digital asset 405 that the token 400 represents, some immutable attributes or properties of the digital asset 405 and / or the token 400, or some combination thereof. The on-chain immutable metadata 425 can use properties of the distributed ledger and / or the token smart contract 445 to ensure that the on-chain immutable metadata 425 does not change. In some examples, the on-chain immutable metadata 425 can identify which game the data asset 405 is from, which game a representation (e.g., a record) is from, or which game it is otherwise associated with. In some examples, the on-chain immutable metadata 425 can identify the creator of the digital asset 405 and / or the token 400. In some examples, the on-chain immutable metadata 425 can identify statistics of the digital asset 405 and / or the token 400 (e.g., this in-game item provides +2 attack).

[0055] The token 400 can include on-chain mutable metadata 430. The on-chain mutable metadata 430 can include, for example, a description of the token 400, a description of the digital asset 405 that the token 400 represents, some immutable attributes or properties of the digital asset 405 and / or the token 400, or some combination thereof. The on-chain mutable metadata 430 can be mutable or changeable. In some examples, changes to the on-chain mutable metadata 430 can be recorded as transactions that are recorded as payload elements within the payload of a block of a blockchain ledger or other distributed ledger. In some examples, the on-chain immutable metadata 425 can identify how many times the digital asset 405 has been used in a game and / or how many different players have used the digital asset 405.

[0056] The token 400 may include an on-chain pointer to the off-chain media 435. The off-chain media may include the digital asset 405 and / or one or more representations of the digital asset 405. For example, the off-chain media may include one or more images, 3D models, video clips, audio clips, or a combination thereof. These types of media may require a lot of storage space to store and therefore may be expensive to store on-chain in terms of execution fees (e.g., gas for the Ethereum blockchain ledger). Therefore, it may be more efficient to store this media off-chain in one or more off-chain locations, such as the data structure 140. The on-chain pointer may include a uniform resource identifier (URI), such as a uniform resource locator (URL), that points to one or more network locations of the one or more off-chain locations. In some examples, a hash of the off-chain media may be stored such that a verification device can calculate a hash of the off-chain media and compare the calculated hash to a stored hash stored on-chain to verify that the off-chain media is accurate. In some examples, the off-chain media may be immutable. In some examples, the off-chain media may be mutable. In some examples, the pointer may be immutable. In some instances, the pointer may be mutable.

[0057] The token 400 may include an on-chain pointer to off-chain metadata 440. The off-chain metadata 430 may include, for example, a description of the token 400, a description of the digital asset 405 that the token 400 represents, some immutable attributes or properties of the digital asset 405 and / or the token 400, or some combination thereof. Some digital assets 405 and / or tokens 400 may require a large amount of metadata, which may require a large amount of storage space to store and thus may be expensive in terms of execution fees (such as gas for an Ethereum blockchain ledger). Therefore, it may be more efficient to store this metadata off-chain in one or more off-chain locations, such as the data structure 140. The on-chain pointer may include a uniform resource identifier (URI), such as a uniform resource locator (URL), that points to one or more network locations of the one or more off-chain locations. In some examples, a hash of the off-chain metadata may be stored such that a verification device can calculate a hash of the off-chain metadata and compare the calculated hash to a stored hash stored on-chain to verify that the off-chain metadata is accurate. In some examples, the off-chain metadata may be immutable. In some examples, the off-chain metadata may be mutable. In some examples, the pointers may be immutable. In some examples, the pointers may be mutable.

[0058] FIG. 5A is a conceptual diagram illustrating an example of a video game interface 500 in which a player character is in an environment with several in-game items, according to an embodiment of the disclosure. The video game interface 500 may be a gameplay interface for a player playing a video game. The video game interface 500 may be a viewer interface for a viewer streaming or otherwise watching a player's gameplay of a video game, either live (as in a live stream broadcast) or at some time after the gameplay. The video game interface 500 shows a player character 505, which may be an example of an in-game character controlled by a player of a video game, approaching a treasure chest 510, which is an example of an in-game item. The video game interface 500 shows two other in-game items, a laser rifle 515 and a plasma sword 520, that emerge from the treasure chest 510 in response to the player character 505 opening the treasure chest 510. The video game interface 500 shows an icon of an energy pistol 525 overlaid on a grid indicating that the energy pistol 525 is the in-game item currently equipped by the player character 505.

[0059] 5B is a conceptual diagram illustrating an example of a video game interface 550 highlighting an in-game item displayed in the video game interface of FIG. 5A , according to aspects of the present disclosure. Similar to the video game interface 500, the video game interface 550 may be a gameplay interface for a player playing a video game, or a viewer interface for a viewer streaming or otherwise watching gameplay of a player's video game. The video game interface 500 includes an "in-game items in view 560" interface, which lists in-game items visible within the view of the video game interface 500 and / or the video game interface 550, including a laser rifle 515, a plasma sword 520, and an energy pistol 525. Each listed in-game item can be added to the "in-game items in view 560" interface by the console 228 or server server 218, which generates the "in-game items in view 560" interface based on identification of an identifiable token 400 corresponding to each of the in-game items. Each listed in-game item includes an "Add" button that allows a player and / or viewer accessing the "In-Game Items in View 560" interface of the video game interface 550 to add one or more in-game items and / or associated tokens 400 to their inventory. In some examples, a treasure chest 510 may also be identified in the "In-Game Items in View 560" interface. In some examples, a treasure chest 510 may be missing from the "In-Game Items in View 560" interface due to certain characteristics that indicate it is unavailable or because no tokens 400 were created for the treasure chest 510.

[0060] 6A is a conceptual diagram illustrating an example of an item customization interface 600 that identifies various instances of an in-game item, each of which may include different customizations, according to aspects of the disclosure. The item customization interface 600 identifies various instances of a laser rifle 515, each of which may be unique, non-fungible, and / or correspond to its own token 400. For example, the item customization interface 600 includes a "Customization 610" tab that lists customized variations of the laser rifle 515, each of which may be unique, non-fungible, and / or correspond to its own token 400. The customized variations of the laser rifle 515 include a no-scope laser rifle 620 with a chevron visual design, created by user "Bob2000," a silenced laser rifle 625 with a silencer, a skull-and-crossbones visual design, created by user "Snipe123," and a truncated laser rifle 630 with a stubby cut end and decorated with a rocket visual design, created by user "TopDog85." The item customization interface 600 includes a "Modifications 615" tab that can list the types of modifications that can be made to the laser rifle 515, such as adding or removing a scope, adding or removing a silencer, a short cut end or a long barrel, and / or other possible modifications to other characteristics of the laser rifle 515.

[0061] FIG. 6B is a conceptual diagram illustrating an example of an item history interface 650 that identifies the history of a particular instance of an in-game item, according to aspects of the disclosure. The item history interface 650 of FIG. 6B highlights the particular digital asset identified in FIG. 6A, namely, the silenced laser rifle 625. The item history interface 650 includes a "History 660" tab that lists the history of the associated token 400 and the associated distributed ledger tracked digital asset (the silenced laser rifle 625). The history 660 identifies that the silenced laser rifle 625 digital asset was created by user "Snipe123" on 4 / 18 / 2021 at 11:22:39 AM. The history 660 identifies that user "Snipe123" shot user "Steve99" with the silenced laser rifle 625 digital asset during Match_402812 on 4 / 19 / 2021 at 3:42:56 PM. History 660 identifies that user “Snipe123” customized the artistic style of the Silenced Laser Rifle 625 digital asset, e.g., by adding a skull and crossbones visual icon, on April 21, 2021 at 1:29:12 PM. History 660 identifies, for example, that user “TopDog85” purchased the Silenced Laser Rifle 625 digital asset (and associated tokens 400) from user “Snipe123” on April 21, 2021 at 3:10:44 PM, such that the Silenced Laser Rifle 625 digital asset (and associated tokens 400) was transferred from user “Snipe123” to user “TopDog85.” History 660 identifies that on April 22, 2021 at 7:05:32 PM during Match_402839, user "TopDog85" shot user "Bob2000" using the silenced laser rifle 625 digital asset.The exemplary item history interface 650 also includes an “Owner” tab 665, which can identify, for example, that the silenced laser rifle 625 digital asset (and associated token 400) was originally owned by user “Snipe123” and is now owned by user “TopDog85” after a transfer of ownership on April 21, 2021 at 3:10:44 PM.

[0062] Each entry in history 660 includes a media button (a button with an arrow pointing right) that, when pressed, can trigger the playback of a video clip, audio clip, and / or image of the corresponding activity, action, or transaction. An example video clip is identified as a video game digital media asset 690 and depicts user "Snipe123" shooting user "Steve99" with a silenced laser rifle 625 digital asset during Match_402812 at 3:42:56 PM on April 19, 2021.

[0063] The item history interface 650 also includes a buy button 670, allowing a viewer of the item history interface 650 to purchase the silenced laser rifle 625 digital asset (by purchasing the corresponding token 400). The item history interface 650 also includes a license button 675, allowing a viewer of the item history interface 650 to become a licensee (by being licensed the corresponding token 400) to license use of the silenced laser rifle 625 digital asset. Licensing includes rental, and in some cases, an owner may license use of the digital asset for certain limited uses via the token smart contract 445 as a licensor, without actually transferring ownership of the digital asset and / or token 400. The item history interface 650 also includes a message button 680, allowing a viewer of the item history interface 650 to send a message to the owner and / or creator of the silenced laser rifle 625 digital asset.

[0064] 7A is a conceptual diagram illustrating an example of a video game interface 700 in which a first player character 710 corresponding to a first user encounters a second player character 720 corresponding to a second user, according to aspects of the disclosure. The first player character 710 is labeled "you" to indicate that the first player character 710 corresponds to a player playing a video game using the video game interface 700. The second player character 720 is labeled "Dragon83," which may be the username or other user identifier of the second user.

[0065] 7B is a conceptual diagram illustrating an example of a player list interface 750 identifying users whose corresponding player characters have encountered a first player character 710 corresponding to a first user, according to aspects of the disclosure. The player list interface 750 includes a “Meet Players” tab 760, which identifies a second player character 720 corresponding to a second user Dragon83 and presents, “You encountered this player while playing a Battle Royale duel in Space Wars Extreme on April 22, 2021.” Included are video clips 775 or other video game digital media assets depicting one or more moments in which the first player character 710 corresponding to the first user encounters the second player character 720 corresponding to the second user Dragon83. Additionally, the “Meeted Players” tab 760 identifies that a first player character 710 corresponding to a first user encountered another player character 770 corresponding to a third user, Bob2000, and presents, “You encountered this player while playing a single race in Speedy Pursuit on April 21, 2021.”

[0066] The player list interface 750 also includes a "Friends" tab 765. In some examples, the first user may follow or become friends with other users whose player characters the first user has encountered through the first user's player character(s) in one or more video games, as identified, for example, in the Encountered Players tab 760. In some examples, each user may be assigned a token 400 that may be used to track that user's history (similar to the item history interface 650 of FIG. 6B, but with respect to that user's actions and transactions). In some examples, each player character may be assigned a token 400 that may be used to track that player character's history (similar to the item history interface 650 of FIG. 6B, but with respect to that player character's actions and transactions).

[0067] In some examples, the player list interface 750 or similar interfaces may be used by users to track news related to particular users, player characters, in-game items, or other digital assets based on the tokens 400 and / or digital ledgers associated with those digital assets. For example, such a news interface may keep viewers of the news interface notified every time a particular user plays a video game, every time a particular player character is used in a match (or is used in a particular way), every time a particular in-game item is used in a match (or is used to perform a particular type of action), or some combination thereof.

[0068] 8A is a conceptual diagram 800 illustrating an example of a marketplace interface 805 for trading in-game digital assets 810, according to an embodiment of the disclosure. The marketplace interface 805 may be an interface within a video game or external to the video game, such as a website accessed by a browser running on a console or mobile device, a software application running on a console or mobile device, or a combination thereof. The marketplace interface 800 for trading in-game digital assets facilitates trading of in-game digital assets, such as in-game items 815, in-game costumes 820, in-game areas 825, in-game characters, save files, ghosts, other types of in-game digital assets, or combinations thereof.

[0069] In-game items 815 include a no-scope laser rifle 620 created by user Bob2000. Statistics for the no-scope laser rifle 620 identify it as being for or derived from the video game "Space Wars" and that it provides -2 accuracy and +1 damage. It has a unit quantity of 5 (representing 5 tokens of 400), a purchase price of $25, and a rental price of $5 per day. In-game items 815 include a silenced laser rifle 625 created by user Snipe124. Statistics for the silenced laser rifle 625 identify it as being for or derived from the video game "Space Wars" and that it provides +1 stealth. It has a unit quantity of 1 (representing 1 token of 400), a purchase price of $70, and a rental price of $9 per day. In-game items 815 include a truncated laser rifle 630 created by user TopDog85. The statistics for the truncated laser rifle 630 identify it as being for or derived from the video game "Space Wars" and that it provides -3 to hit and +4 damage. The unit quantity is 2 (representing 2 400 tokens), the purchase price is $35, and the rental price is $7 per day. In-game item 815 includes a spicy herb, created by user TopDog85. The statistics for the spicy herb identify it as being for or derived from the video game "Action Time" and that it provides +2 health and +1 damage. The unit quantity is 23 (representing 23 400 tokens), the purchase price is $8, and the rental price is $1 per day.

[0070] In-game costume 820 includes a top hat created by user Bob2000. The statistics for the top hat identify it as being for or derived from the video game "Space Wars" and that it provides +1 Charisma. It has a unit quantity of 1 (representing 1 token, 400), a purchase price of $17, and a rental price of $3 per day. In-game costume 820 includes an explorer outfit created by user Snipe123. The statistics for the explorer outfit identify it as being for or derived from the video game "Space Wars" and that it provides +2 Defense. It has a unit quantity of 80 (representing 80 tokens, 400), a purchase price of $5, and a rental price of $1 per day.

[0071] In-game area 825 includes a factory created by user Ashley33. Statistics for the factory identify it as being for or from the video game "Space Wars" and functioning as a dueling arena. The unit quantity is 30 (representing 30 tokens 400), the purchase price is $17, and the rental price is $3 per day. In-game area 25 includes a future Earth created by user Ashley33. Statistics for the future Earth identify it as being for or from the video game "Action Time" and functioning as a single player level set. The unit quantity is 50 (representing 50 tokens 400), the purchase price is $15, and the rental price is $2 per day.

[0072] 8B is a conceptual diagram illustrating an example of a marketplace interface 850 for trading video game digital media assets 860, according to an embodiment of the disclosure. The marketplace interface 855 may be an interface within the video game or external to the video game, such as a website accessed by a browser running on the console or mobile device, a software application running on the console or mobile device, or a combination thereof. The marketplace interface 850 for trading video game digital media assets 860 facilitates trading of video game digital media assets 860, such as video clips 865, images 870, audio clips 875, save files, ghosts, other types of video game digital media assets, or combinations thereof.

[0073] Video clip 865 includes a first video clip created by user Snipe123 and entitled "Game-Winning Shot!" depicting a player character shooting another player character to win the game. Statistics for the first video clip indicate it is from the video game "Space Wars," has a length of 15 seconds, and is provided at a resolution of 1080p. It has a unit quantity of 5 (representing 5 tokens 400), a purchase price of $25, and a rental price of $5 per day. Video clip 865 includes a second video clip created by user Snipe143 and entitled "Snipe123 Customizes a Laser Rifle," depicting the creation and / or customization of an in-game item, a laser rifle. Statistics for the second video clip indicate it is from the video game "Space Wars," has a length of 56 seconds, and is provided at a resolution of 720p. It has a unit quantity of 1 (representing 1 token 400), a purchase price of $70, and a rental price of $9 per day. Video clip 865 includes a third video clip created by user TopDog85 and titled "20 Headshots in a Row!", which depicts a player character getting 20 headshots in a row. Statistics for the third video clip indicate it is from the video game "Action Time", has a length of 1:26, and is provided at a resolution of 1080p. It has a unit quantity of 2 (representing 2 400 tokens), a purchase price of $35, and a rental price of $7 per day. Video clip 865 includes a fourth video clip created by user TopDog85 and titled "World Record Speed ​​Run", which depicts a speed run. Statistics for the fourth video clip indicate it is from the video game "Run Jump", has a length of 4:36, and is provided at a resolution of 720p. It has a unit quantity of 23 (representing 23 400 tokens), a purchase price of $8, and a rental price of $1 per day.

[0074] Image 870 includes a first image, created by user Bob200, entitled "Weird Glitch: Duplicate Characters!", depicting a glitch where a player character is duplicated. The statistics for the first image indicate it is from the video game "Space Wars", and is provided in JPG format with a resolution of 1080p. The unit quantity is 1 (representing 1 token 400), the purchase price is $17, and the rental price is $3 per day. Image 870 includes a second image, created by user Snipe123, entitled "Best Routes for Speedrunning!", depicting a route for a speedrunning game. The statistics for the second image indicate it is from the video game "RunJump", and is provided in PNG format with a resolution of 1080p. The unit quantity is 80 (representing 80 tokens 400), the purchase price is $5, and the rental price is $1 per day.

[0075] Audio clip 875 includes a first audio clip titled "Blue Team Catchphrase" created by user Sam44. Statistics for the first audio clip indicate it is from the video game "Space Wars," has a length of 14 seconds, and is provided at an audio quality of 90 kbps. The unit quantity is 300 (representing 300 tokens 400), a purchase price of $3, and a rental price of $1 per day. Audio clip 875 includes a second audio clip titled "Crowd Cheer at Game 3" created by user Ashley33. Statistics for the second audio clip indicate it is from the video game "Run Jump," has a length of 32 seconds, and is provided at an audio quality of 320 kpbs. The unit quantity is 90 (representing 90 tokens 400), a purchase price of $16, and a rental price of $3 per day.

[0076] In some examples, the video game digital media assets 860 may be manually selected and / or created by a user. In some examples, a video game digital media significance engine (which may be part of the interactive content server 110 and / or the platform server 140 and / or the console 228 and / or the server 218) can automatically identify an action, set of actions, important moments, or set of important moments and automatically create the video game digital media assets 860 in response to the importance detected. An example of a video game digital media significance engine is shown in FIG. 12. This may include, for example, a drama engine 1214, an AI server 1234, a cloud gaming server 1272, a drama engine data structure 1250, or a combination thereof. The video game digital media significance engine may identify significance based on, for example, the first time a particular action was performed (locally and / or globally by a player), a (personal, local, and / or global) record of performing a particular action or set of actions in a game (in record time and / or record score), an in-game action that received a particularly strong (big and / or heavy moves above a threshold) positive or negative reaction (from players, opponents, and / or spectators), an in-game action that met or was associated with a numerical value above a threshold, an in-game action that met or was associated with a numerical value below a threshold, other significant achievements, or a combination thereof. Examples of video game digital media assets may include packaged video game digital media assets 1274 generated by drama engine 1214 and / or AI server 1234 of FIG. 12.The video game digital media significance engine may identify as a significant action, for example, the first time someone kills 20 enemies in a row with a headshot, the most consecutive headshots ever received, the fastest time for any player to achieve 20 headshots in a game, the most headshots ever received by a player, the most consecutive headshots without taking damage from an enemy, the player encountering a glitch in a game, or a combination thereof. In some examples, the video game digital media significance engine may notify a user when the video game digital media significance engine has identified a significant action and generated video game digital media assets 860 based on the significant action.

[0077] In some examples, the marketplace interfaces 805 and 855 may be public. In some examples, the marketplace interfaces 805 and 855 may be private. In some examples, the marketplace interfaces 805 and 855 may be partially public and partially private. In some examples, the marketplace interfaces 805 and 855 may be controlled by and limited to use for a single video game. In some examples, the marketplace interfaces 805 and 855 may be controlled by and limited to use for a set of video games, such as a particular set of video games. In some examples, the marketplace interfaces 805 and 855 may be controlled by and limited to use for a single video game console or video game platform. In some examples, the marketplace interfaces 805 and 855 may be controlled by and limited to use for a set of video game consoles or video game platforms. In some examples, the set of video game consoles or video game platforms may be associated with a single manufacturer, device type, form factor, operating system (OS), or combinations thereof.In some examples, marketplace interfaces 805 and 855 may be controlled by and limited to use for one or more Sony® platforms and / or one or more Sony® PlayStation® platforms corresponding to one or more Sony® devices, such as a Sony® PlayStation4®, a Sony® PlayStation5®, a Sony® PlayStation® Vita®, another Sony® PlayStation® portable gaming console, another Sony® PlayStation® home gaming console, a Sony® PlayStationVR® virtual reality (VR) system, a Sony® PlayStationTV® home entertainment system, a Sony® tablet, a Sony® mobile handset, or a combination thereof. In some examples, a set of video game consoles or video game platforms may be associated with multiple manufacturers, device types, form factors, operating systems (OS), or combinations thereof, enabling, for example, cross-platform support, cross-device type support, cross-OS support, or combinations thereof.

[0078] 9 is a block diagram illustrating an example of a network environment 900 for managing digital assets related to a video game. The network environment 900 includes a digital asset creation engine 905, a digital asset storage resource 910, a digital asset authentication engine 915, a digital asset access gateway 920, and a digital asset management engine 925. In some examples, the digital asset creation engine 905 includes tools for creating digital assets and / or a validation system for verifying whether the created digital assets are valid. In some examples, the digital asset creation engine 905 creates digital assets or identifies digital assets to be created upon token creation. At operation 935, the digital asset creation engine 905 stores the digital assets in a digital asset data storage engine 910, which can store the digital assets in a data structure 140, for example. At operation 940, the digital asset creation engine 905 requests that the digital asset authentication engine 915 authenticate and generate an imprint, generate a token 400 corresponding to the digital asset, and generate a pointer (e.g., a URI) to the network location of the digital asset and / or metadata about the digital asset stored in a digital asset data storage resource 910 (e.g., data structure 140). At operation 945, the digital asset authentication engine 915 requests that the digital asset management engine 925 store the token 400 and begin a history of the token 400 in a distributed ledger (e.g., blockchain ledger 300) of the distributed ledger 150 corresponding to the token 400.

[0079] At operation 950, a request to transfer ownership of the token 400, and thus the digital asset, is received at a digital asset access gateway 920, which may include an API for managing digital assets and / or tokens. At operation 955, the digital asset management engine 925 can transfer ownership of the digital asset from the first user account to the second user account, for example, by creating a new block in the distributed ledger that identifies the transaction transferring ownership of the digital asset from the first user account to the second user account. In some examples, operation 980 can burn or delist the token 400 and associated digital asset from the digital asset management engine 925 and the distributed ledger, and an external system can be used to mint a new token for the digital asset, for example, in a cross-platform transfer, with ownership being transferred to the second user account.

[0080] At operation 960, a request is received at the digital asset access gateway 920 to obtain information regarding ownership, statistics, media, and / or other metadata associated with the token 400, and thus the digital asset. At operation 965, the digital asset management engine 925 can obtain information regarding the ownership, statistics, media, and / or other metadata of the token 400, and thus the digital asset, from the distributed ledger and return the information to the requesting entity via the digital asset access gateway 920 or directly. In some examples, such an information obtainment request can be used simply to verify whether the token 400 and / or the distributed ledger exists for a given digital asset. In some examples, if the digital asset management engine 925 determines that the token 400 and / or the distributed ledger does not exist for a given digital asset, the digital asset management engine 925 can determine that the digital asset (e.g., an in-game item) may have been introduced into the video game through illicit means, such as cheating. Thus, the digital asset management engine 925 can use the token 400 and the distributed ledger 150 to detect cheating in video games and improve the security of game play.

[0081] At operation 970, a request to rent the token 400, and thus the digital asset, is received at the digital asset access gateway 920. In some examples, at operation 975, the digital asset management engine 925 may grant a temporary rental license to use the token 400, and thus the digital asset, to the second user (e.g., through the token smart contract 445) without transferring ownership of the token 400 or the digital asset from the first user to the second user. In some examples, at operation 975, the digital asset management engine 925 may temporarily transfer ownership of the token 400, and thus the digital asset, from the first user to the second user (e.g., through the token smart contract 445) without allowing the second user to sell or otherwise transfer ownership during the temporary ownership period. The digital asset management engine 925 may automatically return ownership to the first user (e.g., through the token smart contract 445) after the rental license period expires.

[0082] FIG. 10A is a conceptual diagram 1000 illustrating the generation of a smart contract and entry of the smart contract into a distributed ledger according to an embodiment of the disclosure. The distributed computing architecture includes multiple computing systems (referred to herein as computers), which may be entertainment systems 1500 that store and modify the distributed ledger. A first computer sends a request 1005 to enter a smart contract with specific rules into the distributed ledger. A second computer sends a response 1010 indicating that the second computer has generated a new block for entry into the distributed ledger using the requested smart contract. A third, fourth, and fifth computers send verifications 1020A-C indicating that they have verified that the block correctly implements the smart contract, that the code of the smart contract is executable (e.g., does not contain syntax or other errors), that all parties involved in the smart contract have agreed to the terms of the smart contract, that the on-chain pointer correctly points to valid off-chain smart contract code, and / or that sufficient funds have been allocated to pay the execution fees of the intended payload elements. The second computer sends an input confirmation in response to the quorum of devices validating that the new block was successfully entered into the distributed ledger using the requested smart contract.

[0083] A process similar to that shown in Figure 10A may be used to enter a token, with corresponding validations 1020A-1020C verifying, for example, that the token references a valid type of digital asset, that the on-chain pointer correctly points to valid off-chain media or metadata, and / or that sufficient funds have been allocated to pay the execution fee for the intended payload element. A process similar to that shown in Figure 10A may be used to enter a transaction, with corresponding validations 1020A-1020C verifying, for example, that the transferor has a sufficient amount of assets for the transaction to occur (e.g., that the transferor owns the tokens to be transferred) and / or that sufficient funds have been allocated to pay the execution fee for the intended payload element.

[0084] FIG. 10B is a conceptual diagram 1050 illustrating execution of a smart contract according to an embodiment of the disclosure. A first computer submits an identification 1005 indicating that the first computer executed the smart contract code, identified that the conditions of the smart contract are satisfied, and identified an action to be taken. A second, third, and fourth computer submit verifications 1010A-1010C identifying that the second, third, and fourth computers executed the smart contract code, verified that the conditions of the smart contract are satisfied, and verified an action to be taken. A fifth computer indicates an error 1015 without verifying. A third computer indicates an action 1020 indicating that the third computer executed the smart contract code and performed an action in response to a quorum of devices verifying (e.g., verifications 1010A-510C).

[0085] FIG. 11 is a block diagram illustrating a directed acyclic graph (DAG) ledger 1100 configured to track digital assets associated with a video game, according to an aspect of the disclosure. While FIG. 3 discusses the use of a blockchain ledger 300, it should be understood that a non-linear ledger structure, such as the directed acyclic graph (DAG) ledger structure of FIG. 11, may be used instead of or in addition to the blockchain ledger 300 described herein. The term "distributed ledger" as used herein should be understood to refer to at least one of a blockchain ledger 300 (as in FIG. 3), a DAG ledger 1100 (as in FIG. 11), or a combination thereof. In a DAG ledger, each block header contains a hash of other "parent" blocks in the DAG ledger, or a hash of a predetermined number of blocks whose block headers are randomly or otherwise non-linearly selected, rather than a hash of the previous block in the blockchain. If each block header contains multiple hashes corresponding to different parent blocks or their headers, these hashes can be combined using a Merkle root.

[0086] For example, in the DAG ledger of FIG. 11, the predetermined number is two after at least the first two blocks have been generated. In the web DAG ledger of FIG. 11, parent blocks are indicated with arrows. Block 1110 contains a hash of the block headers of parent blocks 1120 and 1150. Block 1120 contains a hash of the block headers of parent blocks 1140 and 1160. Block 1130 contains a hash of the block headers of parent blocks 1120 and 1160. Block 1140 contains a hash of the block headers of parent blocks 1110 and 1130. Block 1150 contains a hash of the block headers of parent blocks 1110 and 1120. Block 1160 contains a hash of the block headers of parent blocks 1110 and 1150. The resulting structure is a directed acyclic graph (DAG) of blocks, where each vertex block contains a hash of its parent vertex block, rather than a linear stream of blocks as in a blockchain. The DAG ledger is sometimes called the "Web," "Tangle," or "Hashgraph."

[0087] In some examples, the number of parent blocks of a given block in the DAG ledger is not predefined, but there may be a predefined minimum number of parent blocks, such as 2-parent min or 1-parent min, meaning that each block has at least a predefined minimum number of parent blocks. In some cases, each block in the DAG ledger may only identify a single payload element rather than multiple payload elements, and thus the Merkle root 320 / 350 / 380 of the payload element may be omitted and / or replaced with a hash of the single payload element. In other implementations, each block may identify multiple payload elements associated with a given time period and / or may include the Merkle root 320 / 350 / 380 of the payload element. Potential advantages of the DAG ledger 1100 over the blockchain ledger 300 include parallel validation, which may increase throughput.

[0088] 12 is a block diagram illustrating an example of a network environment 1200 in which a video game digital media significance engine may be implemented according to aspects of the disclosure. The network environment 1200 includes a client device 1202, a third party device 1212, a cloud gaming server system 1272 with a drama engine 1214 and an artificial intelligence (AI) server 1234, and a number of drama engine data structures 1250. The video game digital media significance engine may include the cloud gaming server system 1272, the drama engine 1214, the AI ​​server 1234, the drama engine data structure 1250, or a combination thereof.

[0089] The client device 1202 may be a user device 130, a console 228, a video game console, a computing system, an entertainment system 1500, or a combination thereof. The client device 1202 may store and / or execute a game application that allows a player to play a video game. The client device 1202 may include or be coupled to a user interface, such as a video game controller, a joystick, a remote control, a keyboard, a keypad, a touch screen, a trackpad, or a combination thereof. As part of the execution of the game application, the client device 1202 may generate and / or render 2D and / or 3D graphics (e.g., representing in-game digital assets), perform physics simulations (e.g., affecting in-game digital assets), perform collision detection (e.g., collisions of in-game digital assets), connect to other client devices 1202 (e.g., possibly via an intermediate multiplayer network server) for networked multiplayer gaming, or any combination thereof. In some examples, the client device 1202 is a Sony® PlayStation® device.

[0090] In another embodiment, the game application may be executed on a back-end processor operating on a back-end game server of the cloud gaming network or cloud gaming server system 1272. For example, the cloud gaming server system 1272 may include multiple virtual machines (VMs) running on a hypervisor of a host machine, where one or more virtual machines are configured to execute the game application utilizing hardware resources available to the host's hypervisor to support single-player or multiplayer video games. In that case, the client device 1202 is configured to request access to the game application over a network such as the Internet, stream, receive, and / or render an instance of a video game or game application executed by a processor of the cloud gaming server system 1272, and deliver the rendered instance (e.g., audio and video) to a display device associated with the user device 1202 and the player, such as a display screen, projector, and / or head-mounted display (HMD). For example, while an instance of a game application associated with a video game is running on the cloud gaming server system 1272, the player interacts with the video game via the client device 1202. During execution, at least a portion of the logic of the game application may be executed by the cloud gaming server system 1272 and / or the server game engine.

[0091] The client device 1202 also includes a data capture engine 1204 that captures gameplay metadata 1262 associated with the player's gameplay from the execution of the game application on the client device 1202, from streaming of gameplay from the cloud gaming server system 1272 while the gameplay application is executing on the cloud gaming server system 1272, or from a combination thereof. The gameplay metadata 1262 may include OS context (e.g., which OS is running, what software is running the OS), information related to the time of a particular hardware operation (e.g., a button actuated, a button released, a joystick angle, a joystick direction, a joystick movement, a velocity, etc.), user profile data (e.g., the amount of time the player plays the game application, when the player last played the game application, how often the player requests support, how skilled the player is compared to other players), or a combination thereof. The gameplay metadata 1262 may be captured at various points in the progression of play of the game application, such as at the start of a level, at the end of a level, and / or at one or more points within the level between the start and end.Gameplay metadata 1262 may include information such as where the player (e.g., the player's character) has been within the game application, where the player's player character is in the in-game area of ​​the video game, what the player has done within the video game, what in-game assets and / or skills the player or player character has accumulated and / or used within the video game, what quests or tasks have been presented to and / or accepted by the player, where the player is headed within the video game, the state of the game at that point (e.g., the state of the in-game character, in-game items, in-game costume, and / or in-game area), the state of certain hardware elements (e.g., CPU, GPU, memory, register values, program counter values, programmable DMA state, DMA buffer data, audio chip state, CD-ROM, DVD-ROM, Blu-ray drive), the game area the player character is in, and so forth. The gameplay metadata 1262 may help determine the area in the video game, the level or version of the game application, in-game items (weapons, tools, bombs, etc.) held in the player character's inventory, the type or race of the player character (e.g., wizard, soldier, etc.), the current quest and / or task presented to and / or accepted by the player, the player character's loadout, the player character's skill set, the player character's level or rank, the player character's attributes, the player character's location, the player character's number of lives remaining, the total number of lives available, the amount of health the player has, the total amount of health possible, the amount of mana the player has, the total amount of mana possible, the amount of in-game currency the player possesses, the total possible amount of in-game currency, the in-game costume(s) worn and / or owned by the player character, trophies or awards the player has earned, achievements the player has earned, a time counter value, or a combination thereof. Gameplay metadata 1262 may include information that personalizes the video game for the player, such as control settings, display settings, audio settings, customization of one or more in-game assets, or a combination thereof.The gameplay metadata 1262 may be transmitted from the client device 1202 to a cloud gaming server system 1272, including the AI ​​server 1234, and / or the drama engine 1214. The historical gameplay metadata 1262 may be stored in the historical data database 1258.

[0092] Images, audio clips, and / or video clips of gameplay of a video game by a player using client device 1202 may be captured and / or recorded by gameplay recorder 1206 of client device 1202. Images, audio clips, and / or video clips of gameplay of a video game by a player using client device 1202 may be captured and / or recorded by a secondary gameplay recorder (not shown) of cloud gaming server system 1272. The gameplay images, audio clips, and / or video clips captured and / or recorded by gameplay recorder 1206 and / or the secondary gameplay recorder may be referred to as gameplay recording 1268, and client device 1202 may transmit gameplay recording 1268 to drama engine 1214, AI server 1234, and / or cloud gaming server system 1272.

[0093] Images, audio clips, and / or video clips of responses and / or reactions of the player, another player (e.g., an opponent or collaborator), and / or viewers to gameplay of the video game by the player using the client device 1202 may be captured and / or recorded by the live capture device 1208 of the client device 1202. These responses and / or reactions may be used for further analysis (e.g., to determine events or events of dramatic importance). The images, audio clips, and / or video clips of the responses and / or reactions captured and / or recorded by the live capture device 1208 may be referred to as player reactions 1266, and the client device 1202 may transmit the player reactions 1266 to the drama engine 1214, the AI ​​server 1234, and / or the cloud gaming server system 1272.

[0094] Cloud gaming server system 1272 can receive gameplay metadata 1262 from client device 1202 over a network, the gameplay metadata 1262 including contextual data corresponding to gameplay of a player playing a video game using client device 1202. Cloud gaming server system 1272 can identify dramatically significant events that have occurred, are occurring, or are set to occur in gameplay of a video game by a player using client device 1202 based on gameplay metadata 1262 and / or historical data. Dramatically significant events are distinguished from regular events (e.g., sub-events) that occur within gameplay, where regular events may occur to achieve progress through the game application, but do not necessarily culminate in highly dramatic and / or significant events. Dramatically significant events can be coded into the game application of the video game, discovered by one or more players during play of the video game, and / or associated with challenges based on matching gameplay metadata 1262 to one or more of a plurality of dramatically significant statistical patterns.

[0095] The AI ​​server 1234 of the cloud gaming server system 1272 can generate event classifiers for various types of events using the event classification modeler 1248 and one or more trained machine learning models in the machine learning (ML) engine 1236 trained using the event training data in the event training data database 1254. The event classifiers can be stored in the event classifier database 1252. The AI ​​server 1234 of the cloud gaming server system 1272 can identify various events in the gameplay metadata 1262 by matching events of dramatic importance that occur during a player's gameplay with events (of dramatic importance or otherwise) that have been modeled or recognized using the event classification modeler 1248.

[0096] The event identifier 1238 and one or more trained machine learning models in a machine learning (ML) engine 1236 that are trained using the event training data in the event training data database 1254 are used.

[0097] The AI ​​server 1234 of the cloud gaming server system 1272 can identify events of dramatic importance in the gameplay metadata 1262 using a machine learning (ML) engine 1236, a pattern engine 1242 having a statistical pattern scoring engine 1246 and / or a statistical pattern matching engine 1244, and / or an event identifier of dramatic importance 1240 that may be based on one or more trained machine learning models in a statistical pattern database of dramatic importance 1256. The AI ​​server 1234 of the cloud gaming server system 1272 can identify events of dramatic importance in the gameplay metadata 1262 by matching the gameplay metadata 1626 and / or one or more events identified therefrom (categorized or uncategorized) to one or more of a plurality of statistical patterns of dramatic importance as stored in the statistical pattern database of dramatic importance 1256. The one or more trained machine learning models in the machine learning (ML) engine 1236 can include deep learning models. The one or more trained machine learning models in the machine learning (ML) engine 1236 may include a neural network, such as a convolutional neural network (CNN). Statistical patterns of dramatic significance may include, for example, a last-second win, a come-from-behind victory, a personal record, a world record, an athlete reaching a personal record, reaching a world record, doing something new or unusual, accomplishing a difficult task or challenge, overcoming a personal or global negative trend, achieving a personal or global positive trend, or combinations thereof. In some examples, statistical patterns of dramatic significance and / or events of dramatic significance may be identified based on the reaction of a player of a video game on the client device 1202, another player (e.g., a competitor or collaborator), a viewer, and / or a commentator to an event.

[0098] The story template comparator 1275 can be used to identify and / or match sequences of events in one or more recordings of gameplay of one or more players to a story template for purposes of constructing a packaged video game digital media asset 1274 using the media package generator 1224. The packaged video game digital media asset 1274 can include gameplay recordings, performed synchronously or asynchronously, that have been identified and / or matched to tell a story according to a story template. The story template can define a dramatic storyline, such as an underdog, a come-from-behind victory, a duel between two gameplays, a photo finish victory, a Hail Mary pass to win the game, a single player record, a multiplayer record, the agony of defeat, a rookie who wins the game, a player who is fortunate enough to ultimately win the game, other events of dramatic significance identified herein, or combinations thereof.

[0099] In some examples, events of dramatic importance may be identified through matching one or more statistical patterns of dramatic importance. For example, the statistical pattern matching engine 1244 may be configured to cooperate with the deep learning engine 1236 to match data collected from a player's gameplay (e.g., related to an event) with one or more statistical patterns of dramatic importance that are modeled and stored in the statistical patterns of dramatic importance database 1256. For example, the statistical patterns of dramatic importance may include, but are not limited to, a threshold, novelty, rarity, difficulty, world records, regional records, personal records, negative trends, positive trends, or combinations thereof. The statistical pattern scoring engine 1246 is configured to score the matches performed by the statistical pattern matching engine 1244. The data is determined to be an event of dramatic importance if the total score meets or exceeds a threshold, a minimum, a maximum, or a combination thereof.

[0100] In some cases, the information generator 1216 can generate information related to historical game play that may help define a dramatically important event, why that event is so dramatic, or why it is important in the context of the history of the video game, or can generate information that personalizes the dramatic importance for the player. The information can be generated and / or stored in the historical data database 1258. The information delivery engine 1220 can send the information to the client device 1202 and / or one or more third-party devices 1212. The data surfacing engine 1210 on the client device 1202 can be configured to identify dramatically important events and / or such descriptive information on the client device 1202 in parallel with or overlaid on the game play. The information may also be sent as information 1270 to a player associated with the client device 1202 or to a third-party device 1212 such as another player's device or a commentator or a client device that plays a multiplayer game against a player associated with the client device 1202. The commentator can add live and / or recorded narration and / or commentary, which can be included as part of the packaged video game digital media asset 1274 along with the reactions of the player, other players (such as opponents or collaborators), and / or the audience. The game play and / or commentary can be live or pre-recorded and, for example, streamed live or post hoc using the broadcast / streaming engine 1228.

[0101] The narration may be automatically generated based on the information, such as by the narration generator 1218. For example, the narration may include the information described above (e.g., regarding personal and overall historical background related to events of dramatic importance) and is presented along with other stylized information (e.g., for blending the information into a flowing commentary of the gameplay). The narration and recorded portions of the gameplay may be merged to generate a media package (e.g., a highlight reel) that is shareable on a social networking website or application, such as by the sharing engine 1226. That is, the narration may be presented in a packaged video game digital media asset 1274 along with the player's gameplay to include events of dramatic importance. Additionally, as previously described, the reaction(s) 1266 of the player playing the game application may also be captured. The reaction(s) correspond to events of dramatic importance. The reaction(s) may also be merged into the packaged video game digital media asset 1274. The packaged video game digital media asset 1274 may be stored in the media package database 1260. A highlight reel may be a type of automatically generated video game digital media asset 1274 that includes one or more portions of gameplay corresponding to multiple events of dramatic importance. For example, the highlight reel generator 1230 is configured to automatically generate a highlight reel of one or more events in a player's gameplay. Narration, commentary, player reactions, and / or audience reactions may be integrated into the highlight reel. A slow-motion (slo-mo) replay may be generated by the slow-motion generator 1232 of one or more portions of an event or one or more events in the video game digital media asset 1274.

[0102] In some examples, the validation engine 1222 may validate the identified event of dramatic importance. For example, the engine 1222 may be configured to receive a confirmation from the player validating the event of dramatic importance. In one implementation, the confirmation may be in the form of a tag 1264 delivered by the player via the client device 1202. In some examples, the confirmation may be through a player's bio-signal detected through a sensor associated with the client device 1202. For example, when a corresponding player is experiencing an event of dramatic importance, the player's bio-signal may indicate the player's increased excitement. In this manner, the data collected related to the event of dramatic importance may be stored in the database 1254 as event training data and used as updated training data for defining a corresponding modeled event of dramatic importance.

[0103] 13 is a block diagram illustrating an example of a pointer element 1305 that can indicate to a user a digital asset 1360, an associated token 1355, and / or an associated distributed ledger 1350 associated with a video game, according to an aspect of the disclosure. The pointer element 1305 can include, for example, a barcode 1310, a Quick Response (QR) code 1315, a Near Field Communication (NFC) tag 1320, a wireless transceiver 1325, a Uniform Resource Identifier (URI) 1330, an ArUco marker, an Aztec code, a MaxiCode, a PDF417 barcode, a Data Matrix, a Binary Square Marker, a CodablockF code, a MicroPDF code, a MicroQR Code, a HanXin code, a dot code, other types of pointer elements, or combinations thereof. In some examples, the pointer element 1305 can be included on or within a physical object that represents a digital asset 1360 associated with a video game. For example, the NFC tag 1320 and / or other wireless transceiver 1325 can be within the physical object and / or on the surface of the physical object. The URI 1330 or optical glyphs (eg, barcode 1310, QR code 1315, Aztec code, etc.) may be printed and / or affixed to the surface of a physical object.

[0104] If the digital asset 1360 is an in-game digital asset, the physics object may be a 3D model of the digital asset 1360, a trading card with an image of the digital asset 1360, another type of image of the digital asset 1360, a tag with data about the digital asset 1360, other physical representation of the digital asset 1360, or a combination thereof. If the digital asset 1360 is a video game digital media asset, the physics object may be a 3D model of the scene depicted by the digital asset 1360, a trading card with an image or screenshot of the digital asset 1360, another type of image or screenshot of the digital asset 1360, a tag with data about the digital asset 1360, other physical representation of the digital asset 1360, or a combination thereof.

[0105] The pointer element 1305 can point to a location (on a network and / or device) where one or more copies of the digital asset 1360 are stored. For example, the pointer element 1305 can encode a URI that points to a location where the digital asset 1360 is stored. The pointer element 1305 can point to a location (on a network and / or device) where one or more copies of the distributed ledger 1350 corresponding to the digital asset 1360 (and / or the corresponding token 1355) are stored. For example, the pointer element 1305 can encode a URI that points to a location where the distributed ledger 1350 and / or the corresponding token 1355 are stored. The pointer element 1305 can point to a location (on a network and / or device) where the token 1355 is stored. For example, the pointer element 1305 can encode a URI that points to a location where the token 1355 is stored. The token 1355 can be a token 400 as in FIG. 4 that corresponds to the digital asset 1360. The distributed ledger 1350 may be a blockchain ledger 300, a DAG ledger 1100, or another type of distributed ledger. The distributed ledger 1350 may store tokens 1355, digital assets 1360, pointers to the digital assets 1360, and / or identifiers of the digital assets 1360. Scanning (e.g., using a camera and / or barcode scanner), reading, receiving information, or otherwise interacting with one of the pointer elements 1305 using a device (e.g., a mobile handset or entertainment system 1500) may decode a pointer or URI to the location(s) of the digital asset 1360, the token 1355, and / or the distributed ledger 1350 and may direct the device to the location(s) of the digital asset 1360, the token 1355, and / or the distributed ledger 1350.

[0106] In some cases, the pointer element 1305 may encode an instruction to add a type of transaction, an instruction to introduce a smart contract, an instruction to execute a smart contract, an instruction to perform an action that may be the basis for executing a smart contract, an instruction to mint a token 1355, an instruction to transfer ownership of a token 1355, an instruction to license a token 1355, an instruction to burn a token 1355, another addition to the payload of the distributed ledger 1350, another addition or modification to the off-chain data pointed to by the on-chain pointer on the distributed ledger 1350, or a combination thereof. Using a device (e.g., a mobile handset or entertainment system 1500) to scan, read, receive information from, or otherwise interact with one of the pointer elements 1305 (e.g., using a camera and / or barcode scanner) can decode the pointer or URI and can add a payload element, such as a transaction, a token 1355, a smart contract, an execution of a smart contract, or another payload element, to the distributed ledger 1350.Thus, using a device (e.g., a mobile handset or entertainment system 1500) to scan (e.g., using a camera and / or barcode scanner), read, receive information from, or otherwise interact with one of the pointer elements 1305 can decode the pointer or URI and add it to the history of the digital asset 1360 and / or token 1355 recorded in the distributed ledger and / or off-chain data structure pointed to by the on-chain pointer, e.g., digital asset 1360 and / or token 1355. or the use of the token 1355, a change in ownership of the digital asset 1360 and / or token 1355, a change in the license for the digital asset 1360 and / or token 1355, a change in the visual appearance of the digital asset 1360 and / or token 1355, a change in the in-game characteristics of the digital asset 1360 and / or token 1355, a change in other characteristics or attributes of the digital asset 1360 and / or token 1355, another historically recorded change of the digital asset 1360 and / or token 1355 as described herein, or a combination thereof.

[0107] 14A is a flow diagram illustrating operations 1400 for tracking in-game digital assets using a distributed ledger, according to an aspect of the disclosure. At least a subset of the operations 1400 may be performed by a digital asset tracking system, which may include, for example, the network environment 100, one or more interactive content servers 110, one or more platform servers 120, one or more user devices 130, one or more data structures 140, one or more distributed ledgers 150, the network environment 200, the console 228, one or more servers 218, the blockchain ledger 300, the network environment 900, a digital asset creation engine 905, a digital asset storage resource 910, a digital asset authentication engine 915, a digital asset access gateway 920, a digital asset management engine 925, a digital asset tracking system performing the operations 1450, an entertainment system 1500, or a combination thereof.

[0108] At act 1405, the digital asset tracking system receives a request to update the history of an in-game digital asset. The in-game digital asset may be used in a video game. Act 1405 may be followed by act 1410. The in-game digital asset may include, for example, at least one of an in-game item, an in-game character, an in-game costume, an in-game area, or a combination thereof. Examples of in-game digital assets include, for example, the objects of Figures 2A-2B, the off-chain media of Figure 4, the player character 505, the treasure chest 510, the laser rifle 515, the plasma sword 520, the energy pistol 525, the no-scope laser rifle 620, the silenced laser rifle 625, the truncated laser rifle 630, the player character 710, the player character 720, the in-game digital assets 810, the in-game items 815, the spicy herbs of Figure 8A, the in-game costume 820, the top hat of Figure 8A, the explorer costume of Figure 8A, the in-game area 825, the factory of Figure 8A, the future earth of Figure 8A, a particular digital asset created by the digital asset creation engine 905, a particular digital asset stored in the digital asset data storage resource 910 at operation 935, a particular digital asset for which a token was created by the digital asset authentication engine 915 at operation 940, or combinations thereof. In some examples, the in-game digital assets may include a save file and / or a ghost.

[0109] In operation 1410, the digital asset tracking system identifies a distributed ledger that stores tokens representing in-game digital assets. The distributed ledger includes a plurality of blocks that store at least a portion of the history of the in-game digital assets represented as interactions with the tokens. After operation 1410, either operation 1415 or operation 1425 can follow. Examples of tokens include token 400 of FIG. 4, tokens created by digital asset authentication engine 915 in operation 940, tokens stored in payloads 330 / 360 / 390 of blockchain ledger 300, or combinations thereof. Examples of distributed ledgers include blockchain ledger 300 of FIG. 3, DAG ledger of FIG. 11, and distributed ledgers 150 of FIGS. 1, 2A, and 9. Examples of the history of in-game digital assets are shown in history 660 and / or owner history 665.

[0110] The token may include a unique identifier, such as the token identifier 410. The token may identify the digital asset in the game. In some cases, the token may identify the in-game digital asset by including a pointer to a network location where the in-game digital asset is stored. The in-game digital asset may be stored off-chain as off-chain media. Thus, the pointer may be an on-chain pointer to the off-chain media 435 of FIG. 4. The pointer may be a uniform resource identifier (URI), such as a uniform resource locator (URL). The network location may include storage of the in-game digital asset on an Interplanetary File System (IPFS), a DHT, or another one of the data structures 140. The token may include metadata identifying one or more attributes of the in-game digital asset, such that the metadata is stored on the distributed ledger. Thus, the token may include a token unit quantity 415, token ownership 420, on-chain immutable metadata 425, and / or on-chain mutable metadata 430. The token may include a pointer to a network location that stores metadata identifying one or more attributes of the in-game digital asset, such that the distributed ledger stores the pointer. Thus, the token can include an on-chain pointer to off-chain metadata 440.

[0111] In operation 1415, the digital asset tracking system, in response to receiving the request to update the history of the in-game digital asset, automatically generates a new block of the distributed ledger, where the new block includes a payload identifying one or more updates to the history of the in-game digital asset represented as one or more new interactions with the token, and where the new block also includes a hash of at least a portion of a previous block of the distributed ledger. Operation 1415 may be followed by operation 1420. The new block of operation 1425 may be an example of the new block of operation 1415.

[0112] At operation 1425, the digital asset tracking system sends a request to the block generating computing device, in response to receiving a request to update the history of the in-game digital asset, to automatically generate a new block of the distributed ledger, where the new block includes a payload identifying one or more updates to the history of the in-game digital asset represented as one or more new interactions with the token, and where the new block also includes a hash of at least a portion of a previous block of the distributed ledger. The new block also includes a hash of at least a portion of a previous block of the distributed ledger. Operation 1425 can be followed by operation 1430. The new block of operation 1415 can be an example of the new block of operation 1425. At operation 1405, the digital asset tracking system receives the new block from the block generating computing device. Operation 1430 can be followed by operation 1420.

[0113] In some examples, the request to update the history of the in-game digital asset is based on a request to update properties of the in-game digital asset. The payload of the new block identifies one or more updates to the history of the in-game digital asset by identifying one or more updates to at least the properties of the in-game digital asset. The properties of the in-game digital asset can include the in-game appearance of the in-game digital asset, such that the one or more updates to the properties of the in-game digital asset include one or more changes to the in-game appearance of the in-game digital asset. An example of an update to the appearance of the in-game digital asset is shown in customization 610 of FIG. 6A. The properties of the in-game digital asset include the in-game functionality of the in-game digital asset, such that the one or more updates to the properties of the in-game digital asset include one or more changes to the in-game functionality of the in-game digital asset. Examples of in-game functionality of the in-game digital asset are identified in statistics of the in-game digital asset 810, such as values ​​for hit rate, damage, stealth, health, etc.

[0114] The properties of the in-game digital asset can include ownership of the in-game digital asset, such that the one or more updates to the properties of the in-game digital asset include changing ownership of the in-game digital asset from a first owner account to a second owner account based on the execution of one or more smart contracts. The change of ownership is illustrated in the buy button 670, history 660, and ownership 665 of FIG. 6B, the buy button of FIG. 8A, and operation 955. The properties of the in-game digital asset can include a license for in-game use of the in-game digital asset, such that the one or more updates to the properties of the in-game digital asset include granting a license for in-game use of the in-game digital asset to one or more licensee accounts based on the execution of one or more smart contracts. The license interface is illustrated in the license button 675 of FIG. 6B and the rent button of FIG. 8A. The request to update the history of the in-game digital asset can be based on an indication of in-game use of the in-game digital asset for an in-game action, such that the payload of the new block identifies an in-game action in which the in-game digital asset is used in the game. The in-game usage of the in-game digital assets is shown in history 660 of FIG. 6B.

[0115] At operation 1420, the digital asset tracking system adds the new block to the plurality of blocks of the distributed ledger.

[0116] In some examples, the digital asset tracking system creates a distributed ledger associated with the in-game digital asset in response to receiving an indication regarding the creation of the in-game digital asset. The indication may indicate that the in-game digital asset has been created, that the creation of the in-game digital asset is pending, or that the in-game digital asset is queued for creation. In some examples, the digital asset tracking system creates the in-game digital asset within the video game. The creation of the in-game digital asset may be performed as described with respect to the digital asset creation engine 905 and / or the history 660. The digital asset tracking system may generate a first block of the distributed ledger. A first payload of the first block initiates a history of the in-game digital asset. The plurality of blocks includes the first block. The digital asset tracking system may create a token corresponding to the in-game digital asset by generating at least a unique identifier for the token and identifying the in-game digital asset in the token. The first payload of the first block initiates a history of the in-game digital asset by referencing one or more first interactions with the token.

[0117] In some examples, the digital asset tracking system verifies that the request to update the history of the in-game digital asset is valid. Generating the new block may occur in response to verifying that the request to update the history of the in-game digital asset is valid. The verification may include some of the operations described with respect to verifications 1020A-1020C, verifications 1060A-1060C, or a combination thereof.

[0118] In some examples, adding a new block to the distributed ledger may complete updating the history of the in-game digital asset. In some examples, updating the history of the in-game digital asset may transfer ownership, rental license, license to use, or another property of the in-game digital asset. In some examples, before generating a new block at operation 1415 or before sending the request at block 1425, the digital asset tracking system may verify that the transferor device of the transferor user and / or the transferor device of the transferring user store a copy of the video game and / or a key to the video game. In some examples, before generating a new block at operation 1415 or before sending the request at block 1425, the digital asset tracking system may verify that the transferor device of the transferor user and / or the transferor device of the transferring user are authorized to run and / or play the copy of the video game. In some examples, before generating a new block at operation 1415 or sending the request at block 1425, the digital asset tracking system may verify that the transferor device of the transferor user and / or the transferor device of the transferring user are authorized to run and / or play a copy of the video game. In some examples, before generating a new block at operation 1415 or sending the request at block 1425, the digital asset tracking system may verify that the transferor device of the transferring user has stored a copy of the in-game digital assets and / or corresponding tokens of operation 1410.

[0119] In some examples, the transferring device of the transferring user uses the in-game digital asset during gameplay of the video game prior to acts 1405, 1410, 1415, 1425, and / or 1430. In some examples, the transferring device of the transferring user uses the in-game digital asset during gameplay of the video game after acts 1405, 1410, 1415, 1425, and / or 1430.

[0120] In some examples, the digital asset tracking system may perform a combination of operations 1400 of FIG. 14A and 1450 of FIG. 14B.

[0121] 14B is a flow diagram illustrating operations 1450 for tracking video game digital media assets using a distributed ledger, according to an aspect of the disclosure. At least a subset of the operations 1450 may be performed by a digital asset tracking system, which may include, for example, the network environment 100, one or more interactive content servers 110, one or more platform servers 120, one or more user devices 130, one or more data structures 140, one or more distributed ledgers 150, the network environment 200, the console 228, one or more servers 218, the blockchain ledger 300, the network environment 900, a digital asset creation engine 905, a digital asset storage resource 910, a digital asset authentication engine 915, a digital asset access gateway 920, a digital asset management engine 925, a digital asset tracking system performing the operations 1400, an entertainment system 1500, or a combination thereof.

[0122] At act 1455, the digital asset tracking system receives a request to update a history of a video game digital media asset. The video game digital media asset includes a media representation of one or more moments of gameplay of the video game. Act 1455 may be followed by act 1460. The media representation of the one or more moments of gameplay of the video game may include a video clip of a plurality of moments of gameplay of the video game, such as one of the video clips 865. The media representation of the one or more moments of gameplay of the video game may include an audio clip of a plurality of moments of gameplay of the video game, such as one of the audio clips 875. The media representation of the one or more moments of gameplay of the video game may include an image of the moment of gameplay of the video game, such as one of the images 870. Examples of video game digital media assets include, for example, the content of Figure 2A, the media file 212 of Figure 2A, the content timestamp file 214 of Figure 2A, the object file 216 of Figure 2A, the objects of Figures 2A-2B, the events of Figure 2B, the off-chain media of Figure 4, the video game digital media asset 690, the media associated with other elements of the history 660, the video clip 775, the video game digital media asset 860, the video clip 865, the four video clips shown in Figure 8B, the image 870, the two images shown in Figure 8B, the audio clip 875, the two audio clips shown in Figure 8B, the particular digital asset created by the digital asset creation engine 905, the particular digital asset stored in the digital asset data storage resource 910 at operation 935, the particular digital asset for which a token is created by the digital asset authentication engine 915 at operation 940, the packaged video game digital media asset 1274, or a combination thereof. In some examples, the video game digital media asset can include a save file and / or a ghost.

[0123] At operation 1460, the digital asset tracking system identifies a distributed ledger that stores a token representing the video game digital media asset. The distributed ledger includes a number of blocks that store at least a portion of the history of the video game digital media asset represented as interactions with the token. Operation 1460 can be followed by operation 1465 or operation 1475. Examples of tokens include the token 400 of FIG. 4, a token created by the digital asset authentication engine 915 at operation 940, a token stored in the payload 330 / 360 / 390 of the blockchain ledger 300, or a combination thereof. Examples of distributed ledgers include the blockchain ledger 300 of FIG. 3, the DAG ledger of FIG. 11, and the distributed ledger 150 of FIG. 1, FIG. 2A, and FIG. 9. An example history of the video game digital media asset can be similar to the history 660 and / or the owner history 665.

[0124] The token may include a unique identifier, such as the token identifier 410. The token may identify the video game digital media asset. In some cases, the token may identify the video game digital media asset by including a pointer to a network location where the video game digital media asset is stored. The video game digital media asset may be stored off-chain as off-chain media. Thus, the pointer may be an on-chain pointer to the off-chain media 435 of FIG. 4. The pointer may be a uniform resource identifier (URI), such as a uniform resource locator (URL). The network location may include storage of the video game digital media asset on an Interplanetary File System (IPFS), a DHT, or another one of the data structures 140. The token may include metadata identifying one or more attributes of the video game digital media asset, thus storing the metadata on the distributed ledger. Thus, the token may include a token unit quantity 415, token ownership 420, on-chain immutable metadata 425, and / or on-chain mutable metadata 430. The token may include a pointer to a network location that stores metadata identifying one or more attributes of the video game digital media asset, and the distributed ledger stores the pointer. Thus, the token may include an on-chain pointer to the off-chain metadata 440.

[0125] At operation 1465, the digital asset tracking system automatically generates a new block of the distributed ledger in response to receiving a request to update the history of the video game digital media asset. The new block includes a payload identifying one or more updates to the history of the video game digital media asset represented as one or more new interactions with the token. The new block also includes a hash of at least a portion of a previous block of the distributed ledger. Operation 1465 may be followed by operation 1470. The new block of operation 1475 may be an example of a new block of operation 1465.

[0126] At operation 1475, in response to receiving the request to update the history of the video game digital media asset, the digital asset tracking system sends a request to the block generating computing device to automatically generate a new block of the distributed ledger. The new block includes a payload identifying one or more updates to the history of the video game digital media asset represented as one or more new interactions with the token. The new block also includes a hash of at least a portion of a previous block of the distributed ledger. Operation 1475 can be followed by operation 1480. The new block of operation 1465 can be an example of a new block of operation 1475.

[0127] In some examples, the request to update the history of the video game digital media asset is based on a request to update metadata of the video game digital media asset, such that the payload of the new block identifies one or more updates to the history of the video game digital media asset by identifying at least one update to the metadata of the video game digital media asset. Examples of metadata may include token unit quantity 415, token ownership 420, on-chain immutable metadata 425, on-chain mutable metadata 430, off-chain media pointed to by on-chain pointers to off-chain metadata 440, statistics of FIG. 8B, or combinations thereof.

[0128] In some examples, the request to update the history of the video game digital media asset is based on a request to update ownership of the video game digital media asset, such that the payload of the new block identifies one or more updates to the history of the video game digital media asset by at least identifying that ownership of the video game digital media asset has changed from a first owner account to a second owner account based on execution of one or more smart contracts. The change in ownership is illustrated in the buy button 670, history 660, and ownership 665 of FIG. 6B and the buy button and operation 955 of FIG. 8B.

[0129] In act 1455, the digital asset tracking system receives the new block from the block producing computing device. Act 1480 may be followed by act 1470.

[0130] At operation 1470, the digital asset tracking system adds the new block to the plurality of blocks of the distributed ledger.

[0131] In some examples, the digital asset tracking system creates a distributed ledger associated with the video game digital media asset in response to receiving an indication regarding the creation of the video game digital media asset. The indication can indicate that the video game digital media asset has been created, that creation of the video game digital media asset is pending, or that the video game digital media asset is queued to have been created. In some examples, the digital asset tracking system creates the video game digital media asset in the video game. The creation of the video game digital media asset can be performed as described with respect to the digital asset creation engine 905 and / or the history 660. The digital asset tracking system can generate a first block of the distributed ledger. A first payload of the first block initiates a history of the video game digital media asset. The plurality of blocks includes the first block. The digital asset tracking system can create a token corresponding to the video game digital media asset by generating at least a unique identifier for the token and identifying the video game digital media asset in the token. The first payload of the first block initiates a history of the video game digital media asset by referencing one or more first interactions with the token.

[0132] In some examples, the digital asset tracking system verifies that the request to update the history of the video game digital media asset is valid. Generating the new block may occur in response to verifying that the request to update the history of the video game digital media asset is valid. The verification may include some of the operations described with respect to verifications 1020A-1020C, verifications 1060A-1060C, or a combination thereof.

[0133] In some examples, adding a new block to the distributed ledger may complete updating the history of the video game digital media asset. In some examples, updating the history of the video game digital media asset may transfer ownership, rental license, use license, or another property of the video game digital media asset. In some examples, before generating a new block at operation 1465 or before sending the request at block 1475, the digital asset tracking system may verify that the transferor device of the transferor user and / or the transferor device of the transferring user store a copy of the video game and / or a key for the video game. In some examples, before generating a new block at operation 1465 or before sending the request at block 1475, the digital asset tracking system may verify that the transferor device of the transferor user and / or the transferor device of the transferring user are authorized to run and / or play the copy of the video game. In some examples, before generating a new block at operation 1465 or before sending the request at block 1465, the digital asset tracking system may verify that the transferring user's transferring device has stored a copy of the video game digital media asset and / or corresponding token of operation 1460.

[0134] In some examples, the digital asset tracking system may perform a combination of operations 1400 of FIG. 14A and 1450 of FIG. 14B.

[0135] 15 is an exemplary user electronic entertainment system that may be used in initiating interactive content and providing dynamic interfaces according to aspects of the disclosure. The entertainment system 1500 of FIG. 15 includes a main memory 1505, a central processing unit (CPU) 1510, a vector unit 1515, a graphics processing unit 1520, an input / output (I / O) processor 1525, an I / O processor memory 1530, a peripheral interface 1535, a memory card 1540, a universal serial bus (USB) interface 1545, and a communication network interface 1550. The entertainment system 1500 further includes an operating system read only memory (OSROM) 1555, an audio processing unit 1560, an optical disk control unit 1570, and a hard disk drive 1565, which are connected to the I / O processor 1525 via a bus 1575.

[0136] Entertainment system 1500 may be an electronic game console. Alternatively, entertainment system 1500 may be implemented as a general purpose computer, a set-top box, a handheld gaming device, a tablet computing device, a virtual reality device, an augmented reality device, or a mobile computing device or phone. Entertainment systems may include more or fewer operating components depending on the particular form factor, purpose, or design.

[0137] The CPU 1510, vector unit 1515, graphics processing unit 1520, and I / O processor 1525 of FIG. 15 communicate via a system bus 1585. Additionally, the CPU 1510 of FIG. 15 communicates with the main memory 1505 via a dedicated bus 1580, and the vector unit 1515 and graphics processing unit 1520 may communicate via a dedicated bus 1590. The CPU 1510 of FIG. 15 executes programs stored in the OSROM 1555 and the main memory 1505. The main memory 1505 of FIG. 15 may include pre-stored programs and programs transferred via the I / O processor 1525 from a CD-ROM, DVD-ROM, or other optical disk (not shown) using the optical disk control unit 1570. The I / O processor 1525 of FIG. 15 may also enable the introduction of content transferred via wireless or other communication networks (e.g., 4G, LTE, 1G, etc.). The I / O processor 1525 of FIG. 15 primarily controls data exchange between various devices of the entertainment system 1500, including the CPU 1510, the vector unit 1515, the graphics processing unit 1520, and the peripheral interface 1535.

[0138] The graphics processing unit 1520 of FIG. 15 executes graphics instructions received from the CPU 1510 and the vector unit 1515 to generate images for display on a display device (not shown). For example, the vector unit 1515 of FIG. 15 may convert an object from three-dimensional coordinates to two-dimensional coordinates and send the two-dimensional coordinates to the graphics processing unit 1520. Additionally, the audio processing unit 1560 executes instructions to generate audio signals that are output to an audio device such as a speaker (not shown). Other devices may be connected to the entertainment system 1500 via the USB interface 1545 and a communication network interface 1550, such as a wireless transceiver, which may be embedded within the system 1500 or as part of some other component, such as a processor.

[0139] 15 provides instructions to CPU 1510 via peripheral interface 1535, which enables the use of a variety of different available peripheral devices (e.g., controllers) known in the art. For example, the user may instruct CPU 1510 to store certain game information on a memory card 1540 or other non-transitory computer-readable storage medium, or to instruct a game character to perform some specified action.

[0140] The present disclosure relates to applications that may be operable by a variety of end user devices. For example, the end user device may be a personal computer, a home entertainment system (e.g., Sony PlayStation2® or Sony PlayStation3® or Sony PlayStation4® or Sony PlayStation5®), a portable gaming device (e.g., Sony PSP® or Sony Vita®), or a home entertainment system of a lower level but different manufacturer. It is fully contemplated that the methods described herein are operable on a variety of devices. Aspects of the present disclosure may also be implemented with title neutrality and / or utilized across a variety of titles from a variety of publishers.

[0141] Aspects of the present disclosure may be implemented in applications that may be operable using a variety of devices. A non-transitory computer-readable storage medium refers to any medium or media involved in providing instructions to a central processing unit (CPU) for execution. 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. Common forms of non-transitory computer-readable media include, for example, floppy disks, flexible disks, hard disks, magnetic tapes, any other magnetic media, CD-ROM disks, digital video disks (DVDs), any other optical media, RAM, PROM, EPROM, FLASHEPROM, and any other memory chips or cartridges.

[0142] Various forms of transmission media may be involved in carrying one or more sequences of one or more instructions to the CPU for execution. A bus carries the data to a system RAM, and the CPU retrieves and executes the instructions from the system RAM. The instructions received by the system RAM may optionally be stored on a fixed disk either before or after execution by the CPU. Various forms of storage may be implemented as well, along with other network interfaces and network topologies to implement storage.

[0143] In some aspects of the present disclosure, computer readable storage devices, media, and memories may include cables or wireless signals containing bit streams, etc. However, when mentioned, non-transitory computer readable storage media explicitly excludes media such as energy, carrier signals, electromagnetic waves, and the signals themselves.

[0144] The above 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 teachings. The described aspects of the disclosure were selected to adequately explain the principles of the technology, its practical application, and to enable those skilled in the art to utilize the technology, with various modifications suited to the particular use contemplated. It is intended that the scope of the technology be defined by the claims.

Claims

1. 1. A system for tracking in-game digital assets, comprising: Memory, A processor coupled to the memory, wherein execution of instructions stored in the memory by the processor causes the processor to: receiving a request to update a history of the in-game digital asset to add changes to properties of the in-game digital asset while maintaining an asset type of the in-game digital asset, the in-game digital asset being usable within a video game through a platform associated with the video game by a player playing the game, the asset type being one of a plurality of predefined asset types usable through the platform associated with the video game; identifying a distributed ledger that stores non-fungible tokens representing the in-game digital assets, the distributed ledger including a plurality of blocks that store at least a portion of the history of the in-game digital assets represented as interactions with the non-fungible tokens, each instance of the distributed ledger stored across a plurality of computing devices, one of the plurality of computing devices including the memory and the processor; In response to receiving the request to update the history of the in-game digital asset, automatically generating a new block of the distributed ledger, wherein the new block is generated to include a payload that identifies at least the changes to the properties of the in-game digital asset included in one or more updates to the history of the in-game digital asset, the one or more updates to the history of the in-game digital asset being represented in the payload as one or more new interactions with the non-fungible token, and the new block is generated, in part, using a hashing algorithm such that the new block also includes a hash of at least a portion of a previous block of the distributed ledger; updating each of the instances of the distributed ledger across the multiple computing devices by adding the new block to the multiple blocks of the distributed ledger; The processor, Equipped with the in-game digital assets are customized to include one or more modifications related to the game; A second asset of the asset type does not include the one or more modifications.

2. The system of claim 1 , wherein the non-fungible token includes a unique identifier and identifies the in-game digital asset.

3. 3. The system of claim 2, wherein the non-fungible token identifies the in-game digital asset by including at least a pointer to a network location where the in-game digital asset is stored.

4. The system of claim 3 , wherein the pointer is a Uniform Resource Identifier (URI) and the network location comprises storage of the in-game digital asset on an Interplanetary File System (IPFS).

5. 3. The system of claim 2, wherein the non-fungible token includes metadata identifying one or more attributes of the in-game digital asset, and the distributed ledger stores the metadata.

6. 3. The system of claim 2, wherein the non-fungible token includes a pointer to a network location that stores metadata identifying one or more attributes of the in-game digital asset, and the distributed ledger stores the pointer.

7. 2. The system of claim 1, wherein the properties of the in-game digital asset include an in-game appearance of the in-game digital asset, and the changes to the properties of the in-game digital asset include one or more changes to the in-game appearance of the in-game digital asset.

8. 2. The system of claim 1 , wherein the properties of the in-game digital asset include an in-game functionality of the in-game digital asset, and the changes to the properties of the in-game digital asset include one or more changes to the in-game functionality of the in-game digital asset.

9. 2. The system of claim 1, wherein the properties of the in-game digital asset include ownership of the in-game digital asset, and the change to the properties of the in-game digital asset includes changing the ownership of the in-game digital asset and the non-fungible token from a first owner account to a second owner account based on execution of one or more smart contracts.

10. 2. The system of claim 1, wherein the properties of the in-game digital asset include a license for in-game use of the in-game digital asset, and the modification to the properties of the in-game digital asset includes granting the license for in-game use of the in-game digital asset to one or more licensee accounts based on execution of one or more smart contracts and based on access to the non-fungible token.

11. 2. The system of claim 1, wherein the request to update the history of the in-game digital asset is based on an indication of in-game use of the in-game digital asset for an in-game action, and the payload of the new block identifies the in-game action in which the in-game digital asset is used in a game.

12. Execution of the instructions by the processor causes the processor to: In response to receiving an indication regarding the creation of the in-game digital asset, creating the distributed ledger associated with the in-game digital asset; generating a first block of the distributed ledger, wherein a first payload of the first block initiates the history of the in-game digital asset, and the plurality of blocks includes the first block; The system of claim 1 , further comprising:

13. Execution of the instructions by the processor causes the processor to: creating a non-fungible token corresponding to the in-game digital asset by generating at least a unique identifier for the non-fungible token and identifying the in-game digital asset within the non-fungible token, wherein the first payload of the first block initiates the history of the in-game digital asset by referencing one or more first interactions with the non-fungible token; The system of claim 12 , further comprising:

14. Execution of the instructions by the processor causes the processor to: The system of claim 1 , further comprising: creating the in-game digital asset within the video game.

15. Execution of the instructions by the processor causes the processor to: verifying that the request to update the history of the in-game digital asset is valid, wherein generating the new block occurs in response to verifying that the request to update the history of the in-game digital asset is valid; The system of claim 1 , further comprising:

16. The system of claim 1 , wherein the in-game digital asset is one of an in-game item, an in-game character, an in-game costume, and an in-game area.

17. 1. A method for tracking in-game digital assets, comprising: receiving a request to update a history of the in-game digital asset to add changes to properties of the in-game digital asset while maintaining an asset type of the in-game digital asset, the in-game digital asset being usable through a platform associated with a video game; Identifying a distributed ledger that stores non-fungible tokens representing the in-game digital assets, the distributed ledger including a plurality of blocks that store at least a portion of the history of the in-game digital assets represented as interactions with the non-fungible tokens, each instance of the distributed ledger stored across a plurality of computing devices; In response to receiving the request to update the history of the in-game digital asset, automatically generating a new block of the distributed ledger, wherein the new block is generated to include a payload that identifies at least the changes to the properties of the in-game digital asset included in one or more updates to the history of the in-game digital asset, the one or more updates to the history of the in-game digital asset being represented in the payload as one or more new interactions with the non-fungible token, and the new block is generated, in part, using a hashing algorithm such that the new block also includes a hash of at least a portion of the block of the distributed ledger; updating each of the instances of the distributed ledger across the multiple computing devices by adding the new block to the multiple blocks of the distributed ledger; Including, the in-game digital asset is available within a video game by a player playing the game through a platform associated with the video game, the asset type being one of a plurality of predefined asset types available within a video game by a player playing the game through the platform associated with the video game; the in-game digital assets are customized to include one or more modifications related to the game; A method, wherein a second asset of the asset type does not include the one or more modifications.

18. In response to receiving an indication regarding the creation of the in-game digital asset, creating the distributed ledger associated with the in-game digital asset; generating a first block of the distributed ledger, wherein a payload of the first block initiates the history of the in-game digital asset, and the plurality of blocks includes the first block; 20. The method of claim 17, further comprising:

19. A non-transitory computer readable medium having instructions stored thereon, wherein execution of the instructions by one or more processors of a system for tracking in-game digital assets causes the system to: receiving a request to update a history of the in-game digital asset to add changes to properties of the in-game digital asset while maintaining the asset type of the in-game digital asset, the in-game digital asset being one of a plurality of predefined asset types usable within a video game by players playing the game through a platform associated with the game; Identifying a distributed ledger that stores non-fungible tokens representing the in-game digital assets, the distributed ledger including a plurality of blocks that store at least a portion of the history of the in-game digital assets represented as interactions with the non-fungible tokens, each instance of the distributed ledger stored across a plurality of computing devices; In response to receiving the request to update the history of the in-game digital asset, automatically generating a new block of the distributed ledger, wherein the new block is generated to include a payload that identifies at least the changes to the properties of the in-game digital asset included in one or more updates to the history of the in-game digital asset, the one or more updates to the history of the in-game digital asset being represented in the payload as one or more new interactions with the non-fungible token, and the new block is generated, in part, using a hashing algorithm such that the new block also includes a hash of at least a portion of the block of the distributed ledger; Adding the new block to the plurality of blocks of the distributed ledger. updating each of the instances of the distributed ledger across the multiple computing devices; Do the following: the in-game digital assets are customized to include one or more modifications related to the game; A second asset of the asset type does not include the one or more modifications.

20. The system of claim 1 , wherein the in-game digital asset is equippable by a character of the video game.

Images