Secure matchmaking, asset migration, 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 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 disks or cartridges. More recently, users can obtain video games as digital assets on their devices by, for example, 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 by downloading digital copies of in-game content from, for example, 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, transferring the ownership of the video game and the ability to use the video game from the first user to the second user. Conventionally, there has been no way to resell a digital instance of a video game or digital in-game content of a video game from one user to another.

Summary of the Invention

[0004] Embodiments of this technology include systems and methods for reconfiguring the usability of digital assets. In some examples, an asset management system identifies assets related to a video game. A first user device is authorized to use the assets. 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 authorization to use the assets. The asset management system receives notifications of asset usability transitions, such as a notification that the second user has made a transition payment or a notification that the conditions of a smart contract have been met. In response to receiving a notification, the asset management system automatically deactivates the authorization for the first user device to use the assets and automatically enables the authorization for the second user device to use the assets. Thus, after the transition, the second user device is authorized to use the assets, while the first user device is no longer authorized to use the assets.

[0005] In one example, a system for reconfiguring authentication regarding the availability of digital assets is provided. This system includes memory and one or more processors coupled to the memory (e.g., processors implemented in circuitry). One or more processors are configured and can perform the following: identify assets related to a video game, where a first user device is authenticated to use the assets 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 assets; receive notifications of asset availability transitions; automatically disable authentication for the first user device to use the assets in response to receiving notifications; and automatically enable authentication for the second user device to use the assets in response to receiving notifications.

[0006] Another example provides a method for reconfiguring authentication regarding the availability of digital assets. This method includes 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; identifying a second user, wherein a second user device associated with the second user lacks authentication to use the asset; receiving a notification of a transition in the availability of the asset; automatically disabling authentication for the first user device to use the asset in response to receiving the notification; and automatically enabling authentication for the second user device to use the asset in response to receiving the notification.

[0007] In another example, a non-temporary computer-readable medium storing instructions thereon, the instructions, when executed by one or more processors, cause one or more processors to perform the following actions: 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 the transition of asset availability; in response to receiving the notification, automatically disable authentication for the first user device to use the asset; and in response to receiving the notification, automatically enable authentication for the second user device to use the asset.

[0008] In another example, an image processing apparatus is provided. The apparatus includes means for identifying assets related to a video game, wherein a first user device is authenticated to use the assets and the first user device is associated with a first user; means for identifying a second user, wherein a second user device associated with the second user lacks authentication to use the assets; means for receiving notifications of changes in asset availability; means for automatically disabling authentication for the first user device to use the assets in response to receiving notifications; and means for automatically enabling authentication for the second user device to use the assets in response to receiving notifications. [Brief explanation of the drawing]

[0009] [Figure 1] This block diagram shows an exemplary network environment in which a system for tracking digital assets related to video games using a distributed ledger, according to one aspect of this disclosure, may be implemented. [Figure 2A] This block diagram shows an exemplary network environment in which a system for combining object data from a universal data system with media content, according to one aspect of this disclosure, may be implemented. [Figure 2B] This is a conceptual diagram showing an illustrative table of various objects and related events according to aspects of this disclosure. [Figure 3] This block diagram shows three consecutive blocks of a distributed ledger that may be used to track digital assets related to video games, according to one aspect of this disclosure. [Figure 4] This block diagram shows an exemplary token, as per one aspect of the present disclosure, that may represent a non-fungible, distributed ledger-tracked digital asset related to a video game. [Figure 5] This block diagram illustrates the transfer of asset availability from a first user device to a second user device according to one aspect of the present disclosure. [Figure 6]This is a conceptual diagram illustrating an example of an interface for user-to-user matchmaking to transfer asset availability, according to one aspect of this disclosure. [Figure 7] This is a conceptual diagram illustrating an embodiment of an interface for purchasing authentication for using digital assets related to video games, according to one aspect of the present disclosure. [Figure 8] This is a conceptual diagram illustrating an embodiment of an interface for evaluating the values ​​of digital assets related to video games, according to one aspect of the present disclosure. [Figure 9] This is a conceptual diagram illustrating an embodiment of an interface that, according to one aspect of the present disclosure, onboards a user onto a platform and assists the user in converting video game assets associated with other platforms into corresponding video game assets associated with the platform. [Figure 10] This block diagram shows an authentication process for managing user authentication for the transfer of asset availability, according to one aspect of this disclosure. [Figure 11A] This is a conceptual diagram illustrating the generation of a smart contract and the entry of a smart contract into a distributed ledger, according to one aspect of this disclosure. [Figure 11B] This is a conceptual diagram illustrating the execution of a smart contract according to one aspect of this disclosure. [Figure 12] This is a flowchart illustrating the operation for reconfiguring authentication regarding the availability of digital assets, according to one aspect of this disclosure. [Figure 13] This figure shows an exemplary electronic entertainment system that may be used in the real-time playback data of streaming media, based on one or more objects displayed therein, according to aspects of the present disclosure. [Modes for carrying out the invention]

[0010] The detailed descriptions provided below are intended to describe the diverse configurations of the subject art and are not intended to represent only the configurations in which the art can be practiced. The accompanying drawings are incorporated herein and constitute part of the detailed description. The detailed description includes specific details intended to provide a more complete understanding of the art. However, it will be clear and obvious that the art is not limited to the specific details described herein and can be practiced without these details. In some examples, structures and components are shown in block diagram form so as not to obscure the concepts of the subject art.

[0011] Methods and techniques for creating, modifying, tracking, authenticating, and / or transferring the usability of digital assets related to video games (or multiple video games). In some examples, the asset management system identifies video game-related assets, such as instances of the video game itself or certain in-game content (e.g., downloadable content (DLC), in-app purchases (IAP), characters, items, environments, save files, gameplay records, etc.). In some examples, assets include non-fungible tokens (NFTs) related to the 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 the 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 a second user during the matchmaking process based on one or more shared characteristics with the first user (e.g., the same favorite games, the same most played games, the same region, the same age group, or the same combination thereof). The second user device associated with the second user lacks authentication to use the asset. The asset management system receives notification of the transfer of asset availability. For example, the notification of the transfer of availability may include notifications that the second user has made a payment for the transfer, that the second user has agreed to make a payment for the transfer, that the transfer has been authenticated by another user (e.g., the parent or guardian of the first or second user), that the conditions of a smart contract have been met, or a combination thereof.In response to receiving a notification, the asset management system automatically disables authentication for the first user device to use the asset and automatically enables authentication for the second user device to use the asset, thereby enabling the asset availability transition. Therefore, after the asset availability transition, the second user device is authorized to use the asset, while the first user device is no longer authorized to use it. In some examples, the asset management system also causes a second transition to occur concurrently with, before, or after the asset availability transition. The second transition may include, for example, the transfer of a second asset (e.g., funds, content related to the same video game, content related to a different video game) from a second user to a first user, from a second user to the asset management system, from the asset management system to the first user, or a combination of these.

[0012] In some examples, an asset may be an instance of a video game. In some examples, an asset may be in-game content such as in-game items, characters, environments (e.g., levels, stages, worlds), objectives, save files, DLC, IAP, or a combination thereof. An asset may be a video game digital media asset, such as a video clip, image, and / or audio clip, which is a media representation of a moment of gameplay in the video game. In some examples, a distributed ledger that tracks the history of the asset is created and stored across multiple devices in a distributed system. In some examples, a unique token (e.g., NFT) may be generated for the asset, and the asset's unique identifier and metadata identify the asset's characteristics. The transfer of asset availability may include the transfer of ownership, the transfer of a license, rental, lease, demo, or a combination thereof. In some examples, the asset management system may update a distributed ledger, such as a blockchain ledger or a directed acyclic graph (DAG) ledger, by notifying of the transfer of asset availability in a new block accompanying the distributed ledger, for example. A new block may contain one or more hashes of at least some of the previous blocks in the distributed ledger.

[0013] The methods and techniques described herein extend the capabilities of a system that manages the availability of digital assets related to video games by providing a process for transferring the availability of such digital assets, for example, by disabling the availability of an asset on one user device and enabling the availability of an asset on another user device in response to trigger conditions. The methods and techniques described herein represent a secure and safe platform for enabling such transfers of asset availability, for example by using smart contracts to securely enable such transfers, distributed ledgers to securely track such transfers, 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 transfers. The methods and techniques described herein enable secure and comprehensive tracking of the history of digital assets, for example, when, how, and by whom a digital asset was created, used, modified, rented to, sold to, purchased by, licensed to, exchanged to, transferred to, and / or otherwise affected.

[0014] Figure 1 shows an exemplary network environment 100 in which a system for tracking digital assets related to video games using a distributed ledger may be implemented according to one aspect of the present disclosure. The network environment 100 may 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. One or more distributed ledgers 150 may be stored across a distributed network 115, which may include one or more interactive content servers 110, one or more platform servers 120, one or more user devices 130, one or more data structures 140, or a combination thereof.

[0015] The interactive content server 110 can maintain, stream, and host interactive media that can be streamed on the user device 130 over a communication network. Such an interactive content server 110 may be implemented in the cloud (e.g., one or more cloud servers). Each piece of media may contain one or more sets of object data that may be available for user participation (e.g., viewing or interacting with an activity). Data relating to the objects shown in the media may be stored in an object file 216 ("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 for 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 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] A set of streaming media and object data may be provided by an Application Programming Interface (API) 160, which enables various types of interactive content servers 110 to communicate with different platform servers 120 and different user devices 130. The API 160 may be specific to the computer programming language, operating system, protocol, etc., of the interactive content server 110 providing the streaming media content titles, the platform server 120 providing the set of media and object data, and the user device 130 receiving it. Similarly, in a network environment 100 containing multiple different types of interactive content servers 110 (or platform servers 120 or user devices 130), there may be a corresponding number of APIs 160.

[0018] User device 130 may include multiple different types of computing devices. For example, user device 130 may include any number of different gaming consoles, mobile devices, laptops, and desktops. In another example, user device 130 may be implemented in the cloud (e.g., one or more cloud servers). Such user device 130 may also be configured to access data from other storage media, such as memory cards or disk drives, which may be appropriate in the case of downloaded services, but are not limited to these. Such device 130 may include standard hardware computing components, such as network and media interfaces, non-temporary computer-readable storage devices (memory), and processors for executing instructions that can be stored in memory, but are not limited to these. These user devices 130 may also run using various different operating systems (e.g., iOS®, Android®), applications, or computing languages ​​(e.g., C++®, JavaScript®). Exemplary user devices 130 are described in detail herein with respect to Figure 13.

[0019] The data structure 140 may 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 a combination thereof. The data structure 140 may be stored on the platform server 120, on the interactive content server 110, on any of the servers 218 (shown in Figure 2A), across one or more different servers, on a single server, across different servers, on any of the user devices 130, in the distributed ledger 150, on devices identified by network locations identified by pointers (e.g., the same resource identifier) ​​recorded in the distributed ledger 150, or a combination thereof. Such data structure 140 may store digital assets related to a video game, such as streaming media, parts thereof, and / or associated sets of object data. Such streaming media may depict one or more objects (e.g., activities) in which a user can participate, as well as / or user-generated content (UGC) (e.g., screenshots, videos, commentaries, mashups, etc.) created by peers, publishers of media content titles, and / or third-party publishers. Parts of streaming media may include images, video clips, audio clips, or combinations thereof. Such UGC may include metadata for searching such UGC. Such UGC may also include information about the media and / or peers. Such peer information may be derived from data collected during peer interaction with objects of interactive content titles (e.g., video games, interactive books, etc.), "bound" to the UGC, and stored together with the UGC.Such bindings extend UGC because they enable UGC to deeply link to objects (e.g., directly launch), provide information about UGC's objects and / or peers, and / or enable users to interact with 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 within activities and / or media content titles, user ID, the 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 image or 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 and restricted to use for a single video game. In some examples, the distributed ledger 150 may be controlled 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 and restricted to use for a single video game console or video game platform. In some examples, the distributed ledger 150 may be controlled 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 video game platforms may be associated with a single manufacturer, device type, form factor, operating system (OS), or a combination thereof.For example, the distributed ledger 150 may be controlled and restricted to use for one or more Sony® PlayStation® platforms and / or for one or more types of Sony® devices, such as Sony® PlayStation® 4, Sony® PlayStation® 5, Sony® PlayStation® Vita®, another Sony® PlayStation® portable gaming console, another Sony® PlayStation® home gaming console, Sony® PlayStation VR® Virtual Reality (VR) system, Sony® PlayStation TV® home entertainment system, Sony® tablet, Sony® mobile handset, or a combination thereof. In some examples, a set of video game consoles or video game platforms may include video game consoles or video game platforms associated with two or more manufacturers, device types, form factors, operating systems (OS), or combinations thereof, enabling, for example, cross-platform support, cross-device type support, cross-OS support, or combinations thereof. Blockchain ledger 300 is an example of distributed ledger 150.

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

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

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

[0025] Such object data (e.g., object file 216) may 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 may store object file 216 and receive queries about object file 216 from UGC server 232. Such queries can be performed 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 a stored content timestamp file 214 may be performed by matching the start and end times of content timestamp file 214 with the start and end times of the corresponding object file 216 sent with the query. Such an object file 216 may also be associated with a matching content timestamp file 214 by the UGC server 232, and this association can be performed by any server, cloud server, any console 228, or any user device 130. In another embodiment, the object file 216 and the content timestamp file 214 may be associated by the 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 converted into non-fungible in-game digital assets using non-fungible tokens, such as token 400 in Figure 4, which are stored in one or more distributed ledgers 150 and whose history is tracked across one or more distributed ledgers 150, by the console 228 and / or server 218. The token corresponding to media file 212 may include metadata related to 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 the non-fungible in-game digital asset tracked in the distributed ledger 150.

[0027] Figure 2B is a conceptual diagram showing an illustrative table of various objects and associated events according to aspects of the present disclosure. As shown in the illustrative table 250 of Figure 2B, such object data (e.g., object file 216) may be associated with event information relating to activity availability changes and may be associated with other objects having associated object information. Media-object binding may form telemetry between objects displayed in at least part 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 gameplay-related data files.

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

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

[0030] Such actor data files 254 may be associated with an entity along with its in-game behavior, may be player controllers, or may be game-controlled, and may change dynamically during gameplay. Such actor data files 254 may include the actor's actor ID, the actor's localizable name, the actor's image, and / or a short description of the actor. Such actor data files 254 may be associated with actor selection events that indicate a change in the player's selected actor(s). Selected actor(s) may represent actors controlled by the player 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 its list of actors when loading save data.

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

[0032] Such a mechanic data file 256 may be associated with a mechanic inventory change event, indicating that the player's inventory has been modified. The inventory may refer to mechanics that the player can use immediately without having to perform any additional steps in the game before using them. Inventory information is used to estimate the player's preparation for various activities that may be advanced to the platform server 120. The game may replace that list of mechanic inventory when loading save data. Mechanics with cooldowns may be considered part of the inventory. Mechanic counts with any non-zero value (e.g., ammo, healing points, etc.) may be treated as "in inventory". Inventory mechanics may be considered a subset of available mechanics.

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

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

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

[0036] Figure 3 is a block diagram showing three consecutive blocks of a blockchain ledger 300 that may be used to track digital assets related to video games, 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 Figure 3.

[0037] Each block contains 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 contain 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 contains the hash 375 of the header 340 of block B335. Similarly, the header 340 of block B335 contains the hash 345 of the header 310 of block A305. Similarly, the header 310 of block A305 contains the hash 315 of the header (not shown) of the previous block (not shown) that precedes block A305 in the blockchain ledger 300. Including the hash of the previous block's header stabilizes the blockchain ledger 300 by preventing any modification of any block in the blockchain ledger 300 after the block has been placed in the blockchain ledger 300. This is because any change to a particular block would render the hash 315 / 345 / 375 of the block header in the next block inaccurate. Furthermore, a modification of the hash of that block header in the next block would render the hash 315 / 345 / 375 of the header of the next block in subsequent blocks 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 with the stored hash 315 / 345 / 375 stored in the next block. In some distributed ledgers, the block header 310 / 340 / 370 may 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 may contain Merkle roots 320 / 350 / 380. 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 payload 330 / 360 / 390 for that block. Any attempt to modify the payload after the block has been entered will change the Merkle root. A verification device can verify that the payload(s) 330 / 360 / 390 has not been modified by calculating the Merkle root and then comparing the calculated Merkle root to the stored Merkle roots 320 / 350 / 380 stored in the block headers 310 / 340 / 370. Changes to payloads 330 / 360 / 390 and / or Merkle roots 320 / 350 / 380 also change the hash of the block and / or the hash of the block header, and the values ​​for them are stored in the next block as hash 315 / 345 / 375. Each payload in each block may contain one or more tokens (e.g., token 400), one or more transactions, one or more smart contracts, other content, or a combination 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 blockchain ledger 300, a timestamp for the request for block generation, 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 attempted, the title of blockchain ledger 300, an identifier regarding what blockchain ledger 300 tracks (e.g., the history of digital assets related to video games), or a combination of these. Each of the added individual elements may further function as information that can be verified by a verification device to identify whether the block and the payload within it are accurate and authorized. 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 may 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 a combination thereof. The token may be, for example, a non-fungible token. Token 400 may 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, a particular portion of token 400 is stored within the payload 330 / 360 / 390 of the blockchain ledger 300 and is therefore stored "on-chain". As discussed with respect to Token 400, certain parts of Token 400 include on-chain pointers that point to data outside of the blockchain ledger 300, such as data structure 140, and such data is stored "off-chain". The payloads 330 / 360 / 390 of the blockchain ledger 300 can store hashes of the off-chain data, and as a result, a verification device can calculate the hash of the off-chain data and compare the calculated hash with the stored hash stored on-chain to verify that the off-chain data is accurate. In some examples, the payloads 330 / 360 / 390 contain one or more smart contracts. The block may contain the code of the smart contract stored within the payloads 330 / 360 / 390 of the blockchain ledger 300, and thus the code is stored on-chain. If payload 330 / 360 / 390 contains a smart contract, the block may contain a hash of the smart contract code and / or a pointer to an off-chain data structure 140 that stores the smart contract code, and thus the code is stored off-chain. In some examples, some of the smart contract code may be stored on-chain, while some of the smart contract code may be stored off-chain.In some examples, smart contracts can be used to create, modify, transfer, or otherwise manage tokens. In some examples, payloads 330 / 360 / 390 include transactions. In some examples, transactions may include the transfer of tokens from one account to another. In some examples, transactions may include changes to specific characteristics of the token or associated digital asset, such as changes to ownership, in-game visual appearance, in-game attributes, authorship, usage license, rental, or a combination thereof.

[0041] In one exemplary embodiment, a first computing device can store a blockchain ledger containing multiple blocks. Each of multiple computing devices (e.g., a decentralized 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 related to 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 have been allocated to claim the execution fee for the intended payload element, for example, in the form of gas on the Ethereum blockchain ledger. In the case of a transaction, the first computing device can verify whether the transferor has a sufficient amount of assets for the transaction to take place (e.g., whether the transferor owns the token to be transferred). 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), verify that the smart contract code is executable (e.g., free from syntax errors or other errors), verify that all parties involved in the smart contract have submitted their agreement to the terms of the smart contract, or a combination of these. 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 the new block. The new block header may include a hash of the latest block or block header of the blockchain ledger 300. The first computing device can generate a new block containing the new block, the new block header, and a payload containing one or more payload elements. The one or more payload elements may 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 nonce values ​​based on the payload elements and include the metadata and nonce values ​​in the new block header. The first computing device can add the new block to multiple blocks of the blockchain ledger 300 in response to verifying the intended payload elements. The first computing device can send the new block to multiple computing devices, each storing the blockchain ledger 300, in response to verifying the intended payload elements. Each of the multiple computing devices also adds a new block to their respective copy of the blockchain ledger 300.

[0043] In another exemplary embodiment, a first computing device can store a blockchain ledger 300 containing multiple blocks. Each of the multiple 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 a message by encrypting at least a portion of the message with the private key. The first computing device can send a message to multiple computing devices other than the first computing device. A second computing device of the multiple 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 contains the intended payload element. The first computing device adds new blocks to multiple blocks in the blockchain ledger 300.

[0044] Figure 3 shows only three blocks 305 / 335 / 365 of blockchain ledger 300, but please understand that any blockchain described herein may be longer or shorter in that it may have more or fewer blocks than three. Furthermore, please understand that other types of distributed ledgers, such as directed acyclic graph (DAG) ledgers, may be used instead of or in addition to blockchain ledger 300.

[0045] In some examples, a distributed ledger may have a nonlinear ledger structure, such as a directed acyclic graph (DAG) ledger structure. 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 (as shown in Figure 3), a DAG ledger, or a combination thereof. In a DAG ledger, each block header contains hashes of blocks (or block headers) of several other “parent” blocks in the DAG ledger, selected randomly or in any other nonlinear manner, rather than just a single previous block (or block header) hash 315 / 345 / 375, as in the blockchain ledger 300. If each block header contains multiple hashes corresponding to different parent blocks or their headers, these hashes can be joined together (e.g., using the Merkle root). In some examples, the number of parent blocks for a given block in the DAG ledger is predetermined. In some embodiments, the number of parent blocks in a given block of a DAG ledger is greater than or equal to a predetermined minimum number of parent blocks, such as two parent minimums or one parent minimum, meaning that each block contains at least a predetermined minimum number of parent blocks. In some cases, each block of a DAG ledger may identify only a single payload element (e.g., a smart contract, token 400, or transaction) rather than multiple payload elements, and therefore may precede the Merkle roots 320 / 350 / 380 of the payload element, or replace this with a hash of the single payload element. In other embodiments, each block may identify multiple payload elements associated with a given period and / or include the Merkle roots 320 / 350 / 380 of the payload elements. In some embodiments, a DAG ledger may offer advantages over a blockchain ledger 300, for example, by providing parallelized validation, which may offer higher throughput and / or improved security compared to a blockchain ledger 300.

[0046] Figure 4 is a block diagram showing an exemplary token 400 that can represent a video game-related digital asset 405 that may be nonfungible and tracked on a distributed ledger, according to one aspect of the present disclosure. In some examples, token 400 is a nonfungible 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 a blockchain ledger 300. In some examples, token 400 is tracked within an Ethereum-based blockchain ledger 300.

[0047] The digital asset 405 represented by token 400 may be an instance of a video game. The digital asset 405 represented by token 400 may represent in-game digital assets such as in-game items, as well as in-game characters (sometimes called in-game actors), in-game costumes for in-game characters, in-game areas, save files related to the game, game configurations, DLC, IAP, or a combination of these. In-game digital assets may be referred to as in-game objects, as shown in Figures 2A and 2B. In-game characters may be referred to as in-game actors, as shown in Actor 254 in Figure 2B. In-game areas may be referred to as in-game zones, as shown in Zone 252 in Figure 2B. In some examples, in-game characters may be player characters controlled by the player, non-player characters (NPCs) that cannot be controlled by the player (but can be interacted with in some cases), or any combination of these. In some examples, in-game costumes may 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 may include ranged weapons, melee weapons, potions, food, consumables, armor, shields, ammunition, magical abilities, health recovery items, mana recovery items, vehicles, power-ups, extra lives, extra continues, items that modify the attributes of other items (for example, upgrading a bow and arrow to fire fire arrows), or combinations thereof.

[0048] Digital assets can be video game digital media assets, such as video clips, images, or audio clips, that contain media representations of one or more moments in a video game's gameplay. For example, an image may represent a single moment in a video game's gameplay. An image may include, for example, a screenshot. A video clip or audio clip can represent a series of consecutive moments in a video game's gameplay. For example, each moment in a series may be represented by individual video frames in a video clip, or by a specific set of sounds of one or more frequencies and amplitudes within an audio clip. Not all moments need to be consecutive, as a video clip or audio clip can be cut from one set of moments to another, like a highlight reel. In some examples, an image may represent multiple moments in a video game's gameplay, such as in a collage of images, or in a long-exposure style image that includes a representation of the path a character or item travels over one or more durations. Images, video clips, and / or audio clips can be captured from views, viewpoints, and / or bandage points that a particular player has during gameplay. Images, video clips, and / or audio clips can be captured from different views, viewpoints, and / or bandage points than those held by individual players.

[0049] In some embodiments, a digital asset may include a save file that saves the progress in the video game at a specific point in the video game's progression (e.g., within the story). Since the save file is available for use within the game, it may be identified as an in-game digital asset. Since the save file functions as a representation of the moment of gameplay at which the save file was saved, it can also be identified as a video game digital media asset.

[0050] In some examples, digital assets can include "ghosts" that can be imported into a game in a way that is visible to the game's player. Ghosts can retrace the gameplay paths of previous players. For example, in a racing game, a ghost might appear in the player's game, retracing a previously raced route, either by the same player or another player, at the same speed as the previous race. Ghosts may be identified as in-game digital assets because they are usable within the game. Ghosts may be identified as digital media assets for video games because they function as displays of multiple moments (durations) of a previous player's gameplay.

[0051] One or more token smart contracts 445 can be associated with token 400. For example, one or more token smart contracts 445 can manage the creation (or "minting") of token 400. One or more token smart contracts 445 can make payments to mining devices that create ("mint") token 400 or batches of tokens in order to calculate the time and resources required to mint token 400. One or more token smart contracts 445 can control how ownership of token 400 is determined and / or transferred. For example, one or more token smart contracts 445 can identify the initial owner of token 400 and / or identify offers under which ownership automatically transfers, e.g., when the owner meets or exceeds a modifiable threshold amount. One or more token smart contracts 445 can indicate conditions under which token 400 can be rented or licensed for use by licensee users / players, e.g., when an offer is made where the owner meets or exceeds a modifiable threshold amount. One or more token smart contracts 445 can control the conditions under which a token 400 can be burned, irreversibly destroyed, and / or removed from the list. Elements identified as part of token 400 in Figure 4, including token identifier 410, token unit amount 415, token ownership 420, on-chain immutable metadata 425, on-chain variable metadata 430, on-chain pointer to off-chain media 435, and on-chain pointer to off-chain metadata 440, can be stored as part of token 400, or can be part of token smart contract 445, or both. In some examples, the code of token smart contract 445 is stored at least partially on-chain.In some examples, the code for the token smart contract 445 is stored at least partially off-chain in an off-chain location(s), such as data structure 140, and these off-chain locations(s) are identified by on-chain pointers to them. The smart contracts in Figures 11A to 11B may be examples of token smart contract 445.

[0052] Token 400 includes a token identifier 410, which may be called a token ID. The token identifier 410 may be a unique identifier for token 400 and / or digital asset 405. The token identifier 410 can be used to distinguish a particular instance of digital asset 405 to which token 400 corresponds from any other instance of digital asset 405. In some examples, the token identifier may be generated by a computer system forming (or "minting") token 400 by sequentially incrementing it compared to the token identifier of a previously formed token, in order to ensure that each token identifier is unique.

[0053] Token 400 may contain a token unit amount 415. The token unit amount 415 can identify the amount of token 400 that has been minted or is set to be minted. In some examples, the token unit amount 415 is 1, in which case there is a single token 400 for a given digital asset 405. In some embodiments, the token unit amount 415 is greater than 1. For example, if the token unit amount 415 is 5, there are effectively five copies of this token 400 representing this unique digital asset 405 that can be owned and / or transferred separately. 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 from any other instance, version, or variation of the digital asset 405. The token unit amount 415 can control the scarcity of token 400, and by extension, the digital asset 405. When the token unit amount 415 is 1, token 400 and the corresponding digital asset 405 are unique. If the token unit amount 415 is 2 or greater but below the rarity threshold, the token 400 and the corresponding digital asset 405 are rare. If the token unit amount 415 is 2 or greater but above the rarity threshold, the token 400 and the corresponding digital asset 405 are common. In some examples, in addition to unique, rare, and common, or instead of them, 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 amount 415 may be determined as part of the minting process and / or identified by one of the token smart contracts 445 that manages the minting process.

[0054] Token 400 may 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 can control the rules for the transfer of token ownership 420. Token ownership 420 can be transferred as a transaction recorded as a payload element in the payload of a block on 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 can be guaranteed to remain unchanged using the properties of the distributed ledger and / or token smart contract 445. In some examples, on-chain immutable metadata 425 can identify which game data asset 405 is from, which game's representation (e.g., record), or which game it is otherwise related to. In some examples, on-chain immutable metadata 425 can identify the creator of digital asset 405 and / or token 400. In some examples, on-chain immutable metadata 425 can identify statistics for 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. On-chain variable metadata 430 may include, for example, a description of token 400, a description of the digital asset 405 that token 400 represents, some immutable attributes or characteristics of digital asset 405 and / or token 400, or some combination thereof. On-chain variable metadata 430 may be mutable or modifiable. In some examples, changes to on-chain variable metadata 430 may be recorded as transactions recorded as payload elements in the payload of a block on a blockchain ledger or other distributed ledger. In some examples, on-chain immutable metadata 425 may identify the number of times digital asset 405 has been used in a game and / or the number of different players who have used digital asset 405.

[0057] Token 400 may contain an on-chain pointer to off-chain media 435. Off-chain media may contain digital asset 405 and / or one or more representations of digital asset 405. For example, off-chain media may contain 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 therefore may 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. On-chain pointers may contain uniform resource identifiers (URIs), such as uniform resource locators (URLs), that point to one or more network locations among the one or more off-chain locations. In some examples, the hash of the off-chain media may be stored, and as a result, a verification device can calculate the hash of the off-chain media and compare the calculated hash with a stored hash stored on-chain to verify that the off-chain media is accurate. In some examples, the off-chain media may be immutable. In some cases, off-chain media may be mutable. In some cases, pointers may be immutable. In some cases, pointers may be mutable.

[0058] Token 400 may contain an on-chain pointer to off-chain metadata 440. Off-chain metadata 430 may include, for example, a description of token 400, a description of the digital asset 405 that token 400 represents, some immutable attributes or characteristics of digital asset 405 and / or token 400, or some combination thereof. Some digital assets 405 and / or token 400 may require a considerable amount of metadata, which may require a lot of storage space to store and therefore may 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 in one or more off-chain locations, such as data structure 140. On-chain pointers may contain uniform resource identifiers (URIs), such as uniform resource locators (URLs), that point to one or more network locations among the one or more off-chain locations. In some cases, the hash of the off-chain metadata can be stored, and as a result, the verification device can calculate the hash of the off-chain metadata and compare the calculated hash with the stored hash stored on-chain to verify that the off-chain metadata is accurate. In some cases, the off-chain metadata may be immutable. In some cases, the off-chain metadata may be mutable. In some cases, the pointer may be immutable. In some cases, the pointer may be mutable.

[0059] Figure 5 is a block diagram 500 illustrating the transfer of availability of asset 530 from the first user device 515 to the second user device 525. The first user device 515 is associated with the first user 510, while the second user device 525 is associated with the second user 520. Each of the first user device 515 and the second user device 525 may be an example of a user device 130, a console 228, an entertainment system 1300, or a combination thereof. The asset management system 505 can manage the transfer of availability of asset 530 from the first user device 515 to the second user device 525. The asset management system 505 may 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 communicably connected 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 control levels over the first user device 515 and the second user device 525, and has the ability to enable or disable digital entitlements (e.g., availability of a particular digital asset) on the first user device 515 and / or the second user device 525. The asset management system 505 can be used to manage the transfer of availability of asset 530.

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

[0062] In some examples, a 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 a second user 520 and / or a second user device 525 associated with the second user 520 as part of a matchmaking process, such as the matchmaking process shown in Figure 6. Before the availability of asset 530 is migrated, the second user device 525 does not have authentication to use asset 530. To migrate the availability of asset 530 from the first user device 515 to the second user device 525, the asset management system 505 can disable authentication to use asset 530 on the first user device 515 and enable authentication to use asset 530 on the second user device 525. After the migration, the second user device 525 has authentication to use asset 530, and the first user device 515 no longer has authentication to use asset 530.

[0063] The asset management system 505 can manage the migration of one or more other assets corresponding to the migration of the availability of asset 530 from the first user device 515 to the second user device 525. For example, the asset management system 505 can receive the migration of asset 545 from the second user device 525 and / or the second user 520. The asset management system 505 can migrate asset 540 to the first user device 515 and / or the first user 510. In some examples, asset 540 and / or 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 asset 530, an instance of a different video game than asset 530, in-game content of the same video game as asset 530, in-game content of a different video game than asset 530, or a combination thereof. In some examples, asset 540 includes at least a portion of asset 545. In some examples, asset 545 includes at least a portion of asset 540.

[0064] For example, in one exemplary case, the asset management system 505 can receive a request from the first user device 515 to transfer asset 530, can invalidate the authentication for using 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 authentication to use asset 530. The asset management system 505 can then 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 seeking 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 through the matchmaking process in Figure 6. A second user 520 and / or a second user device 525 may provide the asset management system 505 with an asset 545 (e.g., a second predetermined amount of funds), and in return, the asset management system 505 may enable authentication to use the asset 530 on the second user device 525. In some examples, asset 545 may contain a larger amount of funds than asset 540. In some examples, a portion of asset 545 (e.g., a portion of the funds of asset 545) may 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 may receive a request from the first user device 515 to migrate asset 530, and the asset management system 505 may initiate a matchmaking process to identify the second user 520 and / or the second user device 525, such as the matchmaking process shown in Figure 6. Through the matchmaking process, the asset management system 505 may provide the first user 510 and / or the first user device 515 with information about the second user 520 and / or the second user device 525. Through the matchmaking process, the asset management system 505 may provide the second user 520 and / or the second user device 525 with information about the first user 510 and / or the first user device 515. 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 recipients of authentication using asset 530, and the asset management system 505 can then automatically perform the transfer of authentication using 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 sellers who choose to purchase authentication using asset 530, and the asset management system 505 can then automatically perform the transfer of authentication using 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 asset management system 505 can automatically perform the transfer of authentication using asset 530 from the first user device 515 to the second user device 525 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, and 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 asset 545, the asset management system 505 transfers at least a portion of asset 545 to the first user 510 and / or the first user device 515 as asset 540, and in some examples, another portion of asset 545 is transferred to another entity 550. In some examples, the management platform 505 does not store asset 545 but immediately delivers at least a portion of asset 545 as asset 540 to the first user 510 and / or the first user device 515, and in some examples, another portion of asset 545 is migrated to another entity 550. In some examples, asset 540 is asset 545. In some cases, asset 540 is less than asset 545 (e.g., including less funds than asset 545). In some cases, asset 540 is more than asset 545 (e.g., including more funds than asset 545, or additional other assets), and the additional assets are provided by the asset management system 505 and / or other entity 550, for example, prompting the use of the asset management system 505 for such migration.

[0066] In some examples, the first user 510 and / or the first user device 515 may also provide additional assets along with the asset 530. For example, the first user 510 and / or the first user device 515 may provide a certain amount of funds to the asset management system 505. In some examples, the additional assets may be provided from the asset management system 505 to other entities 550.

[0067] In some examples, the asset management system 505 includes a distributed ledger, such as a blockchain ledger 300. In some examples, transactions recording the migration of assets 530, 540, and / or 545 can be stored in the distributed ledger by the asset management system 505. In some examples, smart contracts corresponding to the migration of assets 530, 540, and / or 545 can be stored in the distributed ledger by the asset management system 505 and executed to perform the migration of assets 530, 540, and / or 545 when certain conditions are met, such as the migration of asset 530 being automatically performed after verification that the migration(s) of asset 540 and / or 545 have been completed. In some examples, tokens corresponding to assets 530, 540, and / or 545 can be stored in the distributed ledger by the asset management system 505 and / or migrated by the asset management system 505 using the distributed ledger.

[0068] In some examples, the asset management system 505 may, as a result of the migration, change the content stored and / or potentially 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 may delete asset 530 from the first user device 515 or cause the first user device 515 to delete asset 530. As part of enabling authentication to use asset 530 on the second user device 525, the asset management system 505 may send asset 530 to the second user device 525, for example, from a software repository, or cause the second user device 525 to download asset 530. In some examples, authentication to use asset 530 also includes authentication to download asset 530 from the asset management system 505's software repository.

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

[0070] Figure 6 is a conceptual diagram illustrating an example of an interface 600 for user-to-user matchmaking to transfer the availability of asset 630. In the illustrative diagram of Figure 6, asset 630 is in-game content, specifically downloadable content (DLC), for a video game titled "Pirate's Flag III". Asset 630 is being sold by user 640, whose username is BugHero62.

[0071] In the matchmaking process shown in Figure 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 shares at least one characteristic in common with user 640. For example, user 605, whose username is Burger85, shares the characteristic of interest of user 640 in a game titled "Bounty Hunter IV". Specifically, the asset management system 505 identifies "Bounty Hunter IV" as the most played game for user 605 and also appears in user 640's wishlist. A "Propose Trade" button 650 appears next to the entry for user 605, allowing 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 the Friend Circle characteristic 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 characteristic 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 the Game Ownership characteristic because both user 620 and user 640 own the game "Pirate's Flag III," and asset 630 is particularly relevant as it is in-game content (DLC) related to the game "Pirate's Flag III." The interface 600 shown in Figure 6 displays a selection pointer that highlights 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] Figure 7 is a conceptual diagram showing an embodiment of an interface 700 for purchasing authentication to use a digital asset 630 related to a video game. Interface 700 is an exemplary interface for potential purchasers of asset 630, such as a second user 520, a second user device 525, user 605, user 610, user 615, and / or user 620. Interface 700 includes asset information 705 that identifies asset 630 as in-game content, specifically downloadable content (DLC) titled "Premium Ships" for a video game titled "Pirate's Flag III". Asset information 705 also identifies that a seller (e.g., user 640) requested a price of $9.99 for asset 630, that the original "new" price of asset 630 was $14.99, and that the average "used" price of asset 630 was $10.99. Interface 700 includes buttons that allow a purchasing user to purchase asset 630 for $9.99, bid on a different amount (such as $5.99 entered in the bid field), propose a trade for asset 630 (e.g., in exchange for a different game or in-game content element), or add asset 630 to the purchasing user's wishlist. If a purchasing user purchases asset 630 for $9.99, $9.99 could be an example of asset 545, and the transition can proceed immediately. In some examples, the asset management system 505 can manage bids for asset 630, for example, by automatically selecting the highest bidder at the end of the bidding period. The winning bid could then be an example of asset 545.

[0074] Interface 700 also includes seller information 710 that identifies information about user 640 who is selling asset 630. For example, seller information 710 identifies that user 640's username is BugHero62, that user 640's average feedback (e.g., from other buyers who purchased from user 640 using the asset management system 505) is 97.9% positive, that user 640 is located in North America, that user 640's most played games include "Call of Speed: Police Chase" and "Pirate's Flag III", and that user 610 Jessica72 is a common friend of user 640 and the buyer. Interface 700 includes a button to contact the seller, which allows the asset management system 505 to open a communication channel between user 640 and the buyer. Interface 700 includes a button to view other assets sold by user 640, which may allow the asset management system 505 to identify to the purchasing user other assets sold by user 640 besides asset 630.

[0075] Figure 8 is a conceptual diagram showing an embodiment of an interface 800 for evaluating the value of a digital asset 630 related to a video game. The interface 800 in Figure 8 may also be an interface for a seller user, such as user 640. Interface 800 identifies some of the same asset information 705 as interface 700 in Figure 7, such as the original "new" price of asset 630 being $14.99 and the average "used" price of asset 630 being $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, below average, or above average. Interface 800 includes a "requested price" field 805 at which user 640 can enter the price at which they wish to sell asset 630. In some examples, the requested price may be a "buy now" price at which a buyer user can immediately purchase asset 630 without going through a bidding process. In some examples, the requested price may be the minimum bid a buyer can make for asset 630, and the asset management system 505 still manages the bidding process even after the bid has been made. Interface 800 includes a price of $9.99 in the "Requested Price" field 805 and includes an alert indicating that this $9.99 price is lower than the average "used" price of asset 630, which is $10.99.

[0076] Interface 800 also includes Graph 840 of the “new” price of asset 630 over time, for example, from an official software repository or marketplace. Graph 840 shows how the “new” price of asset 630 has fluctuated over time, for example, based on various sales, price drops, price increases, etc. Interface 800 also includes Graph 845 of the average “used” price of asset 630 over time, based on various migrations, for example, the migration in Figure 5 managed by the asset management system 505. Graph 845 shows how the average “used” price of asset 630 has fluctuated over time, which is somewhat similar to, but may be somewhat independent of, the “new” price of asset 630 over time in Graph 840. Both Graph 840 and Graph 845 include a dashed horizontal line representing the price of $9.99 requested by user 640.

[0077] Figure 9 is a conceptual diagram showing an embodiment of an interface 900 that onboards the user onto a platform and assists the user in converting video game assets 905 associated with other platforms into corresponding video game assets 910 associated with the platform. As previously mentioned, in some examples, the asset management system 505 can manage assets, migrations, and / or user devices across 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 gamebox platform or ecosystem. Video game assets 905 include instances of the video game "Call of Speed: Police Chase" for the PC platform, instances of the video game "Bounty Hunter IV" for the gamebox platform, and instances of the video game "Pirate's Flag III" for the gamebox platform. In the example in Figure 9, the asset management system 505 associated with the Sony® PlayStation® platform or ecosystem identifies corresponding instances of the same video game available on the Sony® PlayStation® platform or ecosystem as video game assets 910. For example, in interface 900, the asset management system 505 identifies instances of the video game "Call of Speed: Police Chase" for the Sony® PlayStation® 5 platform, instances of the video game "Bounty Hunter IV" for the Sony® PlayStation® 5 platform, and instances of the video game "Pirate's Flag III" for the Sony® PlayStation® 5 platform.

[0078] The interface includes a query 930 that asks the user whether they wish 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® PlayStation® platform in which the user participates. The query 930 includes a "Yes" button that causes the asset management system 505 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, as discussed with respect to Figure 5. For example, video game asset 905 could be an example of asset 530, user 920 could be an example of a second user 520, and user device 925 could be an example of a second user device 525. Funds from user 920 and / or user device 925 could be an example of assets 540 and / or asset 545, which can be automatically applied by the asset management system 505 to purchase video game assets 910. In some examples, the asset management system 505 can purchase video game asset 910 as a new video game asset from an official software repository or marketplace. In some examples, the asset management system 505 can purchase video game asset 910 as a used video game asset from a seller user and / or seller user device. In such examples, video game asset 910 may be example asset 530, seller user may be example second user 520, and seller user device may be example second user device 525. Query 930 includes a "No" button that does not perform the proposed migration of video game asset 905 regarding video game asset 910.

[0079] Figure 10 is a block diagram 1000 showing an authentication process that manages user authentication for the transfer of asset availability. 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 the asset management system 505 to transfer authentication for using asset 1030. In some examples, request 1035 is a request to transfer authentication for using asset 1030 from the first user device 1015. In such examples, the first user 1010 and the first user device 1015 are examples of the first user 510 and the first user device 515, respectively. In some examples, request 1035 is a request to transfer authentication for using 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 the second user 520 and the second user device 525, respectively.

[0080] The second user 1020 may be the parent, guardian, supervisor, collaborator, friend, and / or family member of the first user 1010. The asset management system 505 identifies settings and / or rules associated with the first user 1010, the first user device 1015, the second user 1020, the second user device 1025, and / or asset 1030. The settings and / or rules may identify conditions under which the second user 1020 and / or the second user device 1025 must provide authentication before the requested migration can be performed by the asset management system 505. If 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 may be, for example, 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, mobile handset, and / or wireless communication device. The second user device 1025 can display an alert 1040. The alert 1040 can identify the request 1035, the asset 1030, details of the requested transfer of asset 1030, further information about asset 1030 (e.g., game type or in-game content), or a combination thereof. For example, the alert 1040 may show the age rating of asset 1030, such as the Entertainment Software Rating Board (ESRB) rating of asset 1030. In some examples, the alert 1040 may show user ratings and / or reviews of asset 1030.

[0081] If asset 1030 is an asset authorized for use by the first user device 1015, and request 1035 attempts to transfer that authorization from the first user device 1015, alert 1040 may identify the usage history of asset 1030 on the first user device 1015 to ensure, for example, that the first user 1010 is not attempting to sell a favorite game or piece of in-game content. Alert 1040 may 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 may identify either the interface 700 and / or the asset information 705 and / or seller information 710 within the interface 800.

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

[0083] Figure 11A is a conceptual diagram 1100 illustrating the generation of a smart contract and its entry 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) which may be an entertainment system 1300 that stores and modifies the distributed ledger. A first computer submits a request 1105 requesting the entry of a smart contract having a specific rule into the distributed ledger. A second computer submits a response 1110 indicating that the second computer has generated a new block that will enter into 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 will execute the smart contract correctly, that the smart contract code is executable (e.g., free from syntax errors or other errors), that all parties involved in the smart contract have submitted their agreement to the terms of the smart contract, that the on-chain pointers correctly point to valid off-chain smart contract code, and / or that sufficient funds have been allocated to claim the execution fees for the intended payload elements. The second computer, in response to verifications from a certain number of devices, submits an entry confirmation indicating that the new block, along with the requested smart contract, has successfully entered the distributed ledger.

[0084] A process similar to the one shown in Figure 11A may be used to enter into a token, for example, along with corresponding verifications 1120A-1120C that 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 the execution fee for the intended payload element. A process similar to the one shown in Figure 11A may be used to enter into a transaction, for example, along with corresponding verifications 1120A-1120C that verify that the transferor has a sufficient amount of assets for the transaction to take place (e.g., whether the transferor owns the tokens to be transferred), and / or that sufficient funds are allocated to charge the execution fee for the intended payload element.

[0085] Figure 11B is a conceptual diagram 1150 illustrating the execution of a smart contract according to one aspect of the present disclosure. The first computer executes the smart contract code, identifies that the conditions in the smart contract have been met, and submits proof 1155 that it has identified that an action has been taken. The second, third, and fourth computers execute the smart contract code, verify that the conditions in the smart contract have been met, and submit verifications 1110A to 1110C that it has verified that an action has been taken. The fifth computer displays error 1115 without verification. The third computer displays action 1120, which indicates that the third computer executes the smart contract code and has performed an action in response to verification by a certain number of devices (e.g., verifications 1110A to 1110C).

[0086] Figure 12 is a flowchart 1200 illustrating the operation for authentication reconfiguration regarding the availability of digital assets according to one aspect of this disclosure. At least a subset of operations 1200 can be performed by an authentication management system, which may include, for example, a network environment 100, one or more interactive content servers 110, one or more platform servers 120, one or more user devices 130, one or more data structures 140, one or more distributed ledgers 150, a network environment 200, a console 228, one or more servers 218, a blockchain ledger 300, an asset management system 505, a first user device 515, a second user device 525, a user device of any of users 605-620, a user device of user 640, a user device 925, a first user device 1015, a second user device 1025, the computing devices shown in Figures 11A-11B, an entertainment system 1300, a non-temporary computer-readable storage medium into which a program executed by the system, device, processor is integrated, or a combination thereof.

[0087] In operation 1205, the authentication management system is configured and capable of identifying assets related to the video game. The first user device is authenticated to use the assets. The first user device is associated with the 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 in payload 330, assets identified in payload 360, assets identified in payload 390, token 400, asset 530, asset 630, video game asset 905, video game asset 910, asset 1030, assets whose transfer is controlled using smart contracts (multiple) as shown in Figures 11A-11B, or combinations thereof. Examples of first users 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 first user devices 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, computing devices shown in Figures 11A-11B, entertainment system 1300, or combinations thereof.

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

[0089] In some examples, assets include in-game content related to a video game. This in-game content is available for use within the video game by the video game player during gameplay. The player may be, for example, the first user of operation 1205 before the transition to operations 1215-1220. The player may be, for example, the second user of operation 1210 after the transition to operations 1215-1220.

[0090] In operation 1210, the authentication management system is configured and capable of identifying a second user. The second user device associated with the second user lacks authentication to use the asset. An example of a second user includes any of the exemplary users listed above as examples of the first user in operation 1205. An example of a second user device includes any of the exemplary users 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 matchmaking process shown in Figure 6.

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

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

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

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

[0095] In some examples, notification of asset availability transfer includes receiving notification of a second transfer of a second asset from a second user's account. The second transfer is in exchange for the transfer of asset availability. Examples of second transfers include the transfer of asset 545 and / or the transfer of asset 540, as shown in Figure 5. In some examples, the second asset is the amount of funds that make a payment for the asset availability transfer. In some examples, the authentication management system is configured and can receive bids for the amount of funds from a second user device and is configured and can receive acceptance of bids from a first user device, as shown in the bidding process in interface 700 in Figure 7 and / or interface 800 in Figure 8. In some examples, the authentication management system is configured and can identify a valuation value associated with the asset availability transfer, and the amount of funds is based on this valuation value, as shown in the valuation process in Figure 8 and interface 800.

[0096] In some examples, the authentication management system is configured 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. The authentication management system can automatically enable authentication for the third user device to use the second asset in response to receiving a notification. This example is shown in interface 900 in Figure 9. For example, the Sony® PlayStation® 5 console in interface 900 could be an example of a third user device, and the PC or game box in interface 900 could be an example of a first user device. Similarly, the Sony® PlayStation® platform in interface 900 could be an example of a second platform, and the PC or game box platform in interface 900 could be an example of a first platform. In some examples, the second asset is a variation of an asset available on the second platform, while the asset is available on the first platform. For example, video game asset 910 is a variation of video game asset 905, which is available for use on the Sony® PlayStation® platform, and video game asset 905 is available for use on other platforms.

[0097] In some examples, the authentication management system is configured and can identify that the asset type matches a specific type in the rules. In response to identifying that the asset type matches a specific type in the rules, the authentication management system can automatically request authentication for a migration from a third user device associated with a third user. The authentication management system can receive authentication for a migration from a third user device associated with a third user, and the notification will include authentication for the migration. An example of authentication is 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, the authentication management system is configured and can be configured to automatically disable authentication for the first user device to use the asset in response to receiving a notification.

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

[0100] In some examples, an authentication management system is configured and can identify a distributed ledger containing multiple blocks. Each block in at least a subset of the multiple blocks contains hashes of at least some of the other blocks in the multiple. The authentication management system can cause additional blocks to be added to the distributed ledger. The payload of the additional blocks contains a record of the asset availability transfer. The additional blocks contain hashes of at least some of the multiple blocks in the distributed ledger. In some examples, an authentication management system is configured and can generate additional blocks. 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, assets include non-fungible tokens (NFTs) related to video games, such as token 400. In some examples, one or more blocks in the multiple blocks in the distributed ledger identify a smart contract that identifies a condition. The detection of the condition is configured to trigger the asset availability transfer according to the smart contract. The notification may include validation of the detection of conditions, such as the smart contract validation shown in Figures 11A-11B.

[0101] Figure 13 shows an exemplary user electronic entertainment system that may be used to initiate interactive content and provide a dynamic interface, according to one aspect of the present disclosure. The entertainment system 1300 in Figure 13 includes 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 disc control unit 1370, and a hard disk drive 1365, all connected to the I / O processor 1325 via a bus 1375.

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

[0103] In Figure 13, the CPU 1310, vector unit 1315, graphics processing unit 1320, and I / O processor 1325 communicate via the system bus 1385. Furthermore, the CPU 1310 in Figure 13 communicates with the main memory 1305 via the dedicated bus 1380. On the other hand, the vector unit 1315 and graphics processing unit 1320 may communicate via the dedicated bus 1390. The CPU 1310 in Figure 13 executes programs stored in the OS ROM 1355 and the main memory 1305. The main memory 1305 in Figure 13 may contain pre-stored programs and programs migrated via the I / O processor 1325 from a CD-ROM, DVD-ROM, or other optical disc (not shown) using the optical disc control unit 1370. The I / O processor 1325 in Figure 13 may also enable the introduction of content migrated via a wireless network or other communication network (e.g., 4G, LTE, 1G, etc.). The I / O processor 1325 in Figure 13 primarily 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 Figure 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 Figure 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. Furthermore, 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 several other components such as a processor.

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

[0106] This disclosure relates to an application that may be operable on a variety of end-user devices. For example, an end-user device may be a personal computer, a home entertainment system (e.g., Sony PlayStation 2®, Sony PlayStation 3®, Sony PlayStation 4®, or Sony PlayStation 5®), a portable game device (e.g., Sony PSP® or Sony Vita®), or a lower-end but different manufacturer's home entertainment system. The methods described herein are fully intended to be operable on a variety of devices. The aspects of this disclosure may also be implemented with title neutrality and / or used across a variety of titles from various publishers.

[0107] Aspects of this disclosure may be implemented in applications that may be operable using various devices. Non-temporary computer-readable storage media means any or more 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-temporary computer-readable media include, for example, floppy disks, flexible disks, hard disks, magnetic tapes, any other magnetic media, CD-ROM disks, digital video disks (DVDs), any other optical media, RAM, PROM, EPROM, FLASHEPROM, and any other memory chips or cartridges.

[0108] Various forms of transmission media may be involved in conveying one or more sequences of one or more instructions to the CPU for execution. A bus transmits data to system RAM, from which the CPU retrieves and executes the instructions. Instructions received by system RAM can optionally be stored in 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 also be implemented.

[0109] In some aspects of this disclosure, computer-readable storage devices, media, and memory may include cables or wireless signals, such as bitstreams. However, non-temporary computer-readable storage media, as referred to, expressly exclude media such as energy, carrier signals, electromagnetic waves, and signals themselves.

[0110] The above detailed description of the Technology is provided for illustrative and explanatory purposes only. The above detailed description is not intended to be comprehensive or to limit the Technology to the exact form disclosed. Many modifications and variations are possible in light of the above teachings. The aspects described in this disclosure have been selected to adequately illustrate the principles of the Technology, its practical applications, and to enable other persons skilled in the art to utilize the Technology with various modifications suitable for specific intended uses. The scope of the Technology is intended to be defined by the claims.

Claims

1. A system for reconfiguring authentication regarding the usability of digital assets, Memory for storing instructions, One or more processors, wherein the execution of the instructions by the one or more processors results in the one or more processors, To generate a smart contract that is executable to automatically transfer the availability of digital assets within a video game stream when a trigger condition is met, wherein the smart contract is identified in the payload of the most recent block of a distributed ledger, Verify that the most recent block of the distributed ledger indicates that the first user device was authorized to use the digital asset within the stream of the video game during the first period, and that the second user device lacked authorization to use the digital asset within the stream of the video game during the first period. Receiving gameplay activity data including notification that the trigger condition of the smart contract has been met, Based on a comparison between the characteristics associated with the first user of the first user device and the characteristics associated with each of the multiple users, it is identified that a second user among the multiple users shares the characteristics of the first user. Selecting the second user device of the second user as the destination for the transfer of the availability of the digital asset, Generating a new block to be added to the distributed ledger, wherein the payload of the new block reflects the migration of a token representing the digital asset from a first account associated with the first user device to a second account associated with the second user device. The system comprising one or more processors that perform the following.

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

3. The system according to claim 1, wherein the digital asset includes in-game content related to the video game, and the in-game content is available for use within the video game by the player of the video game during the player's gameplay of the video game.

4. The system according to claim 1, wherein the notification that the trigger condition has been met includes confirmation of the transition from the first user device.

5. The system according to claim 1, wherein the notification that the trigger condition has been met indicates a second transfer of the second asset from the second account, and the second transfer is in exchange for the transfer of the availability of the digital asset.

6. The system according to claim 5, wherein the second asset is the amount of funds.

7. The execution of the instruction by the one or more processors results in the one or more processors, Receiving a bid for the second asset from the second user device, Receiving acceptance of the bid from the first user device, The system according to claim 5, which enables the implementation of the following:

8. The execution of the instruction by the one or more processors results in the one or more processors, Receiving a bid for the amount of funds from the second user device, The system according to claim 6, which identifies an evaluation value associated with the transfer of the usability of the digital assets based on the bid, wherein the amount of funding is based on the evaluation value, and which performs the identification.

9. The execution of the instruction by the one or more processors results in the one or more processors, Identifying a second digital asset related to the video game, wherein the second digital asset is associated with a third user device associated with a designated family account associated with the first account. The third user device automatically enables authentication for using the second digital asset in the stream of the video game, The system according to claim 1, which enables the implementation of the following:

10. The system according to claim 9, wherein the second digital asset is a variation of the digital asset.

11. The execution of the instruction by the one or more processors results in the one or more processors, Identifying that the type of the digital asset matches a specific type in the rule, In response to the identification that the type of the asset matches the specific type in the rule, the system automatically requests authentication for the migration from a third user device associated with a designated family account associated with the first account, Receiving the authentication regarding the migration from the third user device, The system according to claim 1, which enables the implementation of the following:

12. The system according to claim 1, wherein the distributed ledger comprises a plurality of blocks, each block of at least a subset of the plurality of blocks comprises a hash of at least a portion of another block of the plurality of blocks, and the new block comprises a hash of at least a portion of the plurality of blocks of the distributed ledger.

13. The system according to claim 1, wherein the execution of the instruction by the one or more processors causes the one or more processors to generate at least a portion of the new block.

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

15. The system according to claim 1, wherein the token relates to a non-fungible token (NFT).

16. The system according to claim 1, wherein the distributed ledger includes at least one reference to off-chain data outside the distributed ledger.

17. A method for reconfiguring authentication regarding the usability of digital assets, The server generates a smart contract that can be executed to automatically transfer the availability of digital assets within a video game stream when a trigger condition is met, wherein the smart contract is identified in the payload of the most recent block of the distributed ledger. The server verifies that the most recent block of the distributed ledger indicates that the first user device was authenticated to use the digital asset within the stream of the video game during a first period, and that the second user device lacked authentication to use the digital asset within the stream of the video game during the first period. The server receives gameplay activity data including a notification that the trigger condition of the smart contract has been met, The server identifies, based on a comparison between the characteristics associated with the first user of the first user device and the characteristics associated with each of the multiple users, that a second user among the multiple users shares the characteristics of the first user. The server selects the second user device of the second user as the destination for the transfer of the availability of the digital asset, The method, wherein the server generates a new block to be added to the distributed ledger, the payload of which the new block reflects the migration of token information representing the digital asset from a first account associated with a first user device to a second account associated with a second user device.

18. A non-temporary computer-readable storage medium having a program embedded thereon, wherein the program is executable by a processor to perform a method of authentication reconfiguration relating to the usability of a digital asset, To generate a smart contract that is executable to automatically transfer the availability of digital assets within a video game stream when a trigger condition is met, wherein the smart contract is identified in the payload of the most recent block of a distributed ledger, Verify that the most recent block of the distributed ledger indicates that the first user device was authorized to use the digital asset within the stream of the video game during the first period, and that the second user device lacked authorization to use the digital asset within the stream of the video game during the first period. Receiving gameplay activity data including notification that the trigger condition of the smart contract has been met, Based on a comparison between the characteristics associated with the first user of the first user device and the characteristics associated with each of the multiple users, it is identified that a second user among the multiple users shares the characteristics of the first user. Selecting the second user device of the second user as the destination for the transfer of the availability of the digital asset, The non-temporary computer-readable storage medium, which includes generating a new block for addition to the distributed ledger, wherein the payload of the new block reflects the migration of token information representing the digital asset from a first account associated with the first user device to a second account associated with the second user device.

Images