Secure matchmaking, asset transfer, and usability reconfiguration platform

Abstract

A system and method for authentication reconfiguration regarding the usability of digital assets are described. 【Solution means】An asset management system identifies assets related to a video game. A first user device is authenticated to use the asset. The first user device is associated with a first user. The asset management system identifies a second user, for example, through characteristics shared with the first user. A second user device associated with the second user lacks authentication to use the asset. The asset management system receives a notification of the transfer of the usability of the asset, such as a notification that the second user has made a transfer payment or a notification that the conditions of a smart contract have been met. In response to receiving the notification, the asset management system automatically invalidates the authentication for the first user device to use the asset and validates the authentication for the second user device to use the asset.

Description

Technical Field

[0001] This technology relates to the transfer of authentication using digital assets. More specifically, this technology can provide various techniques for matching a first user and a second user and transferring the authentication for using digital assets related to a video game from a first user device associated with the first user to a second user device associated with the second user.

Background Art

[0002] Video games are an increasingly popular activity worldwide. Conventionally, video games have been stored on physical media such as optical discs or cartridges. More recently, users can obtain video games as digital assets on their devices, for example, by downloading digital copies of video games from a network-based video game marketplace. Similarly, in-game content of video games, sometimes referred to as downloadable content (DLC) or in-app purchases (IAP), can also be obtained by users on their respective devices, for example, by downloading digital copies of in-game content from a network-based video game marketplace.

[0003] One advantage of conventional video games stored on physical media is that the physical media can be resold from a first user to a second user, and the ownership of the video game and the ability to use the video game can be transferred from the first user to the second user. Conventionally, there has been no way to resell a digital instance of a video game or the digital in-game content of a video game from one user to another.

Summary of the Invention

[0004] Aspects of the present technology include systems and methods for the reconfiguration of the usability of digital assets. In some examples, an asset management system identifies assets related to a video game. A first user device is authenticated to use the asset. The first user device is associated with a first user. The asset management system identifies a second user, for example, based on characteristics shared with the first user. A second user device associated with the second user lacks authentication to use the asset. The asset management system receives a notification of the transfer of the usability of the asset, such as a notification that the second user has made a payment for the transfer or that the conditions of a smart contract have been met. In response to receiving the notification, the asset management system automatically invalidates the authentication for the first user device to use the asset and automatically validates the authentication for the second user device to use the asset. Thus, after the transfer, the second user device is authenticated to use the asset and the first user device is no longer authenticated to use the asset.

[0005] In one example, a system for the reconfiguration of authentication regarding the usability of digital assets is provided. The system includes a memory and one or more processors (e.g., processors implemented in a circuit) coupled to the memory. The one or more processors are configured to and capable of identifying assets related to a video game, wherein a first user device is authenticated to use the asset and the first user device is associated with a first user; identifying a second user, wherein a second user device associated with the second user lacks authentication to use the asset; receiving a notification of the transfer of the usability of the asset; automatically invalidating the authentication for the first user device to use the asset in response to receiving the notification; and automatically validating the authentication for the second user device to use the asset in response to receiving the notification.

[0006] In another example, a method for authentication reconfiguration regarding the usability of digital assets is provided. The method includes identifying an asset related to a video game, where a first user device is authenticated to use the asset and the first user device is associated with a first user; identifying a second user, where a second user device associated with the second user lacks authentication to use the asset; receiving a notification of a transfer of the usability of the asset; automatically invalidating the authentication for the first user device to use the asset in response to receiving the notification; and automatically validating the authentication for the second user device to use the asset in response to receiving the notification.

[0007] In another example, a non-transitory computer-readable medium storing instructions thereon, which, when executed by one or more processors, cause the one or more processors to identify an asset related to a video game, where a first user device is authenticated to use the asset and the first user device is associated with a first user; identify a second user, where a second user device associated with the second user lacks authentication to use the asset; receive a notification of a transfer of the usability of the asset; automatically invalidate the authentication for the first user device to use the asset in response to receiving the notification; and automatically validate the authentication for the second user device to use the asset in response to receiving the notification.

[0008] In another example, an apparatus for image processing is provided. The apparatus includes means for identifying an asset related to a video game, the means for identifying being such that a first user device is authenticated to use the asset and the first user device is associated with a first user; means for identifying a second user, the means for identifying being such that a second user device associated with the second user lacks authentication for using the asset; means for receiving a notification of a transfer of availability of the asset; means for automatically invalidating authentication for the first user device to use the asset in response to receiving the notification; and means for automatically validating authentication for the second user device to use the asset in response to receiving the notification.

Brief Description of the Drawings

[0009]

Figure 1

Figure 2A

Figure 2B

Figure 3

Figure 4

Figure 5

Figure 6

Figure 7

Figure 8

Figure 9

Figure 10

Figure 11A

Figure 11B

Figure 12

Figure 13

DETAILED DESCRIPTION OF THE INVENTION

[0010] The detailed description that follows is intended as a description of various configurations of the technology of the subject matter and is not intended to represent only configurations in which the technology can be practiced. The accompanying drawings, which are incorporated herein and form a part of the detailed description, are included to provide a more complete understanding of the technology. The detailed description includes specific details for the purpose of providing a more complete understanding of the technology. However, it will be apparent and obvious that the technology is not limited to the specific details described herein and can be practiced without these details. In some instances, structures and components are shown in block diagram form in order not to obscure the concepts of the technology of the subject matter.

[0011] Methods and techniques for creating, modifying, tracking, authenticating, and / or transferring the usability of digital assets related to video game(s) are described. In some examples, an asset management system identifies assets related to a video game, such as an instance of a video game situation or some in-game content (e.g., downloadable content (DLC), in-app purchases (IAP), characters, items, environments, save files, game play records, etc.). In some examples, the assets include non-fungible tokens (NFTs) related to a video game. A first user device is authenticated to use the asset. For example, if the asset is an instance of a video game, the first user device is authenticated to launch and / or play the video game on the first user device. If the asset is in-game content of a video game, the first user device is authenticated to use the in-game content within the video game when the video game is played on the first user device. The first user device is associated with a first user. The asset management system identifies a second user. In some examples, the asset management system identifies the second user during a matchmaking process, based on, for example, one or more shared characteristics with the first user (e.g., same favorite game, same most-played game, same region, same age group, or same combination thereof). A second user device associated with the second user lacks authentication to use the asset. The asset management system receives a notification of the transfer of the usability of the asset. For example, the notification of the transfer of the usability can include a notification that the second user has paid for the transfer, that the second user has agreed to pay for the transfer, that the transfer has been authenticated by another user (e.g., the first user or a parent or guardian of the second user), that the conditions of a smart contract have been met, or a combination of these.In response to receiving the notification, the asset management system automatically invalidates the authentication for the first user device to use the asset and automatically validates the authentication for the second user device to use the asset, thereby enabling the transfer of asset usability. Thus, after the transfer of asset usability, the second user device is authenticated to use the asset, and the first user device is no longer authenticated to use the asset. In some examples, the asset management system also performs a second transfer in parallel with, before, or after the transfer of asset usability. The second transfer can include, for example, a transfer of a second asset (e.g., funds, content related to the same video game, content related to a different video game) from the second user to the first user, a transfer from the second user to the asset management system, a transfer from the asset management system to the first user, or combinations thereof.

[0012] In some examples, the asset may be an instance of a video game. In some examples, the asset may be in-game content such as in-game items, characters, environments (e.g., levels, stages, worlds), objectives, save files, DLC, IAP, or combinations thereof. The asset can be a video game digital media asset with media representations of moments of gameplay of the video game, such as video clips, images, and / or audio clips. In some examples, a distributed ledger that tracks the history of the asset is created and stored across multiple devices of the distributed system. In some examples, a unique token (e.g., NFT) can be generated for the asset, and the unique identifier and metadata of the asset identify the characteristics of the asset. The transfer of the usability of the asset can include transfer of ownership, transfer of a license, rental, lease, demo, or combinations thereof. In some examples, the asset management system can update a distributed ledger, such as a blockchain ledger or a directed acyclic graph (DAG) ledger, in response to a notification of a transfer of the usability of the asset in a new block associated with the distributed ledger. The new block can include one or more hashes of at least a portion of one or more previous blocks in the distributed ledger.

[0013] The methods and techniques described herein extend the capabilities of a system for managing the usability of digital assets related to video games by providing a process by which the system migrates the usability of such digital assets, for example, in response to trigger conditions, by disabling the usability of an asset on one user device and enabling the usability of the asset on another user device. The methods and techniques described herein represent a secure and reliable platform for enabling such a migration of asset usability, for example, by using smart contracts to securely enable such a migration, a distributed ledger to securely track such a migration, non-fungible tokens (NFTs) to convert assets from fungible to non-fungible, and / or authentication from a third user (e.g., parent and / or guardian) regarding such a migration. The methods and techniques described herein enable secure and comprehensive tracking of the history of digital assets, e.g., tracking when, how, and by whom a digital asset was created, used, modified, rented to, rented by, sold to, purchased by, licensed to, licensed by, exchanged with, exchanged by, migrated to, and / or migrated by whom, and / or other actions.

[0014] FIG. 1 shows an exemplary network environment 100 in which a system for tracking digital assets related to a video game using a distributed ledger can be implemented, according to one aspect of the present disclosure. The network environment 100 can include one or more interactive content servers 110 that provide streaming content (e.g., interactive video, podcasts, video game content, etc.), one or more platform servers 120, 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 can be stored across a distributed network 115, which can include 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, or combinations thereof.

[0015] The interactive content server 110 can maintain, stream, and host interactive media that is available for streaming on the user device 130 via a communication network. Such an interactive content server 110 can be implemented in the cloud (e.g., one or more cloud servers). Each media can include one or more sets of object data that may be available for user participation (e.g., display of an activity or interaction with an activity). Data regarding the objects shown in the media can be stored within an object file 216 (the "object file") by the interactive content server 110, the platform server 120, and / or the user device 130.

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

[0017] At least one set of related streaming media and object data can be provided by an application programming interface (API) 160, through which various types of interactive content servers 110 can communicate with different platform servers 120 and different user devices 130. The API 160 can be dedicated to the specific computer programming languages, operating systems, protocols, etc. of the interactive content server 110 that provides the streaming media content title, the platform server 120 that provides at least one set of related media and object data, and the user device 130 that receives it. In a network environment 100 including multiple different types of interactive content servers 110 (or platform servers 120 or user devices 130), there can similarly be a corresponding number of APIs 160.

[0018] The user device 130 may include a plurality of different types of computing devices. For example, the user device 130 may include any number of different gaming consoles, mobile devices, laptops, and desktops. In another example, the user device 130 may be implemented in the cloud (e.g., one or more cloud servers). Such a user device 130 may also be, but is not limited to, a memory card or a disk drive that is 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 and media interface, a non-transitory computer-readable storage device (memory), and a processor for executing 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®), applications, or computing languages (e.g., C++®, JavaScript®). An exemplary user device 130 is described in detail herein with respect to FIG. 13.

[0019] The data structure 140 can include, for example, one or more databases (DBs), one or more distributed hash tables (DHTs), one or more interplanetary file systems (IPFSs), 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. The data structure 140 can be stored on the platform server 120, on the interactive content server 110, on any of the servers (shown in FIG. 2A) such as server 218, across one or more different servers, on a single server, across different servers, on any of the user devices 130, within the distributed ledger 150, on a device identified by a network location identified by a pointer (e.g., the same resource identifier) recorded in the distributed ledger 150, or any combination thereof. Such a data structure 140 can store digital assets related to video games, such as a related set (s) of streaming media, portions thereof, and / or object data. Such streaming media can depict one or more objects (e.g., activities) in which a user can participate, and / or UGC (e.g., screenshots, videos, commentaries, mashups, etc.) created by a peer, a publisher of a media content title, and / or a third-party publisher. Portions of the streaming media can include images, video clips, audio clips, or combinations thereof. Such UGC can include metadata for searching such UGC. Such UGC can also include information about the media and / or the peer. Such peer information can be derived from data collected during peer interaction with objects of an interactive content title (e.g., video game, interactive book, etc.), can be "bound" to the UGC, and can be stored with the UGC.Such bindings extend the UGC to enable the UGC to deeply link (e.g., directly launch) to an object, provide information about the object and / or peers of the UGC, and / or enable a user to interact with the UGC. One or more user profiles may also be stored in the data structure 140. Each user profile can include information about the user (e.g., user progress in activities and / or media content titles, user ID, user's game character, etc.) and can be associated with media.

[0020] In some examples, the object and / or object file 216 is an example of a digital asset related to a video game that is tracked using one or more of the distributed ledgers 150. In some examples, a portion of media, such as a video clip or an image or an audio clip of one or more instants of gameplay, is an example of a digital asset related to a video game that is tracked using one or more of the distributed ledgers 150. The portion of media can be generated, recorded, and / or streamed using the interactive content server 110, the platform server 120, 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 restricted to, use for a single video game. In some examples, the distributed ledger 150 can be controlled by, and restricted to, use for a set of video games, such as a particular series of video games. In some examples, the distributed ledger 150 may be controlled by, and restricted to, use for a single video game console or video game platform. In some examples, the distributed ledger 150 may be controlled by, and restricted to, use for a set of video game consoles or video game platforms. In some embodiments, the set of video game consoles or the set of 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 can be controlled and limited in use by being used for one or more types of Sony® devices such as one or more Sony® platforms and / or Sony® PlayStation® 4, Sony® PlayStation® 5, Sony® PlayStation® Vita®, another Sony® PlayStation® portable gaming console, another Sony® PlayStation® home gaming console, the Sony® PlayStation® VR Virtual Reality (VR) system, the Sony® PlayStation® TV home entertainment system, a Sony® tablet, a Sony® mobile handset, or combinations thereof. In some examples, a set of video game consoles or a set of video game platforms can include video game consoles or video game platforms associated with two or more manufacturers, device types, form factors, operating systems (OS), or combinations thereof, for example, enabling cross-platform support, cross-device type support, cross-OS support, or combinations thereof. The blockchain ledger 300 is an example of the distributed ledger 150.

[0022] Figure 2A is a block diagram showing an exemplary network environment 200 in which a system for coupling object data from a universal data system to media content according to one aspect of the present disclosure may be implemented. In the exemplary network environment 200 of Figure 2A, an exemplary console 228 (e.g., user device 130) and exemplary servers 218 (e.g., streaming server 220, activity feed server 224, UGC server 232, and object server 226) are shown. The console 228 may be implemented on the platform server 120, a cloud server, or any of the servers 218. The console 228 may further include a content recorder 202 and an object recorder 210, which will be described in more detail below, through which content (e.g., media) may be recorded and / or output. Various interactive content titles 230 may be executed on the console 228. Alternatively or in addition, the content recorder 202 may be implemented on the platform server 120, 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 the content ring buffer 208. Such a ring buffer 208 may store a plurality of content segments (e.g., v1, v2, and v3), the start time of each segment (e.g., V1_START_TS, V2_START_TS, V3_START_TS), and the end time of each segment (e.g., V1_END_TS, V2_END_TS, V3_END_TS). Such segments may be stored by the console 228 as a media file 212 (e.g., MP4, WebM, etc.). Such a media file 212 (e.g., part of streaming media) may be uploaded to the streaming server 220 for storage and subsequent streaming or use, but the media file 212 may be stored on any server, cloud server, any console 228, or any user device 130.The media file 212 can be uploaded periodically and / or in real-time, or near real-time. The start time and end time of each such segment can be stored by the console 228 as the content time stamp file 214. Such a content time stamp file 214 can also include a streaming ID that matches the streaming ID of the media file 212, thereby associating the content time stamp file 214 with the media file 212. Such a content time stamp file 214 can be uploaded and stored in the activity feed server 224 and / or the UGC server 232, but the content time stamp file 214 can be stored in any server, cloud server, any console 228, or any user device 130.

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

[0024] While 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 time (beings) and end time of the object. Such object data can be uploaded periodically and / or in real time, or almost in real time. The object library 204 and the object recorder 206 may be implemented on the platform server 120, the cloud server, or any server 218. When the object recorder 206 detects the start of an object, the object recorder 206 receives object data (for example, when 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 (for example, 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 can be stored in the object file 216. Such an object file 216 may include the activity start time, activity end time, activity ID, activity result, activity type (for example, confrontation match, quest, task, etc.), user or peer data related to the activity. For example, the object file 216 may store data related to the items used during the activity. Such an object file 216 can be stored in the object server 226, but the object file 216 can be stored in any server, cloud server, any console 228, or any user device 130.

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

[0026] In some embodiments, objects identified by the object library 204, object recorder 206, object ring buffer 210, object file 216, and / or object server 226 may be stored in the distributed ledger 150 one or more times by the console 228 and / or by the server 218, and tracked across one or more of the distributed ledger 150, and converted into non-fungible in-game digital assets using non-fungible tokens such as token 400 of FIG. 4. Tokens corresponding to media files 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 embodiments, at least some 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 non-fungible in-game digital assets tracked in the distributed ledger 150.

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

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

[0029] Such a zone data file 252 may represent an area of the associated game world having a single coordinate system, the zone may have an associated 2D map, and may be used to display positions on the zone. When the zone data file 252 is 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 (4×4) for converting from 3D world coordinates to 2D map positions. Such a zone data file 252 may be associated with a position change event indicating an update to the player's current in-game position. Such position change events may be posted periodically or whenever the player's in-game position changes significantly. The platform server 120 may store the latest values in the "state". Such a zone data file 252 may include the x, y, z positions of the player's character in the zone, and the a, b, c vectors indicating the orientation or direction of the player's character. Such a zone data file 252 may also be associated with an activity start event and / or an activity end event, and in the case of an activity end event, a result of completion, failure, or abandonment may be associated with the activity (e.g., an activity ID).

[0030] Such actor data file 254 may be associated with an entity along with its in-game behavior, may be a player controller, or may be game-controlled, and may change dynamically during gameplay. Such actor data file 254 may include an actor's actor ID, the actor's localizable name, the actor's image, and / or a short description of the actor. Such actor data file 254 may be associated with an actor selection event indicating that the player's selected actor(s) has been changed. The selected actor(s) may represent the actor(s) the player is controlling in the game and may be displayed in the player's profile and other spaces via the platform server 120. Multiple actors may be selected at once, and each game may replace that list of actors when loading save data.

[0031] Such mechanic data file 256 may be associated with items, skills, or effects (e.g., bow, arrow, stealth attack, fire damage) that can be used by the player or the game to affect gameplay, and may exclude items that do not affect gameplay (e.g., collectibles). Such mechanic data file 256 may include a mechanic's mechanic ID, the mechanic's short name, the mechanic's image, and / or a short description of the mechanic. Such mechanic data file 256 may be associated with a mechanic availability change event indicating that the mechanics available to the player have changed. Available may mean that the mechanic is available to the player in the game world, but the player may need to perform some steps to acquire it in their inventory before using it (e.g., purchase from a shop, receive from the world). Each game may replace that list of mechanics when loading save data.

[0032] Such a mechanic data file 256 can be associated with a mechanic inventory change event indicating that the player's inventory has been changed. The inventory can refer to mechanics that the player can use immediately without the need for additional steps in the game before using the mechanic. Inventory information is used to estimate the player's readiness for various activities that can be advanced to the platform server 120. The game may replace that list of the mechanic inventory when loading save data. The cooldown mechanic can be considered part of the inventory. A mechanic count with any non-zero value (e.g., ammunition, recovery points, etc.) can be treated as "within the inventory". Inventory mechanics can be considered a subset of the available mechanics.

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

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

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

[0036] FIG. 3 is a block diagram showing three consecutive blocks of a blockchain ledger 300 that can be used to track digital assets related to a video game, according to one aspect of the present disclosure. Three blocks of the blockchain ledger 300, including block A305, block B335, and block C365, are shown in FIG. 3.

[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 headers 310 / 340 / 370 include the hash 315 / 345 / 375 of the previous block and / or the hash 310 / 340 / 370 of the block header of the previous block. For example, the header 370 of block C365 includes the hash 375 of the header 340 of block B335. Similarly, the header 340 of block B335 includes the hash 345 of the header 310 of block A305. Similarly, the header 310 of block A305 includes the hash 315 of the header (not shown) of the previous block (not shown) preceding block A305 in the blockchain ledger 300. Including the hash of the header of the previous block makes the blockchain ledger 300 stable by preventing modification of any block in the blockchain ledger 300 after the block has been added to the blockchain ledger 300. This is because any change to a particular block will make the hash 315 / 345 / 375 of the block header in the next block inaccurate. Further, modification of the hash of that block header in the next block will make the hash 315 / 345 / 375 of the header of the next block in the blocks after the next block inaccurate, and so on. A verification device can verify that a block has not been modified by calculating the hash of the block and / or the hash of the block header and then comparing the calculated hash to the stored hash 315 / 345 / 375 stored in the next block. In some distributed ledgers, the block headers 310 / 340 / 370 can include the hashes of multiple previous blocks and / or the block headers of multiple previous blocks, as in the case of a distributed acyclic graph (DAG) ledger.

[0038] The block headers 310 / 340 / 370 of each block can include Merkle roots 320 / 350 / 380. The Merkle roots 320 / 350 / 380 can be generated based on the hash of each of the tokens, transactions, smart contracts, and / or other elements identified in the payloads 330 / 360 / 390 for that block. Any attempt to modify the payload after the block has been entered will change the Merkle root. The verification device can verify that the payload(s) 330 / 360 / 390 have not been modified by calculating the Merkle root and then comparing the calculated Merkle root with the stored Merkle roots 320 / 350 / 380 stored in the block headers 310 / 340 / 370. Changes to the payload 330 / 360 / 390 and / or the Merkle root 320 / 350 / 380 also change the hash for the block and / or the hash for the block header, and the values for them are stored in the next block as hashes 315 / 345 / 375. Each payload of each block can include one or more tokens (e.g., token 400), one or more transactions, one or more smart contracts, other content, or combinations thereof.

[0039] The block headers 310 / 340 / 370 of each block may also include various elements of metadata such as the version number of the blockchain ledger platform, the version number of the block itself, a timestamp for the verification of each payload, a timestamp for the generation of the block, a timestamp for the entry of the block into the blockchain ledger 300, a timestamp for the request for the generation of the block, a difficulty target value (e.g., to adjust the mining difficulty), one or more randomized nonce values, a counter identifying how many nonces have been tried, the title of the blockchain ledger 300, an identifier regarding what the blockchain ledger 300 is tracking (e.g., the history of digital assets related to a video game), or a combination thereof. Each of the additional individual elements may further function as information to be verified by a verification device to identify whether the block and the payloads therein are accurate and authorized. The one or more randomized nonce values help to further complicate the hash and improve security.

[0040] Each block 305 / 335 / 365 of the blockchain ledger 300 also includes a payload 330 / 360 / 390. The payload 330 / 360 / 390 of each block 305 / 335 / 365 can include one or more tokens (e.g., token 400), one or more transactions, one or more smart contracts, one or more other elements, metadata related to any of the previously listed elements, or combinations thereof. The token can be, for example, a non-fungible token. Token 400 can be an example of a token stored in the payload 330 / 360 / 390 of block 305 / 335 / 365. As discussed with respect to token 400, certain portions of token 400 are stored within the payload 330 / 360 / 390 of the blockchain ledger 300 and are thus stored "on-chain." As discussed with respect to token 400, certain portions of token 400 include an on-chain pointer that refers to off-chain data, such as data structure 140, and such data is stored "off-chain." The payload 330 / 360 / 390 of the blockchain ledger 300 can store a hash of the off-chain data, such that a verification device can calculate the hash of the off-chain data and compare the calculated hash to the 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. The block can include the code of the smart contract stored within the payload 330 / 360 / 390 of the blockchain ledger 300 and thus stores the code on-chain. If the payload 330 / 360 / 390 includes a smart contract, the block can 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 stores the code 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 can 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 can include the transfer of tokens from one account to another. In some examples, the transaction can include changes to specific properties of the token or related digital asset, such as changes to ownership, in-game visual appearance, in-game attributes, author, usage license, rental, or combinations thereof.

[0041] In one exemplary embodiment, a first computing device can store a blockchain ledger including a plurality of blocks. Each of a plurality of computing devices (e.g., 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 related to one or more video games described herein. The first computing device can verify that the intended payload element is valid. In some embodiments of the blockchain ledger 300, the first computing device can verify that sufficient funds are allocated, for example, in the form of gas on an Ethereum blockchain ledger, to charge an execution fee for the intended payload element. In the case of a transaction, the first computing device can verify whether the transferor has a sufficient amount of assets (e.g., whether the transferor owns the tokens to be transferred) for the transaction to occur. In the case of a smart contract, the first computing device can verify that the smart contract refers to a valid account containing a sufficient amount of assets (e.g., tokens) to execute the smart contract (e.g., transfer tokens), that the code of the smart contract can be executed (e.g., without syntax errors or other errors), that all parties involved in the smart contract have submitted their consent to the conditions of the smart contract, or combinations thereof. In the case of a token, the first computing device can verify that the token refers to a valid digital asset, e.g., a valid type of digital asset.

[0042] The first computing device can generate a hash of the latest block or block header of the blockchain ledger 300. The first computing device can generate a new block header for a new block. The new block header can include the hash of the latest block or block header of the blockchain ledger 300. The first computing device can generate a new block that includes the new block, the new block header, and a payload that includes one or more payload elements. The one or more payload elements include at least the intended payload elements described above (e.g., tokens, smart contracts, transactions). The first computing device can generate a Merkle root based on the payload elements and include the Merkle root in the new block header. The first computing device can generate metadata and a nonce based on the payload elements and include the metadata and nonce in the new block header. In response to verifying the intended payload elements, the first computing device can add the new block to a plurality of blocks of the blockchain ledger 300. In response to verifying the intended payload elements, the first computing device can send the new block to a plurality of computing devices each storing a copy of the blockchain ledger 300. Each of the plurality of computing devices also adds the new block to their respective copies of the blockchain ledger 300.

[0043] In another exemplary embodiment, the first computing device can store a blockchain ledger 300 that includes a plurality of blocks. Each of the plurality of computing devices (e.g., a distributed architecture) also stores a copy of the blockchain ledger 300. The first computing device can receive a UI input that identifies an intended payload element (e.g., a transaction and / or a smart contract). The first computing device can generate a message that identifies the intended payload element. The first computing device can retrieve a private key associated with an account corresponding to the first computing device. The first computing device can modify the message by encrypting at least a portion of the message with the private key. The first computing device can 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, for example, as described in the previous paragraph. The first computing device receives a new block from the second computing device. The new block identifies the intended payload element (e.g., within its payload) and / or includes the intended payload element. The first computing device adds the new block to the plurality of blocks of the blockchain ledger 300 at the first computing device.

[0044] FIG. 3 shows only three blocks 305 / 335 / 365 of the blockchain ledger 300, but it should be understood that any blockchain described herein may be longer or shorter in that it may have more or fewer than three blocks. Further, it should be understood that instead of or in addition to the blockchain ledger 300, another type of distributed ledger, such as a directed acyclic graph (DAG) ledger, may be used.

[0045] In some examples, the distributed ledger may have a non-linear ledger structure, such as the structure of a directed acyclic graph (DAG) ledger. Such a DAG ledger 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 the blockchain ledger 300 (such as in FIG. 3), the DAG ledger, or a combination thereof. In a DAG ledger, each block header includes not only the hash 315 / 345 / 375 of a single previous block (or block header) like the blockchain ledger 300, but also the hashes of several other "parent" blocks within the DAG ledger, randomly or in any other non-linear manner. When each block header includes multiple hashes corresponding to different parent blocks or their headers, these hashes can be combined together (e.g., using a Merkle root). In some examples, the number of parent blocks of a given block within the DAG ledger is predetermined. In some examples, the number of parent blocks of a given block in the DAG ledger is greater than or equal to a predetermined minimum number of parent blocks, such as a two-parent minimum or a one-parent minimum, meaning that each block includes at least the predetermined minimum number of parent blocks. In some cases, each block in the DAG ledger may identify only a single payload element (e.g., a smart contract, a token 400, a transaction) rather than a plurality of payload elements, and thus may precede or replace the Merkle root 320 / 350 / 380 of the payload elements with the hash of the single payload element. In other embodiments, each block may identify a plurality of payload elements associated with a predetermined period and / or may include the Merkle root 320 / 350 / 380 of the payload elements. In some examples, the DAG ledger can provide advantages over the blockchain ledger 300, for example, by providing parallelized validation, which can provide higher throughput and / or improved security compared to the blockchain ledger 300.

[0046] FIG. 4 is a block diagram showing an exemplary token 400 that can represent a digital asset 405 associated with a video game that can be non-fungible and tracked in a distributed ledger. In some examples, token 400 is a non-fungible token (NFT). In some examples, token 400 is an ERC721 token, an ERC1155 token, an ERC-20 token, or a combination thereof. In some examples, token 400 is tracked within blockchain ledger 300. In some examples, token 400 is tracked within an Ethereum-based blockchain ledger 300.

[0047] The digital asset 405 represented by the token 400 can be an instance of a video game. The digital asset 405 represented by the token 400 can represent in-game digital assets such as in-game items, and in-game characters (which may be referred to as in-game actors), in-game costumes for in-game characters, in-game areas, save files related to the game, configurations related to the game, DLC, IAP, or combinations thereof. In-game digital assets can be referred to as in-game objects, such as the objects from FIGS. 2A through 2B. In-game characters can be referred to as in-game actors, such as the actor 254 in FIG. 2B. In-game areas can be referred to as in-game zones, such as the zone 252 in FIG. 2B. In some examples, in-game characters can be player characters controlled by a player, non-player characters (NPCs) that a player cannot control (but can interact with in some cases), or some combination thereof. In some examples, in-game costumes can include in-game representations of clothing, outfits, armor, suits, hats, helmets, tops, shirts, jackets, bottoms, pants, skirts, gloves, gauntlets, shoes, boots, fins, eyewear, headwear, handwear, legwear, footwear, jewelry, accessories, other clothing, or combinations thereof. In some examples, in-game items can include ranged weapons, melee weapons, potions, food, consumables, armor, shields, ammunition, magical abilities, health recovery items, mana recovery items, vehicles, power-ups, additional lives, additional continues, items that change the attributes of other items (e.g., upgrade a bow and arrows to fire fire arrows), or combinations thereof.

[0048] A digital asset can 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 single moment of gameplay of a video game. The image can include, for example, a screenshot. A video clip or an audio clip can be a representation of a series of consecutive moments of gameplay of a video game. For example, each moment of the consecutive moments can be represented by an individual video frame of the video clip, or by a particular set of sounds of one or more frequencies and amplitudes within the audio clip. Since a video clip or an audio clip can be cut from one set of moments to another set of moments, such as a highlight reel, not all moments need to be consecutive. In some examples, an image can be a representation of multiple moments of gameplay of a video game, such as in an image collage, or in a long exposure style image that includes a representation of a path along which one or more characters or items move over one or more durations. An image, a video clip, and / or an audio clip can be captured from a view, perspective, and / or vantage point that a particular player has during gameplay. An image, a video clip, and / or an audio clip can be captured from a view, perspective, and / or vantage point that is different from that of an individual player.

[0049] In some embodiments, a digital asset may include a save file that saves the progress in a video game at a particular point in the progress of the video game (e.g., within a story). Since the save file is usable within the game, it may be identified as an in-game digital asset. The save file can be identified as a video game digital media asset since the save file functions as a display of the moment of gameplay at which the save file was saved.

[0050] In some examples, a digital asset can include a "ghost" that can be imported into the game in a way that is visible to the game's player. The ghost can trace the path of a previous player's gameplay. For example, in a racing game, a ghost may appear in the player's game, tracing a previously raced route that was raced by the same player before, or by another player, at the same speed as it was previously raced. Since the ghost is available within the game, it may be identified as a digital asset within the game. The ghost can function as a display of multiple instants (durations) of a previous player's gameplay, and thus can be identified as a digital media asset of a video game.

[0051] One or more token smart contracts 445 can be associated with a token 400. For example, one or more token smart contracts 445 can manage the creation (or "minting") of a token 400. One or more token smart contracts 445 can make payments to a mining device that creates ( "mints") a token 400 or a batch of tokens in order to calculate the time and resources required to mint the token 400. One or more token smart contracts 445 can control how the ownership of a token 400 is determined and / or transferred. For example, one or more token smart contracts 445 can indicate the first owner of a token 400 and / or identify conditions under which ownership automatically transfers, such as an offer that meets or exceeds a changeable threshold amount by the owner. One or more token smart contracts 445 can indicate conditions under which a token 400 can be rented or licensed for use by a licensee user / player, for example, an offer that meets or exceeds a changeable threshold amount by the owner. One or more token smart contracts 445 can control the conditions under which a token 400 can be burned, or irreversibly destroyed and / or excluded from the list. Elements identified as part of a token 400 in FIG. 4, including a token identifier 410, a token unit amount 415, a token ownership 420, on-chain immutable metadata 425, on-chain mutable metadata 430, an on-chain pointer to off-chain media 435, and an on-chain pointer to off-chain metadata 440, can be stored as part of the token 400, can be part of the token smart contract 445, or both. In some examples, the code of the token smart contract 445 is stored at least partially on-chain.In some examples, the code of the token smart contract 445 is stored at least partially off-chain at an off-chain location(s) such as the data structure 140, and the off-chain location(s) is / are identified by an on-chain pointer to the off-chain location(s). The smart contracts of FIGS. 11A through 11B can be examples of the token smart contract 445.

[0052] The token 400 includes a token identifier 410, which may be referred to as a token ID. The token identifier 410 can be a unique identifier of the token 400 and / or the digital asset 405. The token identifier 410 can be used to distinguish a particular instance of the digital asset 405 to which the token 400 corresponds from any other instance of the digital asset 405. In some examples, the token identifier can be generated by a computer system that forms (or “mints”) the token 400 by being incremented sequentially compared to the token identifiers of previously formed tokens to ensure that each token identifier is unique.

[0053] Token 400 can include a token unit quantity 415. The token unit quantity 415 can identify the quantity of tokens 400 that have been minted or are 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 embodiments, the token unit quantity 415 is more than 1. For example, if the token unit quantity 415 is 5, there are substantially five copies of this token 400 that represent this unique digital asset 405 that can be separately owned and / or transferred. These five copies may be interchangeable with each other or indistinguishable from each other. However, these five copies are still non-fungible, unique, different, and / or distinguishable compared to any other instance or version or variation of the digital asset 405. The token unit quantity 415 can control the scarcity of the token 400 and, by extension, the digital asset 405. 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 2 or more but less than the rarity threshold, the token 400 and the corresponding digital asset 405 are rare. If the token unit quantity 415 is 2 or more but greater than the rarity threshold, the token 400 and the corresponding digital asset 405 are common. In some examples, in addition to or instead of unique, rare, and common, there may be any number of rarity ranges, such as legendary, very rare, slightly rare, uncommon, and other categories of rarity. In some cases, the token unit quantity 415 can be determined as part of the minting process and / or can be identified in one of the token smart contracts 445 that manage the minting process.

[0054] Token 400 may well identify token ownership 420, and token ownership 420 may identify the person who owns token 400 and, by extension, the corresponding digital asset 405. Token ownership 420 may initially be assigned to the creator of digital asset 405. Token smart contract 445 may control the rules for the transfer of token ownership 420. Token ownership 420 may transfer as a transaction recorded as a payload element in the payload of a block of a blockchain ledger or other distributed ledger.

[0055] Token 400 may include on-chain immutable metadata 425. On-chain immutable metadata 425 may include, for example, a description of token 400, a description of the digital asset 405 represented by token 400, some immutable attributes or characteristics of digital asset 405 and / or token 400, or some combination thereof. On-chain immutable metadata 425 may use the characteristics of the distributed ledger and / or token smart contract 445 to ensure that on-chain immutable metadata 425 remains unchanged. In some examples, on-chain immutable metadata 425 may identify from which game digital asset 405 is, what representation (e.g., recording) of which game it is, or how else it is related to which game. In some examples, on-chain immutable metadata 425 may identify the creator of digital asset 405 and / or token 400. In some examples, on-chain immutable metadata 425 may identify statistics of digital asset 405 and / or token 400 (e.g., this in-game item provides +2 attack power).

[0056] Token 400 may include on-chain variable metadata 430. The on-chain variable metadata 430 can include, for example, a description of the token 400, a description of the digital asset 405 represented by the token 400, some immutable attributes or characteristics of the digital asset 405 and / or the token 400, or some combination thereof. The on-chain variable metadata 430 can be variable or modifiable. In some examples, changes to the on-chain variable metadata 430 can be recorded as a transaction that is recorded as a payload element 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 the number of times the digital asset 405 has been used within a game and / or the number of different players who have used the digital asset 405.

[0057] Token 400 may include an on-chain pointer to off-chain media 435. The off-chain media can include digital asset 405 and / or one or more representations of digital asset 405. For example, the off-chain media can include one or more images, 3D models, video clips, audio clips, or combinations thereof. These types of media may require a lot of storage space to store, and thus can be expensive to store on-chain in terms of execution fees (such as gas on the Ethereum blockchain ledger). Therefore, it may be more efficient to store this media off-chain at one or more off-chain locations such as data structure 140. The on-chain pointer can include a uniform resource identifier (URI) such as a uniform resource locator (URL) that points to one or more network locations of one or more off-chain locations. In some examples, the hash of the off-chain media can be stored, such that the verification device can calculate the hash of the off-chain media and compare the calculated hash to the 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 examples, the pointer may be mutable.

[0058] Token 400 may include an on-chain pointer to off-chain metadata 440. The off-chain metadata 430 can include, for example, a description of token 400, a description of the digital asset 405 represented by token 400, some immutable attributes or characteristics of the digital asset 405 and / or token 400, or some combination thereof. Some digital assets 405 and / or tokens 400 may require a significant amount of metadata, which may require a lot of storage space to store and may thus be expensive to store on-chain in terms of execution fees (such as gas on the Ethereum blockchain ledger). Therefore, it may be more efficient to store this metadata off-chain at one or more off-chain locations such as data structure 140. The on-chain pointer can include a uniform resource identifier (URI) such as a uniform resource locator (URL) that points to one or more network locations among one or more off-chain locations. In some examples, a hash of the off-chain metadata can be stored, such that a verification device can calculate the hash of the off-chain metadata and compare the calculated hash to the 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 pointer may be immutable. In some examples, the pointer may be mutable.

[0059] FIG. 5 is a block diagram 500 showing the transfer of the availability of an asset 530 from a first user device 515 to a second user device 525. The first user device 515 is associated with a first user 510, while the second user device 525 is associated with a second user 520. Each of the first user device 515 and the second user device 525 can be an example of a user device 130, a console 228, an entertainment system 1300, or a combination thereof. An asset management system 505 can manage the transfer of the availability of an asset 530 from the first user device 515 to the second user device 525. The asset management system 505 can include an interactive content server 110, a platform server 120, a data structure 140, a distributed ledger 150, an API 160, one or more user devices 130, a distributed network 105, a console 228, an entertainment system 1300, or a combination thereof.

[0060] The asset management system 505 is communicatively coupled to the first user device 515 and the second user device 525, for example, through one or more networks. In some examples, the asset management system 505 has a control level over the first user device 515 and the second user device 525 and has the function of enabling or disabling, for example, digital entitlement (e.g., the availability of a specific digital asset) in the first user device 515 and / or the second user device 525. The asset management system 505 can use this to manage the transfer of the availability of the asset 530.

[0061] The first user device 515 may acquire an asset 530, may have the asset 530, and may have authentication to use the asset 530. For example, the first user device 515 may purchase the asset 530 from a software repository (e.g., of the asset management system 505) or from a third user device. In the example illustrated in FIG. 5, the asset 530 is a digital instance of a video game titled "Call of Speed: Polystace". The asset management system 505 can receive from the first user device 515 a request indicating that the first user 510 desires to sell, rent, loan, license, and / or transfer the asset 530 and / or has authentication to use the asset 530. The transfer may be permanent as in the case of a sale, or may be temporary as in the case of a rental or loan.

[0062] In some examples, the request may identify a second user 520 and / or a second user device 525 associated with the second user 520. In some examples, the asset management system 505 may identify the second user 520 and / or the second user device 525 associated with the second user 520 as part of a matchmaking process such as the matchmaking process shown in FIG. 6, for example. Before the usability of the asset 530 is transferred, the second user device 525 does not have authentication to use the asset 530. To transfer the usability of the asset 530 from the first user device 515 to the second user device 525, the asset management system 505 can invalidate the authentication to use the asset 530 on the first user device 515 and can enable the authentication to use the asset 530 on the second user device 525. After the transfer, the second user device 525 has authentication to use the asset 530, and the first user device 515 no longer has authentication to use the asset 530.

[0063] The asset management system 505 can manage one or more migrations of other assets corresponding to the transfer of the availability of the asset 530 from the first user device 515 to the second user device 525. For example, the asset management system 505 can receive the transfer of the asset 545 from the second user device 525 and / or the second user 520. The asset management system 505 can transfer the asset 540 to the first user device 515 and / or the first user 510. In some examples, the asset 540 and / or the asset 545 include fiat currency funds, platform-specific funds (e.g., gift cards and / or store points), another instance of the same video game as the asset 530, an instance of a video game different from the asset 530, in-game content of the same video game as the asset 530, in-game content of a video game different from the asset 530, or a combination thereof. In some examples, the asset 540 includes at least a portion of the asset 545. In some examples, the asset 545 includes at least a portion of the asset 540.

[0064] For example, in one exemplary example, the asset management system 505 can receive a request to transfer asset 530 from the first user device 515, can invalidate the authentication to use asset 530 on the first user device 515, and can provide asset 540 (e.g., a predetermined amount of funds) to the first user device 515 and / or the first user 510 in exchange for the authentication to use asset 530. Next, the asset management system 505 can later identify the second user 520 and / or the second user device 525 by, for example, receiving a request from the second user 520 and / or the second user device 525 that is attempting to obtain authentication to use asset 530, by sending an inquiry to the second user 520 and / or the second user device 525 regarding whether the second user 520 is interested in obtaining authentication to use asset 530, and / or via the matching process of FIG. 6. The second user 520 and / or the second user device 525 can provide asset 545 (e.g., a second predetermined amount of funds) to the asset management system 505, and in exchange, the asset management system 505 can enable the authentication to use asset 530 on the second user device 525. In some examples, asset 545 can include a greater amount of funds than asset 540. In some examples, a portion of asset 545 (e.g., a portion of the funds amount of asset 545) can be provided to an entity 550 other than the two users or their devices, such as one or more developers of asset 530, one or more publishers of asset 530, one or more previous owners of asset 530, the asset management system 505 itself, or a combination thereof.

[0065] In another exemplary example, the asset management system 505 can receive a request to transfer asset 530 from the first user device 515, and initiate a matchmaking process, such as the matchmaking process shown in FIG. 6, to identify a second user 520 and / or a second user device 525 for the asset management system 505. Through the matchmaking process, the asset management system 505 can provide information regarding the second user 520 and / or the second user device 525 to the first user 510 and / or the first user device 515. Through the matchmaking process, the asset management system 505 can provide information regarding the first user 510 and / or the first user device 515 to the second user 520 and / or the second user device 525. In some examples, the first user 510 and / or the first user device 515 can select the second user 520 and / or the second user device 525 as the recipient of the authentication to use asset 530, and then the asset management system 505 can automatically perform the transfer of the authentication to use asset 530 from the first user device 515 to the second user device 525 when the second user 520 and / or the second user device 525 provides asset 545. In some examples, the second user 520 and / or the second user device 525 can select the first user 510 and / or the first user device 515 as the seller who chooses to purchase the authentication to use asset 530, and then the asset management system 505 can automatically perform the transfer of the authentication to use asset 530 from the first user device 515 to the second user device 525 when the second user 520 and / or the second user device 525 provides asset 545.In some examples, as soon as the asset management system 505 identifies both the second user 520 and / or the second user device 525 and the first user 510 and / or the first user device 515, the asset management system 505 can automatically effect a transfer of the use of the asset 530 from the first user device 515 to the second user device 525, and the asset 545 is provided by the second user 520 and / or the second user device 525. In some examples, when the asset management system 505 receives the asset 545, the asset management system 505 transfers at least a portion of the asset 545 to the first user 510 and / or the first user device 515 as the asset 540, and in some examples, another portion of the asset 545 is transferred to another entity 550. In some examples, the management platform 505 does not store the asset 545, but immediately conveys at least a portion of the asset 545 to the first user 510 and / or the first user device 515 as the asset 540, and in some examples, another portion of the asset 545 is transferred to another entity 550. In some examples, the asset 540 is the asset 545. In some cases, the asset 540 is less than the asset 545 (e.g., includes less funds than the asset 545). In some cases, the asset 540 is more than the asset 545 (e.g., includes more funds than the asset 545, or additional other assets), and the additional asset(s) are provided by the asset management system 505 and / or other entity 550, e.g., to facilitate use of the asset management system 505 for such a transfer.

[0066] In some examples, the first user 510 and / or the first user device 515 can also provide additional asset(s) along with the asset 530. For example, the first user 510 and / or the first user device 515 can provide a certain amount of funds to the asset management system 505. The additional asset(s) can, in some examples, be provided from the asset management system 505 to another entity 550.

[0067] In some examples, the asset management system 505 includes a distributed ledger such as the blockchain ledger 300. In some examples, transactions that record the transfer of asset 530, asset 540, and / or asset 545 can be stored in the distributed ledger by the asset management system 505. In some examples, smart contracts corresponding to the transfer of asset 530, asset 540, and / or asset 545 can be stored in the distributed ledger by the asset management system 505, and the transfer of asset 530 can be automatically executed after verification that the transfer(s) of asset 540 and / or asset 545 has been completed, etc., and can be executed to effect the transfer of asset 530, asset 540, and / or asset 545 when certain conditions are met. In some examples, tokens corresponding to asset 530, asset 540, and / or asset 545 can be stored in the distributed ledger by the asset management system 505 and / or transferred by the asset management system 505 using the distributed ledger.

[0068] In some examples, as a result of the transfer, the asset management system 505 can change the content stored in and / or that can be stored in the first user device 515 and / or the second user device 525. For example, as part of disabling authentication to use asset 530 on the first user device 515, the asset management system 505 can delete asset 530 from the first user device 515 or cause asset 530 to be deleted from the first user device 515. As part of enabling authentication to use asset 530 on the second user device 525, the asset management system 505 can, for example, send asset 530 to the second user device 525 from a software repository or cause asset 530 to be downloaded to the second user device 525. In some examples, authentication to use asset 530 also includes authentication to download asset 530 from the software repository of the asset management system 505.

[0069] In some examples, the asset management system 505 is associated with managing assets, migrations, and / or user devices related to a particular platform or ecosystem, such as the Sony (R) PlayStation (R) platform or ecosystem. In some examples, the asset management system 505 can manage assets, migrations, and / or user devices across multiple platforms or ecosystems. For example, a first user 510 can exchange an instance of a video game for a PC (e.g., an instance as asset 530) with a different instance of the same video game for a Sony (R) PlayStation (R) console of the first user 510 (e.g., an instance as asset 540 and / or asset 545).

[0070] FIG. 6 is a conceptual diagram illustrating an example of an interface 600 for matchmaking between users to transfer the availability of an asset 630. In the exemplary illustration of FIG. 6, the asset 630 is in-game content of a video game titled "Pirate’s Flag III", specifically downloadable content (DLC). The asset 630 is being sold by a user 640 with the username BugHero62.

[0071] In the matchmaking process shown in FIG. 6, the asset management system 505 identifies various users including user 605, user 610, user 615, and user 620 who may be interested in purchasing asset 630 from user 640. Each of the various users identified by the asset management system 505 includes at least one characteristic in common with user 640. For example, user 605 with the username Burger85 shares with user 640 the characteristic of interest in the game with the title "Bounty Hunter IV". In particular, the asset management system 505 identifies that "Bounty Hunter IV" is the most played game for user 605 and is also displayed in the wish list for user 640. The "Propose Trade" button 650 is displayed next to the entry for user 605, enabling user 640 to propose a trade between asset 630 and the "Bounty Hunter IV" game.

[0072] User 610, whose username is Jessica72 and whose most-played game is "Bombs Away", is identified by the asset management system 505 as sharing friend circle characteristics because User 610 belongs to User 640's friend list. User 615, whose username is SteveRacer1 and whose most-played game is "Call of Speed: Police Chase", is identified by the asset management system 505 as sharing the most-played game characteristics because the game "Call of Speed: Police Chase" is also User 640's most-played game. User 620, whose username is SeaCaptain9 and whose most-played game is "Pirate’s Flag III", is identified by the asset management system 505 as sharing game ownership characteristics because both User 620 and User 640 own the game "Pirate’s Flag III" and Asset 630 is particularly relevant because it is in-game content (DLC) related to the game "Pirate’s Flag III". Interface 600 shown in FIG. 6 shows a selection pointer highlighting User 620, which indicates that User 640 is interested in selling Asset 630 to User 620, for example, based on the shared game ownership characteristics between User 620 and User 640.

[0073] FIG. 7 is a conceptual diagram showing an example of an interface 700 for purchasing authentication for using a digital asset 630 related to a video game. The interface 700 is an exemplary interface for potential purchasers of the asset 630, such as a second user 520, a second user device 525, a user 605, a user 610, a user 615, and / or a user 620. The interface 700 includes asset information 705 that identifies the asset 630 as downloadable content (DLC) of the title “Premium Ships” of a video game with the title “Pirate’s flag III” as in-game content. The asset information 705 also identifies that a seller (e.g., user 640) has requested a price of $9.99 for the asset 630, that the original “new” price of the asset 630 was $14.99, and that the average “used” price of the asset 630 was $10.99. The interface 700 includes buttons that enable a purchasing user to purchase the asset 630 at the current price of $9.99, bid with a different amount (such as the amount of $5.99 entered in the bid field), propose a trade of the asset 630 (e.g., in exchange for a different game or in-game content element), or add the asset 630 to the wish list of the user who purchases it. If the purchasing user purchases the asset 630 at the current price of $9.99, $9.99 can be an example of the asset 545, and the transfer can proceed immediately. In some examples, the asset management system 505 can manage the bids for the asset 630, such as automatically selecting the highest bidder at the end of the bidding period. The winning bid can then be an example of the asset 545.

[0074] The interface 700 also includes seller information 710 that identifies information about the user 640 selling the asset 630. For example, the seller information 710 identifies that the username of the user 640 is BugHero62, that the average feedback of the user 640 (e.g., from other purchasing users who purchased from the user 640 using the asset management system 505) is 97.9% positive, that the user 640 is located in North America, that the user 640's most played games include "Call of Speed: Police Chase" and "Pirate’s Flag III", and that the user 610 Jessica72 is a common friend between the user 640 and the purchasing user. The interface 700 includes a button for contacting the seller, whereby the asset management system 505 can open a communication channel between the user 640 and the purchasing user. The interface 700 includes a button for viewing other assets sold by the user 640, whereby the asset management system 505 may be able to identify other assets sold by the user 640 to the purchasing user in addition to the asset 630.

[0075] FIG. 8 is a conceptual diagram showing an example of an interface 800 for evaluating the value of a digital asset 630 related to a video game. The interface 800 of FIG. 8 may be an interface for a seller user, such as user 640. The interface 800 identifies a portion of the same asset information 705 as the interface 700 of FIG. 7, such as that the original “new” price of the asset 630 is $14.99 and the average “used” price of the asset 630 is $10.99. This information can be used to evaluate the price requested by user 640, for example, to identify whether the price requested by user 640 is average, lower than average, or higher than average. The interface 800 includes a “requested price” field 805 into which user 640 can enter the price at which user 640 wishes to sell the asset 630. In some examples, the requested price can be an “instant purchase” price at which a purchasing user can immediately purchase the asset 630 without going through a bidding process. In some examples, the requested price may be the minimum bid that a purchasing user can make on the asset 630, and the asset management system 505 still manages the bidding process even after a bid has been made. The interface 800 includes an alert indicating that the price included in the “requested price” field 805 is $9.99, which is lower than the average “used” price of the asset 630, which is $10.99.

[0076] The interface 800 also includes, for example, a graph 840 of the "new" price of the asset 630 over time from, for example, a formal software repository or marketplace. The graph 840 shows, for example, that the "new" price of the asset 630 has varied over time based on various sales, price cuts, price increases, etc. The interface 800 includes, for example, a graph 845 of the average "used" price of the asset 630 over time based on various transitions such as the transition of FIG. 5 managed by the asset management system 505. The graph 845 shows that the average "used" price of the asset 630 varies over time, which is somewhat similar to but may be somewhat independent of the "new" price of the asset 630 over time in the graph 840. Both the graph 840 and the graph 845 include a dashed horizontal line representing the price of $9.99 requested by the user 640.

[0077] FIG. 9 is a conceptual diagram showing an example of an interface 900 that assists a user in onboarding the user onto a platform and converting video game assets 905 associated with another platform into corresponding video game assets 910 associated with the platform. As described above, in some examples, the asset management system 505 can manage assets, migrations, and / or user devices of multiple platforms or ecosystems. The interface 900 identifies video game assets 905 owned by the user on other platforms or ecosystems, such as a PC or game console platform or ecosystem. The video game assets 905 include an instance of the video game "Call of Speed: Police Chase" for the PC platform, an instance of the video game "Bounty Hunter IV" for the game console platform, and an instance of the video game "Pirate’s Flag III" for the game console platform. In the example of FIG. 9, the asset management system 505 associated with the Sony (registered trademark) PlayStation (registered trademark) platform or ecosystem identifies corresponding instances of the same video games available on the Sony (registered trademark) PlayStation (registered trademark) platform or ecosystem as the video game assets 910. For example, in the interface 900, the asset management system 505 identifies an instance of the video game "Call of Speed: Police Chase" for the Sony (registered trademark) PlayStation (registered trademark) 5 platform, an instance of the video game "Bounty Hunter IV" for the Sony (registered trademark) PlayStation (registered trademark) 5 platform, and an instance of the video game "Pirate’s Flag III" for the Sony (registered trademark) PlayStation (registered trademark) 5 platform.

[0078] The interface includes a query 930 that asks the user whether they want to automatically sell video game assets 905 for other platforms and use the funds from these sales to purchase video game assets 910 for the Sony (registered trademark) PlayStation (registered trademark) platform the user is participating in. The query 930 includes a "Yes" button that causes the asset management system 505, as discussed with respect to FIG. 5, to sell video game assets 905 for other platforms to one or more other users and / or user devices such as user 920 and / or user device 925. For example, the video game assets 905 can be an example of asset 530, the user 920 can be an example of a second user 520, and the user device 925 can be an example of a second user device 525. Funds from user 920 and / or user device 925 can be an example of asset 540 and / or asset 545 and can be automatically applied to the purchase of video game assets 910 by the asset management system 505. In some examples, the asset management system 505 can purchase video game assets 910 as new video game assets from an official software repository or marketplace. In some examples, the asset management system 505 can purchase video game assets 910 as used video game assets from a seller user and / or seller user device. In such examples, the video game assets 910 can be an example of asset 530, the seller user can be an example of a second user 520, and the seller user device can be an example of a second user device 525. The query 930 includes a "No" button that does not execute the proposed transfer of video game assets 905 with respect to video game assets 910.

[0079] FIG. 10 is a block diagram 1000 showing an authentication process for managing user authentication for the transfer of asset usability. A first user device 1015 is associated with a first user 1010, while a second user device 1025 is associated with a second user 1020. The first user device 1015 and / or the first user 1010 submit a request 1035 to transfer authentication for using an asset 1030 to an asset management system 505. In some examples, the request 1035 is a request to transfer authentication for using the asset 1030 from the first user device 1015. In such examples, the first user 1010 and the first user device 1015 are examples of a first user 510 and a first user device 515, respectively. In some examples, the request 1035 is a request to transfer authentication for using the asset 1030 from another user device to the first user device 1015. In such examples, the first user 1010 and the first user device 1015 are examples of a second user 520 and a second user device 525, respectively.

[0080] The second user 1020 can be a parent, guardian, supervisor, collaborator, friend, and / or family member of the first user 1010. The asset management system 505 identifies settings and / or rules related to the first user 1010, the first user device 1015, the second user 1020, the second user device 1025, and / or the asset 1030. The settings and / or rules can identify conditions under which the second user 1020 and / or the second user device 1025 must provide authentication before a requested transfer can be executed by the asset management system 505. When the conditions are met, the asset management system 505 sends an alert to the second user device 1025 of the second user 1020. The second user device 1025 can be an example of a user device 130, a console 228, an entertainment system 1300, or a combination thereof. In some examples, the second user device 1025 is a smartphone, a mobile handset, and / or a wireless communication device. The second user device 1025 can display an alert 1040. The alert 1040 can identify a request 1035, the asset 1030, details of the requested transfer of the asset 1030, additional information about the asset 1030 (e.g., the type of game or in-game content), or a combination thereof. For example, the alert 1040 can indicate an age rating of the asset 1030, such as an Entertainment Software Rating Board (ESRB) rating of the asset 1030. In some examples, the alert 1040 can indicate a user rating and / or review of the asset 1030.

[0081] Asset 1030 is an asset that is authenticated for use by the first user device 1015. If request 1035 attempts to transfer the authentication for its use from the first user device 1015, alert 1040 can identify the usage history of asset 1030 on the first user device 1015, for example, to ensure that the first user 1010 is not attempting to sell a favorite game or piece of in-game content. Alert 1040 can identify the price at which the first user 1010 is attempting to sell, rent, license, or otherwise transfer asset 1030, such as the price requested in the price request field 805. Alert 1040 can identify either the asset information 705 and / or the seller information 710 within interface 700 and / or interface 800.

[0082] The second user device 1025 can send a response 1045 to the asset management system 505. Response 1045 responds to alert 1040 and indicates whether user 1020 authenticates or rejects request 1035. If response 1045 indicates that user 1020 authenticates request 1035, the asset management system 505 can perform the transfer requested by request 1035, as described with respect to the transfer in FIG. 5, and can send a confirmation 1050 indicating that response 1045 has been received and that response 1045 is an authentication to the first user 1010 and / or the first user device 1015. If response 1045 indicates that user 1020 rejects request 1035, the asset management system 505 can cancel and / or prohibit the transfer requested by request 1035 and can send a confirmation 1050 indicating that response 1045 has been received and that response 1045 has rejected request 1035 to the first user 1010 and / or the first user device 1015.

[0083] FIG. 11A is a conceptual diagram 1100 showing the generation of a smart contract and the entry of the smart contract into a distributed ledger according to one aspect of the present disclosure. The distributed computing architecture includes a plurality of computing systems (referred to herein as computers) that can be an entertainment system 1300 that stores and modifies a distributed ledger. The first computer submits a request 1105 requesting an entry of a smart contract with specific rules into the distributed ledger. The second computer submits a response 1110 indicating that the second computer has generated a new block that enters the distributed ledger along with the requested smart contract. The third, fourth, and fifth computers submit verifications 1120A-1120C indicating that they have verified that the block accurately executes the smart contract, that the code of the smart contract can be executed (e.g., without syntax errors or other errors), that all parties involved in the smart contract have submitted consent to the conditions of the smart contract, that the on-chain pointer accurately points to a valid off-chain smart contract code, and / or that sufficient funds have been allocated to charge the execution fee for the intended payload elements. In response to the verification of a certain number of devices, the second computer submits an entry confirmation indicating that the new block with the requested smart contract has successfully entered the distributed ledger.

[0084] A process similar to the process shown in FIG. 11A may be used to enter a token, for example, together with corresponding verifications 1120A - 1120C to verify that the token relates to a valid type of digital asset, that the on - chain pointer accurately points to valid off - chain media or metadata, and / or that sufficient funds are allocated to charge for the execution of the intended payload elements. A process similar to the process shown in FIG. 11A may be used to enter a transaction, for example, together with corresponding verifications 1120A - 1120C to verify whether the transferor has a sufficient amount of assets (e.g., whether the transferor owns the token to be transferred) for the transaction to occur and / or that sufficient funds are allocated to charge for the execution of the intended payload elements.

[0085] FIG. 11B is a conceptual diagram 1150 showing the execution of a smart contract according to one aspect of the present disclosure. The first computer submits a proof 1155 that the first computer executed the smart contract code, identified that the conditions in this smart contract were met, and identified that an action was taken. The second, third, and fourth computers submit verifications 1110A - 1110C that identify that the second, third, and fourth computers executed the smart contract code, verified that the conditions in this smart contract were met, and verified that an action was taken. The fifth computer indicates an error 1115 without verification. The third computer indicates an action 1120, which indicates that the third computer executed the smart contract code and executed an action in response to a certain number of devices verifying (e.g., verifications 1110A - 1110C).

[0086] FIG. 12 is a flowchart 1200 showing operations for authentication reconstruction regarding the usability of digital assets according to one aspect of the present disclosure. At least a subset of operations 1200 can be performed by an authentication management system, which can include, for example, network environments 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, network environment 200, console 228, one or more servers 218, blockchain ledger 300, asset management system 505, first user device 515, second user device 525, a user device of any of users 605 - 620, the user device of user 640, user device 925, first user device 1015, second user device 1025, the computing devices of FIGS. 11A - 11B, entertainment system 1300, a system, an apparatus, a non-transitory computer-readable storage medium integrated with a program executed by a processor, or a combination thereof.

[0087] In operation 1205, the authentication management system is configured to identify and can identify assets related to a video game. A first user device is authenticated to use the asset. The first user device is associated with a first user. Examples of assets include media file 202, object file 216, activity 251, zone 252, actor 254, mechanic 256, game media 258, assets identified by payload 330, assets identified by payload 360, assets identified by payload 390, token 400, asset 530, asset 630, video game asset 905, video game asset 910, asset 1030, assets whose transfer is controlled using the smart contract(s) of FIGS. 11A-11B, or combinations thereof. Examples of the first user include first user 510, second user 520, user 605, user 610, user 615, user 620, user 640, user 920, first user 1010, second user 1020, or combinations thereof. Examples of the first user device include user device 130, console 228, first user device 515, second user device 525, user device 925, first user device 1015, second user device 1025, the computing devices of FIGS. 11A-11B, entertainment system 1300, or combinations thereof.

[0088] In some examples, the asset is an instance of a video game, such as any of the video games shown in FIGS. 5-10.

[0089] In some examples, the asset includes in-game content related to the video game. The in-game content is available within the video game for use by a player of the video game during gameplay by the player. The player can be, for example, the first user of operation 1205 prior to the transitions of operations 1215-1220. The player can be, for example, the second user of operation 1210 after the transitions of operations 1215-1220.

[0090] In operation 1210, the authentication management system is configured to identify and can identify a second user. A second user device associated with the second user lacks authentication for using the asset. Examples of the second user include any of the exemplary users listed above as examples of the first user in operation 1205. Examples of the second user device include any of the exemplary user devices listed above as examples of the first user device in operation 1205. In some examples, the authentication management system identifies the second user through the matching process shown in FIG. 6.

[0091] In an exemplary example, the first user in operation 1205 is an example of the first user 510, the first user device in operation 1205 is an example of the first user device 515, the second user in operation 1210 is an example of the second user 520, and the second user device in operation 1210 is an example of the second user device 525.

[0092] In some examples, the authentication management system is configured to identify and can identify characteristics of the first user. The authentication management system can identify multiple characteristics of multiple users. The multiple users include the second user. The authentication management system can identify that the second user shares characteristics with the first user among the multiple characteristics of the multiple users. In such examples, identifying the second user in operation 1210 is based on characteristics shared by the first user and the second user. Examples of characteristics include characteristics identified by the matching process and interface 600 of FIG. 6.

[0093] In operation 1215, the authentication management system is configured to receive and can receive a notification of the transfer of asset availability.

[0094] In some examples, the notification of the transfer of asset availability includes receiving confirmation of the transfer from the first user device. For example, the confirmation can be a response to a query that asks the first user whether they confirm that they want to transfer this asset. The confirmation can be, for example, a selection of a price via the price request field 805.

[0095] In some examples, the notification of the transfer of asset availability includes receiving a notification of a second transfer of a second asset from the second user's account. The second transfer is in exchange for the transfer of asset availability. Examples of the second transfer include the transfer of asset 545 as shown in FIG. 5 and / or the transfer of asset 540 as shown in FIG. 5. In some examples, the second asset is the amount of funds that pays for the transfer of asset availability. In some examples, the authentication management system is configured to receive bids for the amount of funds from the second user device and can receive, and is configured to receive approval of the bid from the first user device, such as the bid process shown in interface 700 of FIG. 7 and / or interface 800 of FIG. 8. In some examples, the authentication management system is configured to identify an evaluation value associated with the transfer of asset availability and can identify, and the amount of funds is based on the evaluation value as shown in the evaluation process and interface 800 of FIG. 8.

[0096] In some examples, the authentication management system is configured to identify and can identify a second asset related to a video game. The asset is associated with a first platform to which a first user device belongs, and the second asset is associated with a second platform to which a third user device belongs. The third user device is associated with the first user. In response to receiving a notification, the authentication management system can automatically enable authentication for the third user device to use the second asset. This example is shown in interface 900 of FIG. 9. For example, the Sony (registered trademark) PlayStation (registered trademark) 5 console of interface 900 can be an example of the third user device, and the PC or game box of interface 900 can be an example of the first user device. Similarly, the Sony (registered trademark) PlayStation (registered trademark) platform of interface 900 may be an example of the second platform, and the PC or game box platform of interface 900 may be an example of the first platform. In some examples, the second asset is a variation of an asset usable on the second platform, while the asset is usable on the first platform. For example, video game asset 910 is a variation of video game asset 905 usable by the Sony (registered trademark) PlayStation (registered trademark) platform, and video game asset 905 is usable by other platforms.

[0097] In some examples, the authentication management system is configured to identify and can identify that the type of the asset matches a particular type in the rule. In response to identifying that the type of the asset matches a particular type within the rule, the authentication management system can automatically request authentication for a transfer from a third user device associated with a third user. The authentication management system can receive authentication regarding the transfer from the third user device associated with the third user, and the notification includes the authentication regarding the transfer. Examples of authentication include authentication in response 1045 and / or confirmation 1050. In some examples, the third user is a family member of the first user, such as a parent, guardian, or sibling of the first user.

[0098] In operation 1220, in response to receiving the notification, the authentication management system is configured to and can automatically invalidate the authentication for the first user device to use the asset.

[0099] In operation 1225, in response to receiving the notification, the authentication management system is configured to and can automatically enable the authentication for the second user device to use the asset.

[0100] In some examples, the authentication management system is configured to identify, and can identify, a distributed ledger including a plurality of blocks. Each block of at least a subset of the plurality of blocks includes a hash of at least a portion of another block of the plurality of blocks. The authentication management system can cause an additional block to be added to the distributed ledger. The payload of the additional block includes a record of the transfer of availability of an asset. The additional block includes a hash of at least a portion of the plurality of blocks of the distributed ledger. In some examples, the authentication management system is configured to generate, and can generate, an additional block. In some examples, the distributed ledger is a blockchain ledger. For example, examples of distributed ledgers include blockchain ledger 300 and / or DAG ledger. In some examples, the asset includes a non-fungible token (NFT) related to a video game, such as token 400. In some examples, one or more of the plurality of blocks within the distributed ledger identify a smart contract that identifies conditions. Detection of the conditions is configured to trigger a transfer of availability of an asset according to the smart contract. The notification can include verification of the detection of the conditions, such as verification of the smart contract shown in FIGS. 11A-11B.

[0101] FIG. 13 is an exemplary user electronic entertainment system that can be used to initiate interactive content and provide a dynamic interface according to one aspect of the present disclosure. The entertainment system 1300 of FIG. 13 includes a main memory 1305, a central processing unit (CPU) 1310, a vector unit 1315, a graphics processing unit 1320, an input / output (I / O) processor 1325, an I / O processor memory 1330, a peripheral interface 1335, a memory card 1340, a universal serial bus (USB) interface 1345, and a communication network interface 1350. The entertainment system 1300 further includes an operating system read-only memory (OS ROM) 1355, an audio processing unit 1360, an optical disk control unit 1370, and a hard disk drive 1365, which are connected to the I / O processor 1325 via a bus 1375.

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

[0103] The CPU 1310, vector unit 1315, graphics processing unit 1320, and I / O processor 1325 in FIG. 13 communicate via a system bus 1385. Further, the CPU 1310 in FIG. 13 communicates with the main memory 1305 via a dedicated bus 1380. On the other hand, the vector unit 1315 and the graphics processing unit 1320 may communicate via a dedicated bus 1390. The CPU 1310 in FIG. 13 executes programs stored in the OS ROM 1355 and the main memory 1305. The main memory 1305 in FIG. 13 may include pre-stored programs and programs transferred via the I / O processor 1325 from a CD-ROM, DVD-ROM, or other optical disk (not shown) using the optical disk control unit 1370. The I / O processor 1325 in FIG. 13 may also enable the introduction of content transferred via a wireless network or other communication network (e.g., 4G, LTE, 1G, etc.). The I / O processor 1325 in FIG. 13 mainly controls data exchange between various devices of the entertainment system 1300 including the CPU 1310, vector unit 1315, graphics processing unit 1320, and controller interface 1335.

[0104] The graphics processing unit 1320 in FIG. 13 executes graphics instructions received from the CPU 1310 and the vector unit 1315 to generate an image for display on a display device (not shown). For example, the vector unit 1315 in FIG. 13 may convert an object from three-dimensional coordinates to two-dimensional coordinates and send the two-dimensional coordinates to the graphics processing unit 1320. Further, the audio processing unit 1360 executes instructions to generate an audio signal output to an audio device such as a speaker (not shown). Other devices may be connected to the entertainment system 1300 via a USB interface 1345 and a communication network interface 1350 such as a wireless transceiver, and these may be embedded within the system 1300 or as part of some other component such as a processor.

[0105] The user of the entertainment system 1300 in FIG. 13 provides commands to the CPU 1310 via the peripheral interface 1335, thereby enabling the use of various different available peripheral devices (e.g., controllers) known in the art. For example, the user may command the CPU 1310 to store specific game information on the memory card 1340 or other non-transitory computer-readable storage media, or may command a character in the game to perform some specific actions.

[0106] The present disclosure relates to applications that may be operable by various end-user devices. For example, the end-user device may be a personal computer, a home entertainment system (e.g., Sony PlayStation2 (registered trademark) or Sony PlayStation3 (registered trademark) or Sony PlayStation4 (registered trademark) or Sony PlayStation5 (registered trademark)), a portable game device (e.g., Sony PSP (registered trademark) or Sony Vita (registered trademark)), or, although lower, a home entertainment system of a different manufacturer. The methods described herein are fully intended to be operable on various devices. Aspects of the present disclosure may also be implemented with neutrality between titles and / or may be utilized across various titles from various publishers.

[0107] Aspects of the present disclosure may be implemented in an application that may be operable using various 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 media such as optical or magnetic disks, and volatile media such as dynamic memory. Common forms of non-transitory computer-readable media include, for example, floppy disks, flexible disks, hard disks, magnetic tape, any other magnetic media, CD-ROM disks, digital video disks (DVDs), any other optical media, RAM, PROM, EPROM, FLASHEPROM, and any other memory chip or cartridge.

[0108] Various forms of transmission media may be involved in conveying one or more sequences of one or more instructions to a CPU for execution. A bus transmits data to system RAM from which the CPU retrieves and executes instructions. Instructions received by system RAM can optionally be stored on a fixed disk either before or after execution by the CPU. Various forms of storage, as well as other network interfaces and network topologies for implementing them, may likewise be implemented.

[0109] In some aspects of the present disclosure, a computer-readable storage device, medium, and memory can include a cable or wireless signal including, for example, a bitstream. However, when mentioned, non-transitory computer-readable storage media explicitly exclude media such as energy, carrier signals, electromagnetic waves, and signals themselves.

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

Claims

1. A system for authentication reconstruction regarding the usability of digital assets, a memory for storing instructions, one or more processors, by execution of the instructions by the one or more processors, causing the one or more processors to identify an asset related to a video game, wherein a first user device is authenticated to use the asset and the first user device is associated with a first user, the identifying; identify a second user, wherein a second user device associated with the second user lacks authentication to use the asset, the identifying; receive a notification of a transfer of the usability of the asset; in response to receiving the notification, automatically invalidate authentication for the first user device to use the asset; in response to receiving the notification, automatically enable authentication for the second user device to use the asset; and the one or more processors for causing the above to be performed. A system comprising the one or more processors.

2. The system according to claim 1, wherein the asset is an instance of the video game.

3. The system according to claim 1, wherein the asset includes in-game content related to the video game, and the in-game content is usable within the video game by a player of the video game during gameplay of the video game by the player.

4. The system according to claim 1, wherein the notification of the transfer of the usability of the asset includes receiving confirmation of the transfer from the first user device.

5. The notification of the transfer of the usability of the asset includes receiving a notification of a second transfer of a second asset from the account of the second user, and the second transfer is in exchange for the transfer of the usability of the asset. The system according to claim 1.

6. The system according to claim 5, wherein the second asset is an amount of funds for making a payment for the transfer of the usability of the asset.

7. The execution of the instructions by the one or more processors causes the one or more processors to receive a bid for the amount of funds from the second user device; receive approval of the bid from the first user device; The system according to claim 6, which is implemented.

8. The execution of the instructions by the one or more processors causes the one or more processors to identify an evaluation value associated with the transfer of the usability of the asset, wherein the amount of funds is based on the evaluation value, and the identifying; The system according to claim 6, which is implemented.

9. The execution of the instructions by the one or more processors causes the one or more processors to identify the characteristics of the first user; identify the characteristics of a plurality of users, wherein the plurality of users includes the second user, and the identifying; identifying that the second user also shares the characteristics of the first user among the plurality of characteristics of the plurality of users, and the identifying of the second user is based on the characteristics shared by the first user and the second user; The system according to claim 1, which is implemented.

10. Execution of the instructions by the one or more processors causes the one or more processors to identify a second asset related to the video game, wherein the asset is associated with a first platform to which the first user device belongs, the second asset is associated with a second platform to which a third user device belongs, and the third user device is associated with the first user; and automatically enable authentication for the third user device to use the second asset in response to receiving the notification; and The system according to claim 1, which causes the above to be implemented.

11. The system according to claim 10, wherein the second asset is a variation of the asset usable on the second platform, and the asset is usable on the first platform.

12. Execution of the instructions by the one or more processors causes the one or more processors to identify that the type of the asset matches a specific type in a rule; automatically request authentication regarding the migration from a third user device associated with the third user in response to identifying that the type of the asset matches the specific type in the rule; receive the authentication regarding the migration from the third user device associated with the third user, wherein the notification includes the authentication regarding the migration; and The system according to claim 1, which causes the above to be implemented.

13. The system according to claim 12, wherein the third user is a family member of the first user.

14. Execution of the instructions by the one or more processors causes the one or more processors to Identifying a distributed ledger including a plurality of blocks, each block of at least a subset of the plurality of blocks including the hash of at least a part of another block of the plurality of blocks, the identifying; Adding an additional block to the distributed ledger, the payload of the additional block including a record of the transition of the usability of the asset, the additional block including the hash of at least a part of the plurality of blocks of the distributed ledger, the adding; The system according to claim 1, causing the above to be implemented.

15. By execution of the instructions by the one or more processors, the one or more processors are caused to Generate the additional block; The system according to claim 14, causing the above to be implemented.

16. The system according to claim 14, wherein the distributed ledger is a blockchain ledger.

17. The system according to claim 14, wherein the asset includes a non-fungible token (NFT) related to the video game.

18. One or more blocks of the plurality of blocks in the distributed ledger identify a smart contract that identifies a condition, the detection of the condition being configured to trigger the transition of the usability of the asset according to the smart contract, the notification including verification of the detection of the condition, the system according to claim 14.

19. A method for authentication reconstruction regarding the usability of a digital asset, comprising: Identifying an asset related to a video game, wherein a first user device is authenticated to use the asset, and the first user device is associated with a first user, the identifying; Identifying a second user, wherein the identification is that a second user device associated with the second user lacks authentication for using the asset, Receiving a notification of a transfer of usability of the asset, In response to receiving the notification, automatically invalidating authentication for the first user device to use the asset, In response to receiving the notification, automatically validating authentication for the second user device to use the asset, the method comprising.

20. A non-transitory computer-readable storage medium having an embodied program executable by a processor for performing a method of authentication reconfiguration regarding usability of a digital asset, the method comprising: Identifying an asset related to a video game, wherein the first user device is authenticated to use the asset and the first user device is associated with a first user, Identifying a second user, wherein the identification is that a second user device associated with the second user lacks authentication for using the asset, Receiving a notification of a transfer of usability of the asset, In response to receiving the notification, automatically invalidating authentication for the first user device to use the asset, In response to receiving the notification, automatically validating authentication for the second user device to use the asset, The non-transitory computer-readable storage medium comprising.

Images