CRYPTOGRAPHIC TOKEN RIGHTS MANAGEMENT SYSTEM AND METHOD USING TRUSTED LEDGERS

Abstract

The present disclosure relates, among other things, to systems and methods for dynamically and securely managing digital assets, products, and / or associated tokens. Various embodiments disclosed herein may use a trusted ledger to securely record certain assertions about digital assets, products, rights holders, and / or various ecosystem participants. Such assertions may be used in connection with rights binding, content packaging, management, and / or protection operations in connection with various transactions associated with the digital assets, products, and / or associated tokens.

Description

[Technical field]

[0001] (Related Applications) CROSS-REFERENCE TO RELATED APPLICATIONS This application claims the benefit under 35 U.S.C. §119(e) of U.S. Provisional Patent Application No. 63 / 261,821, entitled "CRYPTOGRAPHIC TOKEN MANAGEMENT SYSTEMS AND METHODS," filed on September 29, 2021, U.S. Provisional Patent Application No. 63 / 291,929, entitled "SYSTEMS AND METHODS FOR CRYPTOGRAPHIC TOKEN MANAGEMENT USING TRUSTED LEDGERS," filed on December 20, 2021, and U.S. Provisional Patent Application No. 63 / 315,874, entitled "CRYPTOGRAPHIC TOKEN RIGHTS MANAGEMENT SYSTEMS AND METHODS USING TRUSTED LEDGERS," filed on March 2, 2022, the contents of which are incorporated by reference in their entireties herein.

[0002] (Copyright Granted) Portions of the disclosure of this patent document may contain material that is subject to copyright protection. The copyright owner has no objection to the facsimile reproduction of either the patent document or the patent disclosure, as appearing in the U.S. Patent and Trademark Office patent file or records, but otherwise reserves all copyright rights whatsoever. Summary of the Invention

[0003] The present disclosure relates generally to systems and methods for managing cryptographic tokens, and more specifically, to systems and methods for managing rights to non-fungible tokens ("NFTs") and associated content in an NFT marketplace using a trusted ledger.

[0004] An NFT is a type of cryptographic token on a trusted distributed ledger, such as a blockchain ledger, that can represent assets, which can include digital and / or physical assets. NFTs can be used in a variety of contexts, with uses ranging from simple digital asset transactions to complex secured loans.

[0005] The NFT paradigm may be implemented using a variety of architectures. For example, a centralized server may be used to store metadata associated with a digital asset. The server may create a reference to that data and store the reference link in a trusted ledger such as a cryptographic blockchain. This approach may be relatively fast and inexpensive to implement, in terms of cost and processing power, and may allow for flexible updates of referenced metadata that is not directly stored in the trusted ledger. However, if the server goes down, there may not be enough data in the trusted ledger to allow for retrieval of the original asset, potentially rendering the NFT essentially invalid. Additionally, if the owner deletes or changes the location of the data and the asset is not stored on the central server, the link to the asset may not work as intended.

[0006] Another approach to implementing the NFT paradigm may include storing metadata on the trusted ledger itself. This may allow relevant data to be stored on the ledger with fewer third-party dependencies and greater reliability in the event that the NFT marketplace goes down. However, this type of implementation comes with additional costs in terms of expense, speed, and / or processing acceptance.

[0007] Embodiments of the systems and methods may provide an improved architecture for managing digital assets. In certain embodiments, metadata associated with digital assets may be stored in a server database, and correlations with the metadata associated with the digital assets may be securely stored in a trusted ledger, which may include a blockchain ledger.

[0008] Many conventional NFT marketplaces may not be well suited to address copyright issues. For example, if a marketplace customer purchases an NFT for a song, the customer may be able to download the song and easily upload it to other platforms, potentially violating the rights of others to the song. Embodiments of the disclosed systems and methods may help ameliorate at least some of these issues using digital rights management ("DRM") technology in conjunction with an NFT management paradigm. For example, using various aspects of the disclosed systems and methods, a customer may be able to listen to a purchased song, but because the purchased song may be protected with DRM techniques, downloading the song and uploading it to other platforms may be impossible, as this would be a violation of the rights to the song.

[0009] In various disclosed embodiments, a trusted database, ledger, and / or the like (which may be generally referred to herein as a "trusted ledger" and / or variations thereof) may be used to record and / or otherwise manage various assertions associated with digital assets and / or NFTs. In some embodiments, such a database and / or ledger may be distributed and may be referred to herein as a trusted immutable distributed assertion ledger ("TIDAL") and / or variations thereof.

[0010] In some embodiments, a trusted ledger used in connection with various aspects of the disclosed embodiments may comprise a blockchain ledger. The ledger may be public, private, and / or a combination thereof in various embodiments. In certain embodiments, TIDAL may include a public indelible distributed database ("PIDD"). TIDAL consistent with various aspects of the disclosed embodiments may be associated with various properties including, for example, a ledger process that may be resistant to Byzantine failures, entries that may be immutable and / or relatively immutable, entries that may be (at least partially) time synchronized, entries that may be scalable, and / or entries that may be available for relatively fast lookup.

[0011] Embodiments of the disclosed systems and methods may enable rights binding, packaging, management, and / or protection operations in connection with various NFT transactions (e.g., mining NFTs, transferring NFTs, etc.) DRM functionality and / or key management may be provided to facilitate management of digital assets, products, and / or NFTs based on authenticated access rights.

[0012] In some embodiments, digital assets (e.g., digital content) may be packaged into products, serialized, and / or managed according to one or more enforced business terms. The business terms may include permitted actions that may be performed in connection with the digital asset and / or associated product, and may be set by an entity that holds certain rights to the digital asset and / or associated product. For example, and without limitation, the business terms may be used to manage the digital asset and / or associated NFTs based on a sales model, a rental model, a subscription model, a rental of ownership model, etc.

[0013] Embodiments of the disclosed systems and methods may provide elements of an ecosystem for registering and uploading digital assets, downloading digital assets and / or products, creating and / or packaging digital assets and / or products, listing digital assets and / or products, delisting digital assets and / or products, updating digital assets and / or products, sharing digital assets and / or products, reproducing digital assets and / or products, and the like. Further embodiments may facilitate compensation of a rights holder and / or multiple rights holders associated with a digital asset, product, and / or associated NFT based on consumer use and / or interaction with the associated digital asset, product, and / or NFT. Certain embodiments may provide mechanisms for easily implementing aspects of the disclosed systems and methods with such established blockchain architectures, for example, using one or more commercial blockchain ledgers, such as the FLOW blockchain, and blockchain connector services. [Brief description of the drawings]

[0014] The work body of the present invention will be readily understood by reference to the following detailed description taken in conjunction with the accompanying drawings. [Figure 1A] 1 illustrates a first portion of a non-limiting example of a process for registering an NFT asset in a trusted service consistent with certain embodiments disclosed herein. [Figure 1B] Illustrates a second portion of a non-limiting example of a process for registering an NFT asset in a trusted service consistent with certain embodiments disclosed herein. [Figure 2A] 1 illustrates a first portion of a non-limiting example of a process for purchasing and accessing NFT assets using a trusted service consistent with certain embodiments disclosed herein. [Figure 2B] Illustrates a second portion of a non-limiting example of a process for purchasing and accessing NFT assets using a trusted service consistent with certain embodiments disclosed herein. [Figure 2C] Illustrates a third portion of a non-limiting example of a process for purchasing and accessing NFT assets using a trusted service consistent with certain embodiments disclosed herein. [Diagram 3] Illustrates a non-limiting example of an aspect of an NFT transaction process consistent with certain embodiments disclosed herein. [Figure 4A] 1 illustrates a first portion of a non-limiting example of an asset upload process consistent with certain embodiments disclosed herein. [Figure 4B] 13 illustrates a second portion of a non-limiting example of an asset upload process consistent with certain embodiments disclosed herein. [Figure 5A] 1 illustrates a first portion of a non-limiting example of a product creation process consistent with certain embodiments disclosed herein. [Figure 5B] 1 illustrates a second portion of a non-limiting example of a product creation process consistent with certain embodiments disclosed herein. [Figure 5C] 1 illustrates a third portion of a non-limiting example of a product creation process consistent with certain embodiments disclosed herein. [Figure 6A] 1 illustrates a first portion of a non-limiting example of a download process consistent with certain embodiments disclosed herein. [Figure 6B] 13 illustrates a second portion of a non-limiting example of a download process consistent with certain embodiments disclosed herein. [Figure 6C] 13 illustrates a third portion of a non-limiting example of a download process consistent with certain embodiments disclosed herein. [Figure 6D] 13 illustrates a fourth portion of a non-limiting example of a download process consistent with certain embodiments disclosed herein. [Figure 7A] 1 illustrates a first portion of a non-limiting example of an asset reclamation process consistent with certain embodiments disclosed herein. [Figure 7B] 1 illustrates a second portion of a non-limiting example of an asset reclamation process consistent with certain embodiments disclosed herein. [Figure 7C] 1 illustrates a third portion of a non-limiting example of an asset reclamation process consistent with certain embodiments disclosed herein. [Figure 8A] 1 illustrates a first portion of a non-limiting example of an asset update process consistent with certain embodiments disclosed herein. [Figure 8B] 13 illustrates a second portion of a non-limiting example of an asset update process consistent with certain embodiments disclosed herein. [Figure 8C] 13 illustrates a third portion of a non-limiting example of an asset update process consistent with certain embodiments disclosed herein. [Figure 9A] 1 illustrates a first portion of a non-limiting example of a product update process consistent with certain embodiments disclosed herein. [Figure 9B] 1 illustrates a second portion of a non-limiting example of a product update process consistent with certain embodiments disclosed herein. [Figure 9C] 13 illustrates a third portion of a non-limiting example of a product update process consistent with certain embodiments disclosed herein. [Figure 10A] 1 illustrates a first portion of a non-limiting example of a product de-listing process consistent with certain embodiments disclosed herein. [Figure 10B] 1 illustrates a second portion of a non-limiting example of a product de-listing process consistent with certain embodiments disclosed herein. [Figure 11A] 1 illustrates a first portion of a non-limiting example of an asset deletion process consistent with certain embodiments disclosed herein. [Figure 11B] 13 illustrates a second portion of a non-limiting example of an asset deletion process consistent with certain embodiments disclosed herein. [Figure 12A]1 illustrates a first portion of a non-limiting example of an asset unbundling process consistent with certain embodiments disclosed herein. [Figure 12B] 1 illustrates a second portion of a non-limiting example of an asset unbundling process consistent with certain embodiments disclosed herein. [Figure 13A] 1 illustrates a first portion of a non-limiting example of a product solicitation process consistent with certain embodiments disclosed herein. [Figure 13B] 1 illustrates a second portion of a non-limiting example of a product solicitation process consistent with certain embodiments disclosed herein. [Figure 13C] 1 illustrates a third portion of a non-limiting example of a product solicitation process consistent with certain embodiments disclosed herein. [Figure 14A] 1 illustrates a first portion of a non-limiting example of a product solicitation cancellation process consistent with certain embodiments disclosed herein. [Figure 14B] 13 illustrates a second portion of a non-limiting example of a product solicitation cancellation process consistent with certain embodiments disclosed herein. [Figure 15A] 1 illustrates a first portion of a non-limiting example of an asset creation process using a blockchain ledger consistent with certain embodiments disclosed herein. [Figure 15B] 1 illustrates a second portion of a non-limiting example of an asset creation process using a blockchain ledger, consistent with certain embodiments disclosed herein. [Figure 15C] 1 illustrates a third portion of a non-limiting example of an asset creation process using a blockchain ledger, consistent with certain embodiments disclosed herein. [Figure 15D] 1 illustrates a fourth portion of a non-limiting example of an asset creation process using a blockchain ledger, consistent with certain embodiments disclosed herein. [Figure 15E] 1 illustrates a fifth portion of a non-limiting example of an asset creation process using a blockchain ledger, consistent with certain embodiments disclosed herein. [Figure 15F] 14 illustrates a sixth portion of a non-limiting example of an asset creation process using a blockchain ledger, consistent with certain embodiments disclosed herein. [Figure 16A] 1 illustrates a first portion of a non-limiting example of an asset update process using a blockchain ledger consistent with certain embodiments disclosed herein. [Figure 16B] 1 illustrates a second portion of a non-limiting example of an asset update process using a blockchain ledger, consistent with certain embodiments disclosed herein. [Figure 16C] 1 illustrates a third portion of a non-limiting example of an asset update process using a blockchain ledger, consistent with certain embodiments disclosed herein. [Figure 17A] 1 illustrates a first portion of a non-limiting example of an asset purchasing process using a blockchain ledger consistent with certain embodiments disclosed herein. [Figure 17B] 1 illustrates a second portion of a non-limiting example of an asset purchasing process using a blockchain ledger, consistent with certain embodiments disclosed herein. [Figure 17C] 1 illustrates a third portion of a non-limiting example of an asset purchasing process using a blockchain ledger, consistent with certain embodiments disclosed herein. [Figure 18A] 1 illustrates a first portion of a non-limiting example of an asset rental process using a blockchain ledger consistent with certain embodiments disclosed herein. [Figure 18B] 1 illustrates a second portion of a non-limiting example of an asset rental process using a blockchain ledger, consistent with certain embodiments disclosed herein. [Figure 18C] 1 illustrates a third portion of a non-limiting example of an asset rental process using a blockchain ledger, consistent with certain embodiments disclosed herein. [Figure 19A]1 illustrates a first portion of a non-limiting example of an asset regeneration process using a blockchain ledger, consistent with certain embodiments disclosed herein. [Figure 19B] 1 illustrates a second portion of a non-limiting example of an asset regeneration process using a blockchain ledger, consistent with certain embodiments disclosed herein. [Figure 19C] Illustrates a third portion of a non-limiting example of an asset regeneration process using a blockchain ledger, consistent with certain embodiments disclosed herein. [Figure 20] 1 illustrates a flow diagram of a non-limiting example of a method for managing digital assets consistent with certain embodiments of the present disclosure. [Figure 21] Illustrates non-limiting examples of systems that can be used to implement certain embodiments of the systems and methods of the present disclosure. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0015] In this specification, a description of a system and method consistent with the embodiments of the present disclosure is provided. Although several embodiments are described, it should be understood that the present disclosure is not limited to any one embodiment, but instead encompasses numerous alternatives, modifications, and equivalents. In addition, numerous specific details are set forth in the following description to provide a thorough understanding of the embodiments disclosed herein, but some embodiments can be practiced without some or all of these details. Moreover, for the sake of clarity, certain technical material that is known in the relevant art has not been described in detail to avoid unnecessarily obscuring the disclosure.

[0016] The embodiments of the present disclosure can be understood by reference to the drawings, in certain instances, though not necessarily all instances, where like parts may be designated by like numerals or descriptions. The components of the disclosed embodiments may be arranged and designed in a wide variety of configurations, as generally described and / or illustrated in the figures herein. Thus, the following description of the embodiments of the systems and methods of the present disclosure is not intended to limit the scope of the disclosure, but is merely representative of possible embodiments of the present disclosure. In addition, the steps of any method disclosed herein do not necessarily have to be performed in any particular order, nor sequentially, nor do steps have to be performed only once, unless otherwise specified.

[0017]

[0013] Embodiments of the disclosed systems and methods may provide for dynamic management of digital assets, products, and / or associated NFTs in a secure manner, such that rights holders' rights in such assets, products, and / or NFTs are respected and / or otherwise secured. Various embodiments disclosed herein may use a trusted ledger to securely record certain assertions regarding digital assets, products, rights holders, and / or various ecosystem participants. Such assertions may be used in connection with rights binding, content packaging, management, and / or protection operations in connection with various transactions associated with the digital assets, products, and / or associated NFTs.

[0018] Certain embodiments disclosed herein may be used to manage digital assets, products, and / or associated NFTs according to various associated business terms supporting various rights holder compensation models, as well as supporting sales models, rental models, subscription models, rental of ownership models, and the like. DRM and / or key management services may be used in connection with managing access to the digital assets and / or associated products, which may include and / or otherwise be associated with digital content, such as, for example and without limitation, audio content, video content, image content, text content, and / or the like. Further embodiments use blockchain connector services to facilitate integration of various aspects of the disclosed systems and methods with established commercial blockchain and digital wallet services.

[0019] Certain aspects of the disclosed processes may be performed by and / or otherwise implemented in connection with one or more entities, services, and / or systems that may comprise, for example, and without limitation, one or more of the following:

[0020] Marketplace Service - an entity that may comprise third-party entities that use trusted data management platform ("TIP") services (or, in certain instances herein, more generally, "trusted data management services") for NFT and / or DRM implementation. Owner – a digital asset owner who may upload content to the Marketplace Service. A distributed blockchain service and / or other suitable trusted ledger service that may be provided by the TIDAL-TIP service and / or another service and / or entity. While various examples described herein may use TIDAL, it will be understood that various embodiments and aspects of the disclosed systems and methods may be implemented using various other trusted databases, ledgers, and / or blockchains that may or may not have the specific attributes associated with TIDAL. TIDAL, as used herein, may generally describe an assertion ledger that has certain characteristics of TIDAL (and / or a subset thereof) as detailed herein, and in some cases may describe a TIDAL that has entries derived and / or otherwise generated based on entries in one or more other ledgers and / or TIDALs, and in some cases may alternatively and / or additionally be referred to as a derived TIDAL. DB - A database that may be created by the marketplace services that may interact with the data virtualization service. File Storage - File storage services such as, for example and without limitation, Amazon S3 cloud, which may be used to store encrypted digital assets. TIP - In various illustrative examples included herein, "TIP" may refer to APIs provided by the TIP service for marketplace services to access various services, which may include, for example and without limitation, one or more of TIDAL, DB, and / or file storage services. Consumers – buyers of digital assets through marketplace services. Payment Gateways – Services that facilitate payments between various services and entities in connection with certain transactions involving Digital Assets.

[0021] Register and upload NFT assets 1A and 1B illustrate a non-limiting example of a process for registering an NFT asset consistent with various embodiments of the present disclosure. Various entities, services, and / or systems participating in the ecosystem may be involved in various aspects of the illustrated process, including, for example and without limitation, an NFT and / or digital asset owner 100, a marketplace service 102, a TIP service 104, TIDAL 106, a database service and / or DB 108 managed by the TIP service 104, a file storage service 110, a payment gateway 112, and / or a consumer 114. Various functions of the systems, services, entities, and / or execution environments illustrated in FIGS. 1A and 1B and elsewhere herein may be integrated into and / or otherwise performed by any suitable combination of a single system and / or service, and / or multiple systems and / or services.

[0022] It will be appreciated that various aspects of the disclosed embodiments may be used in connection with various types of digital assets that may be represented by and / or otherwise associated with NFTs. For example, various disclosed embodiments may be used in managing audio, video, image, and / or written content and / or associated NFTs generated and / or otherwise associated by various content creators, distributors, administrators, and / or other parties that have an interest and / or rights in the content within a content ecosystem.

[0023] Various aspects of the disclosed NFT management process are described below with reference to several constituent steps.

[0024] Account Initialization A marketplace service 102 wishing to interact with and / or otherwise use a TIP service 104 may contact a TIP administrator to be provisioned with a TIP account. Once the account is set up, the marketplace administrator may connect its database to the TIP service 104. In some embodiments, the TIP administrator may create a data set using database services and / or data virtualization ("DV") services that point to a DB 108 managed by the TIP service 104.

[0025] The marketplace service 102 may have a user interface that may enable the owner 100 and / or consumer 114 to sign up for the service. In certain embodiments, this interaction may not necessarily directly create an account, but may notify the marketplace administrator to request that the owner 100 and / or consumer 114 log in using a suitable user authentication method (e.g., Google login and / or any other suitable login protocol). Once an account has been created and the owner 100 and / or consumer 114's email has been verified, the owner 100 and / or consumer 114 may log in to the marketplace service 100 using their associated user credentials. After logging in to the marketplace service 100, the owner 100 and / or consumer 114 may be redirected to a user account interface. The owner 100 and / or consumer 114 may enter payment receipt details on this page.

[0026] Upload Phase Steps 1.1-1.2 The marketplace services 102 may include third party services that use the TIP services 104. The TIP services 104 may provide secure execution environment ("SEE") deployment services, including, for example and without limitation, the following: · Secure communication and key management for TIDAL106 by SEE. · Using DV and / or identity access management ("IAM") services to control access to DB 108 by multiple entities (eg, owners 100, consumers 114, etc.). · Secure management of digital asset encryption and key management with SEE.

[0027] The owner 100 may log into the marketplace service 102 using their associated credentials (e.g., using a Google account via OpenID Connect and / or another authentication protocol). The marketplace service 102 may authenticate the owner 100, potentially returning an indication of success if the owner 100 is authenticated.

[0028] Step 1.3 An owner 100 may upload digital assets (e.g., images, video, audio, text, etc., and / or combinations thereof) to the marketplace service 102. In some embodiments, the owner 100 may provide metadata along with the uploaded digital assets. The data flow may include, for example and without limitation, one or more of the following: ·title. ·explanation. · One or more business terms, which in some embodiments may include public terms and / or private terms. For example, the public business terms may allow a consumer, e.g., consumer 114, to access (e.g., view and / or listen to) the digital asset without engaging in a complete transaction (e.g., purchase, rental, subscription). The public business terms in this non-limiting example may include, for example, a sale and associated pricing information. The private business terms may allow a consumer (e.g., consumer 114) to access (e.g., view and / or listen to) the digital asset after completing, for example, a purchase transaction (e.g., purchase, rental, subscription). The private business terms in this non-limiting example may include, for example, a sale and associated pricing information, a rental and associated pricing information, and / or a subscription and associated pricing information, etc.

[0029] It will be appreciated that various business terms may be associated with digital assets and / or products via metadata in connection with various embodiments disclosed herein. The business terms may represent one or more granular conditions and / or tolerances, including, for example and without limitation, one or more of the following: · Not allowing playback under certain conditions. For example, and without limitation, playback of a Digital Asset and / or Product may be restricted before a date and / or time and / or after a date and / or time (e.g., playback period) within certain countries, locations, and / or jurisdictions, and / or combinations thereof. Not allowing rentals / subscriptions to digital assets and / or products under certain conditions. For example, and without limitation, rentals and / or subscriptions to digital assets and / or products may be restricted before a date and / or time and / or after a date and / or time (e.g., rental period), in certain countries, locations, and / or jurisdictions, below a minimum price, above a maximum price, and / or combinations thereof. · Not allowing sales of Digital Assets and / or Products under certain conditions. For example, and without limitation, sales of Digital Assets and / or Products may be restricted before a date and / or time and / or after a date and / or time (e.g., a sales period), in certain countries, locations, and / or jurisdictions, below a minimum price, above a maximum price, and / or combinations thereof. Not allowing soliciting friends under certain conditions. For example, and without limitation, solicitation allowance may be limited before dates and / or times and / or after dates and / or times (e.g., solicitation periods), within certain countries, locations, and / or jurisdictions, not to exceed a maximum amount of solicitations (e.g., concurrent solicitations and / or total solicitations), and / or combinations thereof. Limiting the maximum amount of rentals (e.g., amount of simultaneous rentals and / or total rental amount). · Limit the maximum number of sales permitted.

[0030] The business terms articulated in the metadata may further represent indications of fractional ownership and / or other rights held in connection with the digital asset and / or associated product and / or NFT. In certain embodiments, such fractional rights may be expressed in terms of ownership and / or rights holding rates, discounts, and / or percentages, although other methods and / or manners of implementing fractional ownership and / or rights holding are also envisioned. For example, and without limitation, the business terms may represent indications of the name and / or other identity of the rights holder and associated ownership and / or ownership percentages to the digital asset, product, and / or associated NFT. In various embodiments, such fractional ownership and / or rights and / or rights may be traded and / or otherwise sold and / or exchanged using services enabled by embodiments of the disclosed ecosystem. Additionally, as discussed in more detail below, payment models and / or mechanisms between owners and / or rights holders may be implemented based at least in part on the fractional ownership and / or rights information detailed in the business terms.

[0031] Step 1.4 The marketplace service 102 may add identity information associated with the owner 100 to a payload that may include the digital assets and send the payload along with the associated metadata to the TIP service 104 (e.g., via a REST API). In some embodiments, the marketplace service 102 may receive and / or otherwise retrieve information stored in a user account associated with the owner 100, such as name, address, email, contact information, payment receipt details, etc., and add this information to the metadata.

[0032] Steps 1.5 - 1.7 The TIP service 104 may generate assertions, which may include base assertions and / or account assertions, based at least in part on the uploaded digital assets. For example, in some embodiments, the assertions may include a hash generated based on the digital asset and / or related information (e.g., marketplace and / or owner account information) and / or one or more hashes generated based thereon. In some embodiments, the assertions may include a signed hash value that allows for some degree of authentication of the recorded assertion.

[0033] The assertions may be recorded in a trusted ledger, which may comprise TIDAL 106, although other types of ledgers may also be used in connection with various disclosed embodiments. As detailed above, a base assertion may be generated based on a digital asset, for example, and without limitation, by hashing the digital asset. An account assertion may be generated based on the base assertion and identity information associated with the owner 100. For example, an account assertion may include a hash of the base assertion concatenated with a token and / or other identifying information associated with the owner 100 of the digital asset.

[0034] The TIP service 104 may check whether the base assertion (e.g., a hash) exists in TIDAL 106 and / or a derived ledger (e.g., a ledger that may be a TIDAL with entries derived and / or otherwise generated based on entries in one or more other ledgers and / or TIDAL). When the hash of the base assertion does not exist in TIDAL 106 (e.g., based on an indication that no duplicates exist in the ledger), the TIP service 104 may import and / or otherwise store the base assertion and the account assertion in TIDAL 106. In some embodiments, the base assertion and the account assertion may be cryptographically signed with a key securely associated with the TIP service 104. TIDAL 106 and / or a service that manages TIDAL 106 may be managed according to an ingestion policy configured to accept entries into TIDAL 106 when the entry to be recorded in TIDAL 106 is signed by the TIP service 104 and / or another authorized service and / or entity.

[0035] In some embodiments, when the hash of the base assertion already exists in TIDAL 106, the TIP service 104 may check whether the account assertion also exists in TIDAL 106. If the account assertion already exists in TIDAL 106, this may indicate that the original owner of the digital asset has attempted to re-upload the digital asset. In this case, processing may proceed to step 1.8. If the account assertion does not exist in TIDAL 106, this may indicate that a different owner has attempted to upload a copied digital asset to the marketplace. In this case, a warning message may be returned to terminate further transactions.

[0036] Steps 1.9 - 1.14 Upon completion of the base assertion and / or account assertion checks, the TIP service 104 may store market metadata for the digital asset in DB 108. The TIP service 104 may also create a market assertion and ingest the generated market assertion into TIDAL 106. In some embodiments, the market assertion may be generated based on the account assertion and the market metadata (which may be defined in some embodiments in step 1.3). For example, the market assertion may include a signed hash of the concatenation of the account assertion and the market metadata. In certain implementations, the market assertion may be cryptographically signed with a key associated with the TIP service 104, and TIDAL's ingest policy may be configured to only accept entries when the entries are signed by the TIP service 104.

[0037] To protect the uploaded digital assets, the TIP service 104 may generate a content key, which may include a symmetrically encrypted content key. The TIP service 104 may encrypt the digital asset with the generated content key and then encrypt the content key with a key associated with the service (e.g., a private symmetric key, a public key associated with a private key securely stored by the TIP service, etc.). The TIP service private key may be stored in a secure storage and / or vault in the SEE in some embodiments. The TIP service 104 may store the encrypted content key in the DB 108 and the encrypted digital asset in the file storage service 110. After successful completion, the TIP service 104 may return a market assertion to the marketplace service 102. In some embodiments, an indication of successful upload and / or registration of the digital asset may be provided to the owner 100 by the marketplace service 102.

[0038] Download Phase 2A and 2B illustrate non-limiting examples of processes for purchasing and accessing NFT assets consistent with certain embodiments disclosed herein.

[0039] Steps 2.1-2.2 The consumer 114 may log into the marketplace service 102 using their associated credentials (e.g., using a Google account via OpenID Connect and / or another authentication protocol). The marketplace service 102 may authenticate the consumer 114 based on the provided credentials and / or return an indication of successful authentication (or unsuccessful if the credentials are not authenticated).

[0040] Steps 2.3 - 2.8 The marketplace service 102 may request the TIP service 104 to retrieve the verified asset. In some embodiments, the TIP service 104 may retrieve asset details from the DB 108 and generate a market assertion. The TIP service 104 may check the market assertion against the TIDAL 106 to verify up-to-dateness and / or completeness. The TIP service 104 may send the verified asset details back to the marketplace service 102. The marketplace service 102 may then display market metadata (which may be defined by the owner 100 as detailed above) associated with the verified digital asset to the consumer 114. The consumer 114 may then browse and purchase the available digital assets from the marketplace service 102. Depending on the business terms of the digital asset, the consumer may, for example and without limitation, purchase (e.g., own), rent, and / or subscribe to the digital asset.

[0041] Steps 2.9 - 2.14 A variety of consumer transactions may be supported by the marketplace service 102, including, for example and without limitation, purchase, rental, play, and / or subscription transactions, although other types of transactions associated with digital assets are contemplated. For example, when a consumer 114 requests access to a digital asset for viewing and / or listening (e.g., play), the process may proceed to step 3.1 of FIG. 2C. In another example, when a consumer 114 requests to purchase a public or private digital asset for sale, rental, and subscription (e.g., step 2.9), the marketplace service 102 may redirect the consumer 114 to a secure payment gateway service 112. In some embodiments, the secure payment gateway service 112 may comprise a third-party secure payment service, such as, for example and without limitation, PayPal, although other payment services may be used.

[0042] 2B , the marketplace service 102 may call an API of the payment gateway service 112. The payment gateway service 112 may respond to the marketplace service 102 with one or more available payment options. The consumer 114 may select a suitable payment method supported by the marketplace service 102, such as, for example and without limitation, credit and / or debit card payment, PayPal, etc. The consumer 114 may confirm payment details with the marketplace service 102.

[0043] The marketplace service 102 may call the API of the payment gateway service 112 with the requested order information and may receive an indication from the payment gateway service 112 indicating successful payment by the consumer 114. After the payment is successful, the marketplace service 102 may receive the amount from the consumer 114. The marketplace service 102 may then distribute the payment to the respective owners 100 in accordance with one or more applicable business agreements (as discussed below in connection with FIG. 3).

[0044] Step 2.15 The marketplace service 102 may create a signed JSON web token ("JWT") with the consumer's identity information, the agreed-upon business terms, the base assertion, and / or other transaction details. The marketplace service 102 may send the generated JWT to the TIP service 104. The marketplace service 102 may sign the JWT using its private key.

[0045] Steps 2.16-2.18 The TIP service 104 may verify the JWT signature using a public key associated with the marketplace service 102. For the sale of public and / or private digital assets, the TIP service 104 may create a new account assertion based on the base assertion and the identity of the new owner (e.g., the identity of the consumer 114). For example, in some embodiments, the TIP service 104 may create a new account assertion by generating a cryptographic hash based on information associated with the base assertion and the identity of the new owner (e.g., a hash calculated on the concatenated information of the base assertion and the identity of the new owner). The TIP service 104 may register the new account assertion with TIDAL 106. The TIP service 104 may further register any old account assertion and / or its derivatives in TIDAL 106 as false and / or otherwise expired.

[0046] For rentals and / or subscriptions of private digital assets, the TIP service 104 may generate a rights assertion based on the account assertion and the agreed-upon business terms information. For example, in some embodiments, the TIP service 104 may create a new rights assertion by generating a cryptographic hash (e.g., a hash calculated on the concatenated information of the account assertion and the agreed-upon business terms information) based on information associated with the account assertion and the agreed-upon business terms information. The agreed-upon business terms information may include, for example and without limitation, rental and / or subscription details and / or identity information associated with the consumer 114. The rights assertion may be signed by the TIP service 104 (e.g., cryptographically signed with a private key securely associated with the TIP service 104).

[0047] The TIP service 104 may register the rights assertion with TIDAL. TIDAL's ingestion policy may be configured to accept assertions that include a signature made by the TIP service 104. Based on the purchase transaction, the TIP service 104 may also store the transaction information in DB 108 by correlating the transaction information to the purchased digital asset. This transaction information may include, for example and without limitation, the identity associated with the consumer 114 and agreed upon business terms information. The TIP service 104 may use the rights assertion for validation purposes for rental and / or subscription of the private digital asset in step 3.5 shown in connection with FIG. 2C.

[0048] Steps 2.19-2.21 To access a public or private digital asset for viewing, listening, reading, etc., the TIP service 104 may generate a unique link to access the digital asset. This link may include a base assertion and may map to the original digital asset on the associated file storage service 110. The TIP service 104 may provide the generated link to the marketplace service 102. The consumer 114 may then be provided by the marketplace service 102 with the link for use in accessing the digital asset. For example, and without limitation, in the case of rights-managed audio and / or video content, the consumer 114 may use the link to stream the content. In certain embodiments, when the consumer 114 accesses the content, a DRM token may be generated (e.g., as in the case of audio, video, and / or other DRM-managed content).

[0049] Steps 3.1-3.8 When the consumer 114 opens the link to access the digital asset, a request may be sent to the marketplace service 102. The marketplace service 102 may send a validation request to the TIP service 104. In some embodiments, the request may include a signed JWT with the base assertion and the identity of the consumer 114.

[0050] If the digital asset is marked as public in the market assertion and validates TIDAL 106, the TIP service 104 may retrieve the base assertion from the JWT and use the retrieved base assertion to retrieve the encrypted content key from the digital asset from DB 108.

[0051] If the digital asset is marked as private in the market assertion and / or verified with TIDAL 106, the TIP service 104 may retrieve the base assertion and identity information of the consumer 114 from the JWT. The agreed-upon business terms and / or identity of the owner 100 may be retrieved from DB 108 using the retrieved base assertion and consumer identity information. The TIP service 104 may generate a rights assertion and check the rights assertion against TIDAL 106 (which may be a derived TIDAL). If the rights assertion is present in TIDAL 106 (e.g., based on TIDAL returning an indication that the assertion is validated), the TIP service 104 may check the contents of the agreed-upon business terms (e.g., check whether the rental period has expired). If the agreed-upon business terms are valid for the consumer 114, the TIP service 104 may use the retrieved base assertion to retrieve an encrypted content key for the digital asset from DB 108.

[0052] In some embodiments where a DRM method is applied in connection with various aspects of the disclosed systems and methods (e.g., in connection with audio and / or video content), the TIP service 104 may decrypt the encrypted content key with the TIP service's 104 private key. The TIP service 104 may then issue a token for the DRM license by calling the DRM service API and providing basic assertions, such as the content ID, the content key, and / or agreed upon business terms information (e.g., rental period, output control, etc.). Once the token is issued by the DRM service, the TIP service 104 may return the token to the marketplace service 102. The marketplace service 102 may then initiate playback of the digital asset.

[0053] In a further embodiment, the TIP service 104 may decrypt the encrypted content key with the private key of the TIP service 104. The TIP service 104 may then retrieve the encrypted digital asset from file storage and decrypt the digital asset using the content key. The TIP service 104 may then make the decrypted digital asset available to the consumer 114 using the link. The consumer 114 may then access the digital asset via the link provided by the marketplace service 102.

[0054] Transaction Clearing Phase 3 illustrates a non-limiting example of an aspect of an NFT transaction process consistent with certain embodiments disclosed herein. As discussed in more detail below, in various embodiments, the marketplace service 102 may distribute payments to respective owners 100 in accordance with one or more applicable business agreements and / or terms.

[0055] Steps 4.1-4.5 The marketplace service 102 may request new transaction details from the TIP service 104. For example, the marketplace service 102 may periodically (e.g., weekly) request new transaction details from the TIP service 104. Based on the purchase amount, the agreed upon business terms information, and / or the associated marketplace service fee (which may be retrieved from the DB 108 by the TIP service 104), the marketplace service 102 may generate an amount due to the owner 100 of the digital asset. The marketplace service 102 may make the payment to the owner 100 using available payment receipt details.

[0056] Token Rights Management Service Ecosystem According to embodiments disclosed herein, token rights management ("TRM") services may be used in connection with managing NFTs and / or other digital assets. As discussed above, NFTs may include cryptographic tokens recorded on a trusted ledger, such as a blockchain ledger, that may represent digital assets. However, applications of NFTs may be broader, ranging from simple media transactions to complex secured loans. FIGS. 4A-14B illustrate various conceptual diagrams showing various aspects of a process for managing NFTs using TRM services in a TRM ecosystem, consistent with certain embodiments disclosed herein.

[0057] TRM Ecosystem Entities, Services, and / or Systems Some aspects of the disclosed processes using a TRM service may be performed by and / or otherwise implemented in connection with one or more entities, services, and / or systems that may be similar to the entities, services, and / or systems described above in connection with Figures 1A-3. These entities, services, and / or systems may include, for example, and without limitation, one or more of the following: Marketplace service 102 - an entity that may include third party entities that use the TRM service 402 to implement various NFT management processes. In various embodiments, the TRM service 402 may trust the marketplace service 102 for TRM API calls. The marketplace service 102 may manipulate data for its own marketplace, but may not be able to easily manipulate, or in some implementations may not be able to manipulate, data for another marketplace. Marketplace Administrator - An administrator who may set up and / or otherwise configure the marketplace service 102 using the TRM API and the TIP service 104. In some implementations, the marketplace administrator's TIP account ID may be used as the marketplace ID. Original Rights Holder ("ORH") 400 - ORH 400, which may be a content creator, distributor, and / or any other service, entity, and / or party that may hold the original rights in a digital asset, upload the digital asset, and / or create a product. · Owner 100 - A product owner 100 who may have created their own product (eg, as an ORH 400) and / or purchased a product through the marketplace service 102. - A decentralized blockchain service and / or other suitable trusted ledger service, which may be provided by TIDAL 106-TIP and / or another service and / or entity. While various examples described herein may use TIDAL, it will be understood that various embodiments and aspects of the disclosed systems and methods may be implemented using a variety of other trusted databases and / or ledgers that may or may not have the specific attributes associated with TIDAL detailed herein. Additionally, while various examples are described herein with respect to TIDAL, it will be understood that derived TIDALs may also be used in connection with various aspects of the disclosed embodiments. DB 108 - A database that may be created and / or otherwise managed by the marketplace service 102 and / or the TIP service 104 that may interact with the data virtualization service. · File Storage Service 110 - A file storage service 110, such as, for example and without limitation, Amazon S3 cloud, that may be used to store encrypted digital assets. · TRM Service 402 - The TRM service 402 may be implemented via an API for the marketplace service to access TIDAL 106, DB 108, and / or file storage service 110. · TIP Services 104 - TIP services 104 used for various TRM implementations that may provide governance between different marketplace services 102. TIP services 104 may include, for example and without limitation, one or more of the following: (1) DV services of TIP services 104 used to fetch digital assets, products, and / or transactions using appropriate queries (e.g., SQL queries); (2) TIP IAM services that may include IAM services of TIP used for governance between different marketplace services 102; (3) TIP vault that may include TIP services 104 for securely storing protected data. Key Encryption Keys ("KEK") stored in the TIP vault may be accessible only to TRM administrators in certain implementations (i.e., marketplace administrators may have limited access, if any); (4) TIP SEE that may include TIP services 104 providing a SEE for running the TRM backend. The TRM backend may be used in some implementations for communication between the TRM service 402, the TIDAL 106, the DB 108, and / or the file storage service. · Consumer 114 - Buyers of digital assets through marketplace services. Payment Gateway 112 - The payment gateway service 112 may include services that facilitate payments between various services and entities in connection with particular transactions involving digital assets. · TRM Administrator - Administrator who sets up TRM access for Marketplace Services 102 including TIP account creation. Key management service ("KMS") 114 - a service configured to provide certain key management functions including, for example and without limitation, key generation, content key storage and / or management, etc. KMS 104 may in some embodiments be provided by and / or included in a DRM service. Invitee--A user who is invited by a Product Owner 100 to consume the Owner's 100 product.

[0058] TRM Ecosystem Identifier Various embodiments disclosed herein may use various identifiers in connection with digital assets, users, entities, services, and / or other aspects of the disclosed systems and methods. These identifiers may include, for example and without limitation, one or more of the following: User ID - A user (e.g., owner 100, consumer 114, etc.) may be assigned a user ID and / or associated identifier. The user ID may include, for example and without limitation, one or more of the following: (1) an owner ID, which may include a user ID of the owner 100 of the product; (2) an ORH ID, which may include a user ID of the ORH 400 of the product (e.g., the product creator); (3) a consumer ID, which may include a user ID of the consumer 114 of the product (e.g., a user who purchases and / or rents the product); and an invitee ID, which may include a user ID of the invitee. Asset ID - An asset may be assigned an asset ID after a successful upload. Product ID - When a product is created, a product ID may be generated (eg, a "UUID") and assigned to the new copy of the product. Task ID - A task can be assigned a task ID. Product Serial ID - Each product copy may be assigned a unique identifier represented by the Product Serial ID. Transaction ID - Transactions may be assigned a transaction ID. These transactions may include, for example and without limitation, purchases, sales, subscriptions, and / or other transactions that may be represented by business terms. · Key ID ("KID") - A key ID may be generated as a key identifier for the KMS 404. stat ID - The stat ID may correspond to a stat row in the stats table. Marketplace ID - The marketplace ID may correspond to the marketplace service 102. In some embodiments, the marketplace ID may be the same as the account ID of the marketplace service 102 on the TIP service 104.

[0059] TRM Ecosystem Table Various tables may be used in connection with managing NFTs in connection with the various disclosed embodiments. These tables may include, for example and without limitation, one or more of the following: Task Table - The task table may include, for example and without limitation, one or more of the following: task ID, marketplace ID, creator ID, asset ID / product ID (potentially used for updates), title, task timestamp, asset / product, status (e.g., processing, completed, failed, deleted, etc.), type of task (e.g., upload, update, unlist, delete), etc. Asset Table - The asset table may include, for example and without limitation, one or more of the following: asset ID (which may be unique per asset), marketplace ID, media type (e.g., audio, video, image, text, etc.), encrypted content key, KID, file location URL, title, asset assertion, fact (e.g., hash of file content), upload timestamp, ORH ID, metadata (JSON), initial supply, remaining supply, preview URL, etc. Products Table - The products table may include, for example and without limitation, one or more of: product ID, product serial ID, marketplace ID, name, asset (e.g., list of asset IDs included in a bundle), serial number, type (e.g., public or private), preview URL, listed timestamp, owner ID, ORH ID, business terms (e.g., array of business terms), sale price, rental price, rental period, metadata (e.g., JSON), product assertions, facts, delist, remove, invitee (e.g., list of invitee IDs), etc. · Transaction Table - The transaction table may include, for example and without limitation, one or more of a transaction ID, marketplace ID, owner ID, consumer ID, product serial ID, timestamp, business terms, sale price, rental price, rental expiration date, asset ID, etc. Marketplace User Table - The marketplace user table may include, for example and without limitation, one or more of user ID, email, name, account creation timestamp, balance, role (e.g., roles supported by the marketplace service 102), etc. Marketplace Table - The Marketplace table may include, for example and without limitation, one or more of Marketplace ID, Name, Contact Email, etc. This table may be manually managed by a TRM administrator. When a new marketplace service 102 is provisioned, its TIP account may be created, an entry in this table may be created and the Marketplace ID may be set to the newly created TIP account ID.

[0060] TRM Ecosystem Physics Datasets The physical datasets in the disclosed TRM ecosystem embodiments may include TIP datasets that map to the TRM tables described above. These datasets may be used to fetch assets, products, and transactions from the TIP using queries (e.g., fetch directly from the TIP using SQL queries).

[0061] Various data sets may be used in connection with managing NFTs in accordance with various disclosed embodiments. Such trusted data flows may include, for example and without limitation, one or more of the following: Task Physical Dataset - A TIP dataset that can map to the Task table. Marketplace administrators may have view and / or query privileges to this dataset. TRM administrators may have admin privileges to this dataset. Asset Physical Dataset - A TIP dataset that can map to the Asset table. Marketplace administrators may have view and / or query privileges to this dataset. TRM administrators may have admin privileges to this dataset. Product Physical Dataset - A TIP dataset that may map to the Products table. Marketplace administrators may have view and / or query privileges to this dataset. TRM administrators may have admin privileges to this dataset. Transaction Physical Dataset - A TIP data set that can map to the Transactions table. Marketplace administrators may have view and / or query privileges to this data set. TRM administrators may have admin privileges to this data set. Marketplace User Physical Dataset - A TIP dataset that may map to the Marketplace User table. This dataset may be created by each Marketplace Administrator and supported by the Marketplace. Marketplace Administrators may have administrator privileges to this dataset. TRM Administrators may not have privileges to this dataset.

[0062] TRM Ecosystem Asset Assertions Various assertions may be used in connection with managing NFTs in connection with various disclosed embodiments. These assertions may include asset assertions and product assertions. Asset assertions may include, for example and without limitation, one or more of the following: Asset Assertions - Asset assertions may include a hash of file contents, which in some embodiments may be used to detect copied content using TIDAL 106. In some embodiments, asset assertions may include a hash of a hash of file contents, which may include binaries (e.g., hash(hash(file contents))) of audio, video, and / or image files. Asset Ownership Assertion - The asset ownership assertion may prove ownership of an asset and / or enable playback by the ORH 400. In some embodiments, the asset ownership assertion may include an asset assertion + ORH ID (as used here and elsewhere herein, "+" may indicate concatenation of values). In further embodiments, the asset ownership assertion serves as proof of ownership of an asset via the TIDAL 106.

[0063] TRM Ecosystem Product Assertions Various assertions may be used in connection with managing NFTs in connection with the various disclosed embodiments. These assertions may include, for example and without limitation, one or more of the following: Product Assertion - The product assertion, in some embodiments, may serve as the basis for subsequent assertions. The product assertion may be stored in a product table for each entry for quick assertion calculation. In some embodiments, the product assertion may include a hash of the concatenated information of the asset assertion and serial number of the individual asset. The asset assertions may be concatenated in alphabetical order in some implementations. Product Ownership Assertion - A product ownership assertion may serve as proof of product ownership in TIDAL 106. In some embodiments, a product ownership assertion may include a product assertion and an owner ID. Market Assertion - Market Assertion may check the validity of metadata in DB 108. Market Assertion may act as a validation of product market metadata of product table entries in TIDAL 106. Market Assertion may include Product Assertion and Market Metadata. In at least one non-limiting example, Market Metadata may be determined according to Market Metadata = Product Metadata (e.g., Title + Description) + Business Metadata (e.g., Business Terms + Sale Price + Rental Price + Rental Period). · Rights Assertion - Rights assertion may check the validity of a transaction. Rights assertion may act as a validation of the transaction date in TIDAL 106. In at least one non-limiting example, rights assertion may be calculated according to Rights Assertion = Product Assertion + Transaction Price (e.g., amount paid by the consumer 114) + Business Terms + Consumer ID. Product Solicitation Assertion - The product solicitation assertion may validate the invitee's access to the product. In at least one non-limiting example, the product solicitation assertion may be calculated according to Product Solicitation Assertion = Product Ownership Assertion + Invitee ID.

[0064] TRM Ecosystem API Various APIs may be used in connection with managing NFTs in connection with various disclosed embodiments. These APIs may include, for example and without limitation, the TRM verification API of the TRM service 402. This API allows the marketplace service 102 to verify data using TIDAL 106. In some embodiments, the input may include a list of asset IDs / product serial IDs / transaction IDs, and the API may verify whether the data on the database corresponding to these IDs is valid. For assets, the verification may use asset ownership assertions using TIDAL 106. For products, the verification may use product ownership assertions and market assertions using TIDAL 106. For transactions, the verification may use rights assertions using TIDAL 106. In some embodiments, the API may accept as input one or more of a list of asset IDs, product serial IDs, and / or transaction IDs, and / or types of IDs (e.g., assets, products, transactions, etc.). In certain embodiments, the API may return a list of IDs that failed verification. An empty array returned may mean that the data for all IDs was valid.

[0065] TRM Ecosystem Business Conditions Various business terms may be used in connection with managing NFTs in accordance with the various disclosed embodiments. These business terms may include, for example and without limitation, one or more of the following: · Sale - Ownership of a product is transferred from one user to another. Associated business metadata may include, for example and without limitation, pricing information. Rental - A user can access a product for a limited time. Ownership may be maintained by the current owner. Associated business metadata may include, for example and without limitation, price and / or rental period. Subscription - A user can access a product if they pay a subscription fee. Ownership may remain with the current owner. Associated business metadata may include, for example and without limitation, price and / or rental period. · Ownership rental - Ownership may be transferred from ORH 400 to another user for a limited time. The new owner may make this product available for ownership rental / rental / subscription. However, after the ownership rental period, the ownership may be reverted back to ORH 400. The associated business metadata may include price and / or rental period. In some implementations, the new owner may not set a rental period (for rental or subscription) that exceeds the original rental period (for ownership rental) set by ORH 400. When a product is sold, a scheduled job may be created. This job may transfer the ownership back to ORH 400 after the ownership rental period. The scheduled job may be a thread in a program that runs after the rental period expires. In some embodiments, changing the ownership rental period may be restricted to ORH 400. Subsequent ownership rental transactions from the new owner may have the original ownership rental period. The business terms for the ownership rental may be restricted to ORH 400 in some embodiments. In some implementations, if an existing rental / subscription transaction exists for the product, the business terms may not be changed to rental of ownership.

[0066] TRM Ecosystem Metadata Various metadata definitions may be used in connection with managing NFTs in connection with various disclosed embodiments. These metadata definitions may include, for example and without limitation, one or more of the following: Asset Metadata - Asset metadata may include the title in some embodiments. Product Metadata - Product metadata, in some embodiments, may include one or more of a title, description, and / or any additional metadata determined by the marketplace administrator. · Business Metadata - Business metadata, in some embodiments, may include one or more of business terms, sale price, rental price, rental period, subscription price, subscription period, rental price of ownership, and / or rental period of ownership.

[0067] Remove a product from the list In various embodiments, any product may be unlisted from the marketplace service 102 at any time by its owner, which may be the ORH 400. This means that the product is no longer available on the marketplace service 102 for purchase, rental, and / or subscription by consumers 114. In some embodiments, a product table entry may have a field called "Unlisted" that may take on values ​​"0" or "1." A unlisted value of "0," meaning false, may mean that the product is currently available on the marketplace service 102. On the other hand, a unlisted value of "1," indicating true, may mean that the product is currently unlisted and therefore not currently available on the marketplace service 102.

[0068] Asset provision and product copying When a digital asset is uploaded to the marketplace service 102, the ORH 400 may indicate an initial supply of the digital asset. In some implementations, once selected, the initial supply of the asset may not be changed by the ORH 400 (although this may not be true in all implementations). The initial supply of the digital asset may set an upper limit on the number of times the asset may be bundled into different products, such that the ORH 400 may not add the digital asset to new products indefinitely.

[0069] When a product is created, the ORH 400 may select the number of copies of the new product. Each copy may have a unique product serial ID, but may have a uniform product ID to correlate the different copies. Each such copy may be referred to as a product copy. In at least one non-limiting example, assume a new product A is created with five copies. In the backend, this may result in five new entries in the product table, e.g., A0 (serial #0), A1 (serial #1), A2 (serial #2), A3 (serial #3), A4 (serial #4). Each entry or product copy may have a unique product serial ID, a UUID that serves as the primary key to the product table. However, the product copies may have the same product ID, a UUID that is used to correlate copies of product A.

[0070] In some embodiments, when a digital asset is bundled into a product, the remaining supply of the digital asset may be reduced by the total number of copies of the product. For example, and without limitation, consider asset A with an initial supply of 100. ORH 400 may decide to create product X that includes asset A with 10 copies. Now, the remaining supply of A may be 90. Now, ORH 400 may create another product Y that bundles A, and ORH 400 may decide to have 50 copies of product Y. In this case, the remaining supply of A may be reduced to 40. If ORH 400 decides to remove product X, the remaining supply of A may be increased by the number of unsold copies of X. For example, if product X remains completely unsold, the remaining supply of A will be 50. In some embodiments, the number of versions of a product may be limited by the minimum remaining supply across the bundled assets within that product.

[0071] Marketplace Preparation In some embodiments, a marketplace service 102 that wishes to use a TRM service 402 consistent with various aspects of the disclosed embodiments may contact a TRM administrator to be provisioned with a TIP account. The TRM administrator 402 may create an API key and client that can be used by the marketplace service 102 to obtain an access token for authenticating TRM API calls.

[0072] Asset, product, and transaction tables may be common to different marketplace services 102 and may be under a TRM TIP instance. A marketplace may query these tables via the TIP DV service, as data set restrictions may be set up by a TRM administrator so that each marketplace service 102 may view entries matching its marketplace ID (e.g., TIP account ID). In some embodiments, a marketplace service 102 may manage its own user authentication and marketplace user tables.

[0073] In some embodiments, the marketplace may have an interface that allows the ORH 400, owner 100, and / or consumer 114 to "sign up," which may not directly create an account, but may notify a marketplace administrator to have the ORH 400, owner 100, and / or consumer 114 log in using user credentials (e.g., Google login). Once an account is created and their email is verified, the ORH 400, owner 100, and / or consumer 114 may log in to the marketplace service 102 using their user credentials. After logging in to the marketplace service 102, the ORH 400, owner 100, and / or consumer 114 may be redirected to a user account page, where the ORH 400, owner 100, and / or consumer 114 may enter their payment receipt details.

[0074] Asset Upload 4A and 4B illustrate a non-limiting example of an asset upload process consistent with certain embodiments disclosed herein.

[0075] Step 1.1-1.2: User login In some embodiments, the ORH 400 may log in to the marketplace service 102. In one particular embodiment, a Google account (e.g., Open ID connect) may be used for logging in, although other methods of logging in may also be employed. The marketplace service 102 may authenticate the ORH 400 and, if authentication is successful, issue an authentication token to the ORH 400.

[0076] Steps 1.3-1.4: Upload assets The ORH 400 may upload digital assets (e.g., images, videos, text, audio, etc.) to the marketplace service 102. The ORH 400 may specify an initial supply of the digital asset, which may be an upper limit on the number of times the asset may be bundled into different products. The ORH 400 may upload a preview file to act as a thumbnail for the asset on the marketplace portal. The ORH 400 may also provide the asset title, description, and any other metadata, which may be determined and / or otherwise set by the marketplace service 102.

[0077] The marketplace service 102 can obtain a TIP access token from the TIP IAM service using the TIP IAM service's API key and secret, which the marketplace service can provide to the TRM API of the TRM service 402 along with the request data (e.g., digital asset file, preview file, initial supply, metadata).

[0078] Steps 1.5-1.7: Verify the Marketplace The marketplace TIP access token may be verified via the TIP IAM service. The marketplace ID may be obtained from the IAM service and / or the user info endpoint. The marketplace service 102 may then be verified by interacting with DB 108 (e.g., it may be determined that the marketplace ID exists in a marketplace table in DB 108 because the marketplace table stores a list of verified marketplace services 102).

[0079] Steps 1.8-1.11: Asset Assertion The TRM service 402 may generate an asset assertion. In some embodiments, the asset assertion may include a hash of the file contents of the digital asset. An asset ownership assertion may also be generated by the TRM service 402. In one particular embodiment, the asset ownership assertion may be generated by concatenating an ORHID to the asset assertion.

[0080] The TRM service 402 may query TIDAL 106 to check if an asset assertion already exists, and if so, may indicate that the digital asset has already been uploaded to the TRM service 402 and may therefore reject the copied content. If not, a new asset and asset ownership assertion may be inserted into TIDAL 106.

[0081] Steps 1.12-1.20: Encrypt assets A task entry may be created in the task table with a status of "in progress" while the digital asset encryption is taking place. In various embodiments, one or more steps of the asset encryption process may be implemented as an asynchronous task. To protect the digital asset, a KEK may be retrieved from the TIP vault and / or a new KEK may be generated and stored in the TIP vault if one does not already exist. A KID may be generated. The KEK and KID may be sent to the KMS 404 and a content key -K- may be generated and returned to the TRM service 402. The digital asset file may be encrypted using the content key using K. The encrypted digital asset and / or preview may be stored in the file storage service 110 and an associated location (e.g., URL) that may be used to access the encrypted digital asset and / or preview may be returned to the TRM service 402. An entry may be created in the asset table containing the asset information. An entry may be updated in the task table with the status set to "completed" and the asset ID may also be updated in the task table.

[0082] In some embodiments, to protect the digital asset, a private key may be obtained from the TIP vault. A new private key may be generated and stored in the TIP vault if one does not already exist. In some embodiments, the content key may be encrypted using the private key. An entry may be created in an asset table that includes the associated asset information. The entry may be updated in a task table to set the status to "completed" and the asset ID may also be updated in the task table.

[0083] In some embodiments, an indication of a successful upload of the digital asset may be communicated from the TRM 402 to the marketplace service 102 and / or the ORH 400.

[0084] Product Creation 5A-5C illustrate a non-limiting example of a product creation process consistent with certain embodiments disclosed herein.

[0085] Steps 2.1-2.2: User Login In some embodiments, the ORH 400 may log into the marketplace service 102. In certain embodiments, a Google account (e.g., Open ID connect) may be used for logging in, although other methods of logging in may also be employed. The marketplace service 102 may authenticate the ORH 400 and, if authentication is successful, issue an authentication token to the ORH 400.

[0086] Steps 2.3-2.9: Create a product When the ORH 400 decides to create a new product, the marketplace service 102 may use the TIP access token of the TIP service 104 to fetch a list of assets created by the ORH 400 from the asset physics dataset via the DV provided by the TIP service 104. The ORH 400 may use the TRM validation API to check whether the fetched assets are valid. Once the assets are validated, the ORH 400 may determine which of the assets to bundle with this new product and provide supporting product information. The supporting product information may include, for example and without limitation, one or more of the following: · Number of copies to be minted. ·title. Preview files (e.g. thumbnails). Product Type - In some embodiments, the product type may be public or private. Public products may be accessed (e.g., rendered for viewing and / or listening, etc.) by any consumer. Private products may be accessed by consumers after a purchase transaction. · Business Terms - Business terms may include, for example and without limitation, sale, rental, subscription, rental of ownership, etc. Business Metadata - Business metadata, in certain embodiments, may include price (e.g., price for sale, rental, subscription, rental of ownership) and / or rental period (e.g., rental period for rental, subscription, rental of ownership, etc.). A product description and / or any other metadata that may be defined by the marketplace service 102.

[0087] The marketplace service 102 may generate and issue a product creation request to the API of the TRM service. In some embodiments, the product creation request may include a marketplace TIP access token.

[0088] Steps 2.10-2.12: Verify the Marketplace The marketplace TIP access token included in the product creation request may be verified via the IAM service of the TIP service 104. The marketplace ID may be obtained from the IAM service and / or another user information endpoint. The marketplace service 102 may then be verified as registered in DB 108 (e.g., the marketplace ID is present in the marketplace table because the marketplace table stores a list of verified marketplaces).

[0089] Steps 2.13-2.14: Verify ownership of the underlying asset For each asset bundled in a product, the TRM service 402 may generate an asset ownership assertion and may validate the asset ownership assertion with TIDAL 106 (e.g., check whether the assertion exists in TIDAL 106). If any of the asset ownership assertions are not validated, the product creation request may be rejected because the ownership of the underlying assets may not be validated.

[0090] Steps 2.15-2.16: Check asset supply count The remaining supply count of the underlying asset in the product may be retrieved from the asset table. If the remaining supply count is less than the specified total number of copies of the product, the product creation request may be rejected. In such a case, the TRM API may inform the marketplace service 102 of the maximum number of copies of the product possible and indicate the digital assets that are in short supply for this request.

[0091] Steps 2.17-2.18: Start the process The TRM service 402 may generate one or more of the following: Product ID: The uniform UUID of the product in this set. Product Serial ID: A unique UUID for each individual copy of the product. · Serial Number: A sequential number assigned to each product serial ID (e.g., 0, 1, 2, ... (total copies - 1)).

[0092] A task entry may be created by the TRM service 402 in the task table with a status of "in progress."

[0093] Steps 2.19-2.25: Create the assertion and complete the process The TRM service 402 may generate one or more of the following assertions for each product serial ID: Product Assertion: Hash (concatenated information of the underlying asset assertion) + Serial Number. · Product Ownership Assertion: Product Assertion+ORHID. · Market Assertions: Product Assertions + Market Metadata.

[0094] Once an assertion is inserted into TIDAL 106, the TRM service 402 may decrement the remaining supply of the underlying asset in the asset table in DB 108 by the total number of copies of the product. A new product entry may be inserted into the product table in DB 108 with the associated product information. The task entry may be updated with a status of "completed" and a product ID. In various embodiments, one or more steps of an assertion creation process consistent with various aspects of the disclosed embodiments may be implemented as an asynchronous task.

[0095] In some embodiments, an indication of a successful upload of the digital asset may be communicated from the TRM 402 to the marketplace service 102 and / or the ORH 400.

[0096] Download Phase 6A-6D illustrate a non-limiting example of a download process consistent with certain embodiments disclosed herein.

[0097] Step 1.1-1.2: Log in In some embodiments, the consumer 114 may log into the marketplace service 102. In one particular embodiment, a Google account (e.g., Open ID connect) may be used for logging in, although other methods of logging in may also be employed. The marketplace service 102 may authenticate the consumer 114 and, if authentication is successful, issue an authentication token to the consumer.

[0098] Steps 1.3-1.9: Get a verified Marketplace product The marketplace service 102 may fetch products using the TIP service 104 DV service. In some embodiments, the marketplace service 102 may use a TIP access token to access the TIP service 104 DV service. A query (e.g., an SQL query) may be used to fetch the information. The query may include any filter, offset, and / or restriction parameters. The requested information may be returned from the DB 108 to the marketplace service 104 via the TRM service 402. Once the marketplace service 102 receives the data, the marketplace service 102 may validate the data on the DB 108 using a TRM validation API. For example, the marketplace service may send a list of product IDs to the TRM service 402 for validation. The TRM service 102 may generate a market assertion, check the assertion against the TIDAL 106, and return the validated product details to the marketplace service 102. The marketplace service 102 may display the verified products to the consumer 114, who may browse and purchase available digital products from the marketplace service 102. Depending on the business terms of the product, the consumer may have the right to purchase, rent, and / or subscribe to the product.

[0099] Steps 1.10-1.11: Create a transaction The marketplace service 102 may receive a request to purchase a product (e.g., for sale, for rental, etc.) from a consumer 114. The marketplace service 102 may make a request to the API of the TRM service 104 to record the transaction, which may include various details about the transaction along with the TIP access token of the marketplace service 102.

[0100] Steps 1.12-1.14: Verify the Marketplace The marketplace TIP access token may be verified via the IAM service of the TIP service 104. The marketplace ID may be obtained from the IAM service and / or another user information endpoint. The marketplace service 102 may then be verified as registered in DB 108 (e.g., the marketplace ID is present in the marketplace table because the marketplace table stores a list of verified marketplaces).

[0101] Steps 1.15-1.19: Create an assertion For the sale of a public or private product, the TRM service 402 may create a new product ownership assertion, which may include the product assertion and the identity of the new owner (e.g., the identity of the consumer 114). The TRM service 402 may register the new product ownership assertion with TIDAL 106. In some embodiments, the previous product ownership assertion in TIDAL 106 may be set to false to reflect the update of the ownership of the product. For the rental or subscription of a private product, the TRM service 402 may create a rights assertion, which may include the product assertion, an indication of the transaction process, business terms, and the consumer identity. The rights assertion may be signed by the TRM service 402, which may register the rights assertion with TIDAL 106. Consistent with various embodiments disclosed herein, the ingestion policy of TIDAL may be configured to accept assertions signed by the TRM service 402. The TRM service 402 may use the rights assertion for validation purposes for rental and / or subscription of private digital assets.

[0102] Steps 1.20-1.22: Update the DB A transaction ID may be generated (e.g., as a UUID) and the data may be recorded in a transaction table in DB 108. If a product is purchased, the product owner ID may also be updated in the product table in DB 108.

[0103] Steps 1.24-1.28: Payment Processing The marketplace service 102 may redirect the consumer 114 to a third-party secure payment gateway 112 (e.g., PayPal). The consumer 114 may select a payment method, and after successful payment, the marketplace service 102 may distribute the payment to the respective owners (e.g., owners 100) according to any applicable business agreements.

[0104] For example, as illustrated in FIGURE 6D, the marketplace service 102 may call an API of the payment gateway service 112. The payment gateway service 112 may respond to the marketplace service 102 with one or more available payment options. The consumer 114 may select a suitable payment method supported by the marketplace service 102, such as, for example and without limitation, credit and / or debit card payment, PayPal, etc. The consumer 114 may confirm payment details with the marketplace service 102.

[0105] The marketplace service 102 may call the API of the payment gateway service 112 with the requested order information and may receive an indication from the payment gateway service 112 indicating a successful payment by the consumer 114. The marketplace service 102 may indicate to the consumer 114 that the payment was successful. After the payment is successful, the marketplace service 102 may receive the amount from the consumer 114. The marketplace service 102 may then distribute the payment to the respective owners 100 according to one or more applicable business agreements.

[0106] In-product asset regeneration 7A-7C illustrate a non-limiting example of an asset reclamation process consistent with certain embodiments disclosed herein.

[0107] Steps 2.1-2.2: Request playback When a consumer 114 opens a link to access a product and initiates a request to access a digital asset within the product, the marketplace service 102 may send a validation request to the TRM service 402. The request may include, for example, and without limitation, a TIP access token (e.g., a marketplace TRM access token), a product serial ID, an asset ID, and / or a consumer ID.

[0108] Steps 2.3-2.5: Verify the Marketplace The marketplace TIP access token included in the access request may be verified via the IAM service of the TIP service 104. The marketplace ID may be obtained from the IAM service and / or another user information endpoint. The marketplace service 102 may then be verified as registered in DB 108 (e.g., the marketplace ID is present in the marketplace table because the marketplace table stores a list of verified marketplaces).

[0109] Steps 2.6-2.9: Check if the user is an ORH of the asset The product and / or asset data may be retrieved from product and asset tables, respectively, contained in DB 108. A corresponding asset ownership assertion may be generated by TRM 402 and checked against TIDAL 106. For example, if the ORH ID of the asset matches the consumer ID, the consumer may be permitted to play the content until the asset ownership assertion is verified with TIDAL 106. However, if the remaining supply of the asset is 0, the ORH may not be permitted to play the asset since a copy of the asset may currently be bundled with a product (if the ORH owns any of these products, the ORH may still be able to play the asset since these checks may be performed in a subsequent step).

[0110] Steps 2.10-2.13: Check if the user is entitled to the product Transaction data associated with the consumer 114 and / or product may be retrieved from the DB 108 and provided to the TRM service 402. The TRM service 402 may generate associated rights assertions and verify the rights assertions against the TIDAL 106.

[0111] For example, and without limitation, if the product type is "public," the consumer may be allowed to play the assets within the product. However, if the product type is "private," the TRM service 402 may check whether the consumer ID matches the product's owner ID. If the consumer ID matches the product's owner ID, the consumer 114 is allowed to play the assets until the product ownership assertion is verified in TIDAL 106.

[0112] The TRM service 402 may further check whether the consumer ID is in the invitee column of the product table. If the consumer ID is in the invitee column of the product table, the consumer 114 may be allowed to play the asset until the product invitee assertion is verified in TIDAL 106.

[0113] In addition, the TRM service 402 may check whether there is a valid transaction that allows the consumer 114 to access the product in a transaction table in the DB 108. If a valid transaction exists, the consumer may be allowed to play the asset until the rights assertion is verified in the TIDAL 106.

[0114] Steps 2.14-2.18: Prepare assets for playback For DRM applications (e.g., audio content, video content, etc.), the TRM service 402 may retrieve the KEK stored in the TIP vault and the KID from the asset table. The TRM service 402 may call a DRM service API associated with the KMS 404 to issue a token for a DRM license by providing the KEK and the KID. Once a DRM token is issued by the DRM service's KMS 404, the TRM service 402 may deliver the token and a file location URL (e.g., from the asset table) to the marketplace service 102. The marketplace service 102 may fetch the data from the file storage 110 and initiate DRM playback of the digital asset to the consumer 114 (e.g., via a media player application that integrates DRM functionality).

[0115] In the non-DRM case, the TRM service 402 may retrieve its private key from the TIP vault and retrieve the encrypted content key from the asset table. The TRM service 402 may decrypt the encrypted content key with the TRM service's 402 private key. The TRM service 402 may retrieve the encrypted digital asset from the file storage 110 and decrypt the digital asset with the content key. The TRM service 402 may make the decrypted digital asset available to the marketplace service 102, where it may be accessed by the consumer 114.

[0116] Update / Delist Phase Asset Update 8A-8C illustrate a non-limiting example of an asset update process consistent with certain embodiments disclosed herein.

[0117] Step 1.1-1.2: Log in In some embodiments, the ORH 400 may log into the marketplace service 102. In one particular embodiment, a Google account (e.g., Open ID connect) may be used for logging in, although other methods of logging in may also be employed. The marketplace service 102 may authenticate the ORH 400 and, if authentication is successful, issue an authentication token to the consumer.

[0118] Steps 1.3-1.6: Asset Update Request The marketplace service 102 may use its marketplace TIP access token to retrieve the list of assets uploaded by the ORH 400 from the asset physics dataset in the TIP service 104. The ORH 400 may select an asset from the list of assets and update its estimated metadata. For example, the ORH 400 may update the title and / or preview information included in the asset metadata. In some embodiments, the asset file and / or its associated supply may not be updated (although certain implementations may allow for such updates). The marketplace service 102 may send a request to the TRM service 402 including the updated asset metadata, asset ID, and / or user ID along with the TRM service's 402 TIP access token.

[0119] Steps 1.7-1.9: Verify the Marketplace The marketplace TIP access token may be verified via the IAM service of the TIP service 104. The marketplace ID may be obtained from the IAM service and / or another user information endpoint. The marketplace service 102 may then be verified as registered in DB 108 (e.g., the marketplace ID is present in the marketplace table because the marketplace table stores a list of verified marketplaces).

[0120] Steps 1.10-1.13: Verify asset ownership The asset data may be retrieved from DB 108 using, for example, an asset ID and / or a marketplace ID. An asset ownership assertion may be generated using the provided user ID and checked against TIDAL 106. If the asset ownership assertion is not verified by TIDAL 106, the asset update request may be rejected by the TRM service 402.

[0121] Step 1.14: Validate assets that are not bundled with the product The TRM service 402 may check if the remaining supply of the asset is less than the initial supply of the asset. This may be a proxy to check if the asset is bundled with any product. If the asset is bundled with a product that may already be sold, the ORH 400 may not be allowed to update the asset metadata since the owner of such product has purchased the product with the original asset metadata. Thus, if the remaining supply of the asset is less than the initial supply of the asset, the update operation may be rejected.

[0122] Steps 1.15-1.18: Update assets If a preview file is provided as part of the update, the preview file may be updated in file storage 110. The asset metadata and preview file URL may be updated in the asset table in DB 108. In some embodiments, an indication of a successful upload of the digital asset may be communicated from the TRM 402 to the marketplace service 102 and / or the ORH 400.

[0123] Product updates In some implementations, certain assets may be limited in their ability to be updated. For example, in certain embodiments, assets bundled with a product may not be updated, nor may the number of copies available be updated. For some business metadata (e.g., business terms, sale price, rental price, etc.), product type (e.g., public / private), product metadata (e.g., title, description, etc.), and / or preview files may be updated for all copies of the product owned by the owner 100 making the update request. Figures 9A-9C illustrate non-limiting examples of a product update process consistent with certain embodiments disclosed herein.

[0124] Steps 2.1-2.2: Log in In some embodiments, the owner 100 may log into the marketplace service 102. In one particular embodiment, a Google account (e.g., Open ID connect) may be used for logging in, although other methods of logging in may also be employed. The marketplace service 102 may authenticate the owner 100 and, if authentication is successful, issue an authentication token to the consumer.

[0125] Steps 2.3-2.6: Product Update Request The marketplace service 102 may use the marketplace TIP access token of the TIP service 104 to retrieve a list of products owned by the owner 100 from the product physical dataset in the TIP service 104. The owner 100 may select one product from the list of products and update the product. For example, the owner 100 may update product metadata (e.g., title, description, etc.), preview, asset type, business metadata (e.g., business terms, sale price, rental price and / or duration, subscription price and / or duration, rental price and / or duration of ownership, etc.). In a particular embodiment, the assets bundled with the product may not be updated, and the number of copies may not be updated, although other alternative implementations are contemplated. The marketplace service 102 may send a request to the TRM service 402 including the updated fields, product ID, owner ID, along with the TIP access token of the TRM service 402.

[0126] Steps 2.7-2.9: Verify the Marketplace The marketplace TIP access token included in the product creation request may be verified via the IAM service of the TIP service 104. The marketplace ID may be obtained from the IAM service and / or another user information endpoint. The marketplace service 102 may then be verified as registered in DB 108 (e.g., the marketplace ID is present in the marketplace table because the marketplace table stores a list of verified marketplaces).

[0127] Step 2.10: Start the update process In some embodiments, a task entry may be created in the task table with a status of "in progress" and a product ID.

[0128] Steps 2.11 - 2.19: Process product updates In various embodiments, one or more steps of the product update process may be implemented as an asynchronous task. Product data corresponding to the product ID and owner ID may be retrieved from a product table in DB 108. For each such product serial ID, a product ownership assertion may be generated and verified with TIDAL 106. If one or more product ownership assertions are not verified, the product update operation may be rejected. An old market assertion (e.g., product assertion + original market metadata) may be generated and set to false in TIDAL 106. A new market assertion (e.g., product assertion + new market metadata) may be generated. The new market assertion may be inserted into TIDAL 106. If a preview file is provided by the owner 100, the preview may be updated in the file storage service 110. The product data and preview may be updated in DB 108 and the task entry may be set to "completed."

[0129] In some embodiments, an indication of a successful upload of the digital asset may be communicated from the TRM 402 to the marketplace service 102 and / or the owner 100.

[0130] Remove a product from the list 10A-10B illustrate a non-limiting example of a product de-listing process consistent with certain embodiments disclosed herein.

[0131] Steps 3.1-3.2: Log in In some embodiments, the owner 100 may log into the marketplace service 102. In one particular embodiment, a Google account (e.g., Open ID connect) may be used for logging in, although other methods of logging in may also be employed. The marketplace service 102 may authenticate the owner 100 and, if authentication is successful, issue an authentication token to the consumer.

[0132] Steps 3.3-3.5: Remove product requests from the list The marketplace service 102 may use the marketplace TIP access token of the TIP service 104 to retrieve a list of products owned by the owner 100 from the product physical dataset in the TIP service 104. The owner 100 may select one product from the list of products. The owner 100 may remove the product from the list (e.g., set the remove list value to "1" for true) if the product is currently available on the marketplace service 100, and may relist the product on the marketplace service 102 (e.g., set the remove list value to "0" for false) if the product is not currently available on the marketplace service 100. The marketplace service 102 may send a request to the TRM service 402 including the updated remove list value, product ID, owner ID, along with the TIP access token of the TRM service 402.

[0133] Steps 3.6-3.8: Verify the Marketplace The marketplace TIP access token may be verified via the IAM service of the TIP service 104. The marketplace ID may be obtained from the IAM service and / or another user information endpoint. The marketplace service 102 may then be verified as registered in DB 108 (e.g., the marketplace ID is present in the marketplace table because the marketplace table stores a list of verified marketplaces).

[0134] Step 3.9: Create a To Do Entry A task entry can be created in a task table in DB 108 with a status of "in progress" and a product ID.

[0135] Steps 3.10-3.12: Validate product ownership In various embodiments, one or more steps of the product ownership verification process may be implemented as an asynchronous task. The TRM service 104 may search for an entry in a product table in DB 108 that corresponds to the specified product ID and / or owner ID. The TRM service 104 may generate a product ownership assertion for the specified owner ID and verify the generated assertion with TIDAL 106. If any of the product ownership assertions are not verified, the TRM service 402 may reject the delisting request.

[0136] Steps 3.13-3.15: Update your product The delisting property of the corresponding entry in the products table in DB 108 may be updated to the specified delisting value and the task entry may be set to "Completed." In some embodiments, an indication that the delisting was successful may be communicated from the TRM 402 to the marketplace service 102 and / or the owner 100.

[0137] Deletion Phase Delete an asset 11A and 11B illustrate a non-limiting example of an asset deletion process consistent with certain embodiments disclosed herein. In one particular embodiment, an ORH 400 that creates an asset may delete it unless the asset is bundled into an existing product.

[0138] Step 1.1-1.2: Log in In some embodiments, the ORH 400 may log into the marketplace service 102. In one particular embodiment, a Google account (e.g., Open ID connect) may be used for logging in, although other methods of logging in may also be employed. The marketplace service 102 may authenticate the ORH 400 and, if authentication is successful, issue an authentication token to the consumer.

[0139] Steps 1.3-1.5: Asset deletion request The marketplace service 102 may use the marketplace TIP access token of the TIP service 104 to retrieve the list of assets uploaded by the ORH 400 from the asset physical dataset in the TIP service 104. The ORH 400 may select one asset from the list of assets to delete. The marketplace service 102 may send a delete request to the TRM service 104 with the asset ID, the ORH ID, along with the TIP access token of the TRM service 104.

[0140] Steps 1.6-1.8: Verify the Marketplace The marketplace TIP access token included in the product creation request may be verified via the IAM service of the TIP service 104. The marketplace ID may be obtained from the IAM service and / or another user information endpoint. The marketplace service 102 may then be verified as registered in DB 108 (e.g., the marketplace ID is present in the marketplace table because the marketplace table stores a list of verified marketplaces).

[0141] Steps 1.9-1.11: Verify asset ownership The asset data may be retrieved from an asset table in DB 108. An asset ownership assertion may be generated using the provided ORH ID. If the asset ownership assertion is not verified by TIDAL 106, in some implementations the asset deletion request may be rejected by the TRM service 104 since only the ORH 400 may delete the asset.

[0142] Step 1.12: Validate that the asset is not also bundled in a product The TRM service 402 may check if the remaining supply of the asset is less than the initial supply of the asset. This may be a proxy to check if the asset is bundled with any product. If the asset is bundled with a product that may already be sold, the ORH 400 may not be allowed to delete the asset. Thus, if the remaining supply of the asset is less than the initial supply of the asset, the delete operation may be denied.

[0143] Steps 1.13-1.17: Delete assets The TRM service 104 may set the asset and asset ownership assertions to false in TIDAL 106. The encrypted digital asset file and the preview file may be deleted from the file storage service 110. Finally, the asset may be deleted from the asset table and the associated task may be deleted from the task table in the TB 108. In some embodiments, an indication of a successful delisting may be communicated from the ORH 400 to the marketplace service 102 and / or the owner 100.

[0144] Remove Products 12A and 12B illustrate a non-limiting example of an asset unbundling process consistent with certain embodiments disclosed herein. In certain embodiments, deleting a product may unbundle assets bundled within that product. For example, the supply of each asset bundled with the product being deleted may be incremented by the total supply of the product. In some implementations, deleting a product may be limited to ORHs 400 that created the product and own a copy of the product.

[0145] Steps 2.1-2.2: Log in In some embodiments, the ORH 400 may log into the marketplace service 102. In one particular embodiment, a Google account (e.g., Open ID connect) may be used for logging in, although other methods of logging in may also be employed. The marketplace service 102 may authenticate the ORH 400 and, if authentication is successful, issue an authentication token to the consumer.

[0146] Steps 2.3-2.5: Product removal request The marketplace service 102 may use the marketplace TIP access token of the TIP service 104 to search the list of products created by the ORH 400 from the product physical dataset in the TIP service 104. The ORH 400 may select and delete at least one product from the list of products. The ORH 400 may decide to delete one of the products uploaded to the marketplace service 102. The marketplace service 102 may send a request to the TRM service 104 including the product ID, the ORH ID, along with the marketplace TIP access token.

[0147] Steps 2.6-2.8: Verify the Marketplace The marketplace TIP access token may be verified via the IAM service of the TIP service 104. The marketplace ID may be obtained from the IAM service and / or another user information endpoint. The marketplace service 102 may then be verified as registered in DB 108 (e.g., the marketplace ID is present in the marketplace table because the marketplace table stores a list of verified marketplaces).

[0148] Step 2.9: Create a To Do Entry A task entry may be created in a task table in DB 108 with a status of "in progress" and a product ID.

[0149] Steps 2.10-2.14: Validate the ORH In various embodiments, one or more steps of the ORH validation and / or product deletion process may be implemented as asynchronous tasks. The TRM service 402 may search DB 108 for an entry in the product table that corresponds to the specified product ID. If the ORH ID of the product entry does not match the supplied ORH ID, the operation may be denied. If the owner ID of any product entry does not match the supplied ORH ID, the operation may be denied. In some embodiments, the ORH 400 may be required to own all copies of the product to be deleted, although other implementations are contemplated in which this is not the case.

[0150] A product ownership assertion may be generated by the TRM service 402 for each product serial ID and checked against TIDAL 106. If any of the product ownership assertions are not verified by TIDAL 106, the deletion request may be denied.

[0151] Steps 2.15-2.19: Remove the product A product assertion, product ownership assertion, and market assertion may be generated for each product serial ID and set to false in TIDAL 106. The remaining supply of each underlying asset in the product may be incremented in DB 108 by the total number of copies of the product being deleted. The asset table may be updated in DB 108 to reflect the new remaining supply count of the underlying asset. The state of the entry in the task table in DB 108 may be set to "deleted" and the deleted value in the product table in DB 108 for the product entry may be changed to true.

[0152] In some embodiments, an indication of successful removal may be communicated from the ORH 400 to the marketplace service 102 and / or the owner 100.

[0153] Invite / Uninvite a friend about a product Recruitment Process 13A-13C illustrate a non-limiting example of a product solicitation process consistent with certain embodiments disclosed herein.

[0154] Step 1.1-1.2: Log in In some embodiments, the owner 100 may log into the marketplace service 102. In one particular embodiment, a Google account (e.g., Open ID connect) may be used for logging in, although other methods of logging in may also be employed. The marketplace service 102 may authenticate the owner 100 and, if authentication is successful, issue an authentication token to the owner 100.

[0155] Steps 1.3-1.7: Invite friends to use your product The marketplace service may use the marketplace TIP access token of the TIP service 104 to retrieve a list of products owned by the owner 100 from the product physical dataset in the TIP service 104. The owner 100 may select a product from the list of products to invite another user, who may be generally referred to herein as a "friend," to use. The owner 100 may add the friend's email address to invite the friend to access the product. The marketplace service 102 may check whether the email address exists in the marketplace user table and may look up the associated user ID. If the email address does not exist in the marketplace user table, the marketplace service 102 may reject the request. The marketplace service 102 may send a request to the TRM service 402 that includes the user ID, product ID, owner ID, along with the TIP access token of the TRM service 402.

[0156] Steps 1.8-1.10: Verify the Marketplace The marketplace TIP access token may be verified via the IAM service of the TIP service 104. The marketplace ID may be obtained from the IAM service and / or another user information endpoint. The marketplace service 102 may then be verified as registered in DB 108 (e.g., the marketplace ID is present in the marketplace table because the marketplace table stores a list of verified marketplaces).

[0157] Steps 1.11-1.17: Process product solicitation requests Product data corresponding to the product ID and / or owner ID may be retrieved from a product table in DB 108. For each such product serial ID, a product ownership assertion may be generated and verified using TIDAL 106. If one or more product ownership assertions are not verified, the product solicitation operation may be rejected. A. A product solicitation assertion (e.g., product ownership assertion + invitee ID) may be generated and inserted into TIDAL 106. The invitee ID may be added to an invitee column in the product table in DB 108. A success message may be communicated from the TRM service 402 to the marketplace service 102.

[0158] Steps 1.18-1.19: Generate links The marketplace service 102 may generate a link to access the asset and send it to the owner 100. The owner 100 may share the link with friends via email or any other suitable communication method. When someone clicks on the link, it may take them to a login screen for the marketplace service 102. After logging in, the person may play and / or view the asset.

[0159] Unsolicitation Process 14A and 14B illustrate a non-limiting example of a product solicitation revocation process consistent with certain embodiments disclosed herein.

[0160] Steps 2.1-2.2: Log in In some embodiments, the owner 100 may log into the marketplace service 102. In one particular embodiment, a Google account (e.g., Open ID connect) may be used for logging in, although other methods of logging in may also be employed. The marketplace service 102 may authenticate the owner 100 and, if authentication is successful, issue an authentication token to the consumer.

[0161] Steps 2.3-2.6: Uninviting a friend to your product The marketplace service 102 may use the TIP service's 104 marketplace TIP access token to retrieve a list of products owned by the owner 100 from the product physical dataset in the TIP service 104. The owner 100 may select a product from the list of products and update the product. The owner 100 may remove a friend's email address to uninvited the friend from accessing the product. The marketplace service 100 may send a request to the TRM service 402 with the updated user ID, product ID, owner ID, along with the TRM service's 402 TIP access token.

[0162] Steps 2.7-2.9: Verify the Marketplace The marketplace TIP access token may be verified via the IAM service of the TIP service 104. The marketplace ID may be obtained from the IAM service and / or another user information endpoint. The marketplace service 102 may then be verified as registered in DB 108 (e.g., the marketplace ID is present in the marketplace table because the marketplace table stores a list of verified marketplaces).

[0163] Steps 2.10-2.17: Process product unsolicitation requests Product data corresponding to the product ID, owner ID may be retrieved from the product table in DB 108. For each such product serial ID, a product ownership assertion may be generated and verified using TIDAL 106. If one or more product ownership assertions are not verified, the product invitation cancellation operation may be rejected. A product invitation assertion (e.g., product ownership assertion + invitee ID) may be generated, falsed, and registered in TIDAL 106. The invitee ID may be removed from the invitee column in the product table in DB 108.

[0164] Token Entitlement Management Using Commercial Blockchain Ledgers Although various embodiments of the disclosed systems and methods are described in connection with applications implementing TIDAL and / or derived TIDAL, certain embodiments of the disclosed systems and methods may be used in connection with established blockchain ledgers and / or derivative ledgers of such ledgers, which may be used in connection with various other applications and / or users, entities, and / or parties. For example, certain non-limiting examples described herein may be used to manage tokens using the FLOW blockchain ledger. Although some examples are described as being used in connection with the FLOW blockchain ledger, it will be understood that various aspects of the disclosed systems and methods may be implemented in connection with a wide variety of blockchain ledgers.

[0165] As discussed above, embodiments of the disclosed system and method may enable rights binding and packaging and / or protection operations in connection with a particular NFT transaction (e.g., minting an NFT, transferring an NFT, etc.). For example, an uploaded asset (e.g., video, audio, etc.) may be encrypted with a unique key (e.g., a KID, which may be a unique key used for encryption and an identifier for the asset). The KID and terms of use may be bound to each other and recorded on a blockchain. For example, an asset token may bind a KID with an uploader's ID (e.g., ORH ID), a product token may bind a KID with an owner's ID (e.g., Owner ID) and other terms of use (e.g., expiration date, Invitee ID), and a rental token may bind a KID with a renter's ID (e.g., Borrower ID) and other terms of use (e.g., expiration date). In some implementations, an asset token may be used to bind a KID with an ORH ID and / or Owner ID. Ownership of an NFT can be transferred by checking expiration data in the product token (and / or asset token, depending on the implementation).

[0166] Various embodiments disclosed herein may support an ownership rental period. An ownership-rental period may be set by the ORH to limit how long a product may be made available for sale, rental, and / or playback in the marketplace. After this period, the product may no longer be available in the marketplace. In some embodiments, an ownership-rental period may be associated with a product token that allows for sale, rental, access solicitation, and / or playback for a specified period of time.

[0167] Further embodiments disclosed herein may provide a rights binding service. The rights binding service may use TIDAL and / or other blockchains to bind additional rights to the NFT. These rights may include DRM rights, and associated metadata may specify the DRM permissions. Further embodiments provide packaging and protection services. In traditional NFT platforms, the underlying content associated with the NFT is typically not part of the NFT. The packaging and protection service may take the original content and transform it to be consistent with the metadata in the NFT and provide various protections (e.g., encryption, authentication, and / or key management for keys that provide security).

[0168] In the FLOW blockchain ledger, objects such as fungible tokens ("FTs"), NFTs, and / or redemptions may be implemented as resources that may be stored within a user's account. In embodiments in which the FLOW ledger is used to implement various aspects of the disclosed token rights management systems and methods, resources may include, for example and without limitation, one or more of the following: Asset Token - An asset token may represent an NFT for an asset. An asset token may include several fields including, for example and without limitation, one or more of the following: (1) an asset token ID, which may be immutable and may include a unique identifier; (2) a serial number, which may be immutable and may include a unique serial number for different copies of the asset; (3) an asset type, which may be mutable and may be either "private" or "public"; (4) a URL, which may be immutable and may include one or more URLs associated with the asset file (e.g., an encrypted asset file); and (5) a KID, which may be immutable and may include a KID for a DRM management system (e.g., ExpressPlay). Rental Token - A rental token may represent an NFT for renting an asset, allowing the owner of the asset to play the content of the rental asset before an expiration timestamp. The rental token may include several fields including, for example and without limitation, one or more of the following: (1) a rental token ID, which may be immutable and may include a unique identifier; (2) an asset token ID, which may be immutable and may include an asset token ID for the asset being rented; (3) a URL (e.g., encrypted asset file), which may be immutable and may include one or more URLs associated with the asset file; (4) a KID (e.g., ExpressPlay), which may be immutable and may include a KID for a DRM management system; and (5) an expiration timestamp, which may be immutable and may include a timestamp after which the rental token becomes invalid for playing the content. The expiration timestamp may be initialized to the current data plus the rental period. Asset redemption - Asset redemption may include the redemption of owned asset tokens. Rental Recovery - Rental recovery may include the recovery of owned rental tokens. · Revenue Collection - Revenue Collection may include resources used to track asset tokens available for sale and rental. Revenue Collection may track asset prices and allow owners to view, delist, and / or update listings. Purchase and rental transactions may be enabled via revenue collection. Discounts for each sale / rental transaction may be sent to the administrator's cryptocurrency vault and / or digital wallet (e.g., using fiat-backed stable coins issued as fungible tokens on the FLOW network, such as FUSD). In some embodiments, the specific discount percentage (e.g., 5%) may be updated by the administrator at any time. Alternatively and / or in combination, the logic may accommodate separate discounts for the marketplace and the TRM administrator. It will be appreciated that in further embodiments, various other discount percentages may be offered to various and / or multiple parties. The content of the URLs in the asset tokens and rental tokens may depend on the implementation. For example, and without limitation, the content may include: (1) a link to an asset in a file system protocol (e.g., the Interplanetary File System ("IPFS"), (2) a link to a JSON file that contains a copy of the asset in IPFS, and / or (3) one or more links to a manifest file (e.g., DASH, HLS, etc.).

[0169] Asset Creation 15A-15F illustrate a non-limiting example of an asset creation process using a blockchain ledger consistent with certain embodiments disclosed herein. In various embodiments, the FLOW blockchain ledger may be used, although it will be understood that embodiments of the disclosed systems and methods may be used in connection with a variety of other blockchain ledgers.

[0170] In various embodiments, a wallet service 1500 (e.g., a cryptocurrency wallet) and a blockchain ledger 1502 may be used in connection with various embodiments of the disclosed systems and methods and may be conceptually included in the blockchain functionality of the disclosed ecosystem. The packaging functionality within the disclosed ecosystem may, in some embodiments, comprise a storage service 1502, a media packager 1506, and a distributed event store and / or stream processing platform such as Kafka 1508. The TRM system functionality may be implemented using an orchestrator service 110, a TIP IAM and / or data service ("DS") 1512, and a blockchain connector service 1514. A secure DB 1516 may also be used to store and / or manage various tables and / or other values. Various interactions between these systems and / or services are described in more detail below.

[0171] Steps 1.1-1.3: User Login The ORH 400 may log into the wallet service 1500 through the marketplace service 102. In the FLOW blockchain, the marketplace service 102 may authenticate the ORH 400 with the wallet service 1500 using the FLOW Client Library ("FCL"). The FCL may comprise a JavaScript client library that allows applications to integrate with FCL compatible wallets (e.g., Blocto, Ledger, Dapper wallet, etc.). The marketplace service 102 may obtain details about the ORH account such as the wallet ID after authentication. The marketplace service may check if the wallet ID matches the ORH wallet ID registered in the marketplace service 102.

[0172] Steps 1.4-1.5: Upload your assets to the Marketplace The ORH 400 may upload asset content (e.g., images, video, text, audio, etc.) in the marketplace service 102 and may specify one or more of the following for the asset: (1) the number of copies of the asset to mint, (2) the title of the asset, (3) a preview file (e.g., thumbnail), (4) an asset type, which may include a public asset where any consumer may access (e.g., view and / or listen to) the asset, or a private asset where a consumer may access (e.g., view or listen to) the asset after purchasing a transaction (e.g., buy, rent, etc.), and (5) a description and / or any other metadata associated with the asset that may be defined by the marketplace service. The ORH 400 may also upload a preview file to act as a thumbnail for the asset on the marketplace service 102 portal.

[0173] Steps 1.6-1.8: Upload asset media content to the Package feature The marketplace service 102 may upload asset (e.g., images, videos, music) content to a storage service 1504 (e.g., AWS S3) and may receive a URL and a transaction ID. For certain content (e.g., audio and / or video), the marketplace service 102 may subscribe to a Kafka service 1508, which may notify the media packager service 1506 when the digital asset content is uploaded and if there are any updates to the digital asset content.

[0174] Steps 1.9-1.11: Upload assets to TRM The marketplace service 102 may obtain an access token from the TIP IAM service 1512 service using the TIP IAM service 1512 API key and secret. The marketplace service 102 may provide an asset upload request to the orchestrator service 1510, which may include one or more of the following: (1) the ORH wallet ID, (2) information set by the ORH 400 described above (e.g., number of copies of the asset, asset title, preview file, asset type, etc.), and (3) the access token, and (4) the transaction ID.

[0175] Steps 1.12-1.16: Verify the marketplace and create a task entry The orchestrator service 1510 may validate the marketplace access token with the TIP IAM service 1512. The marketplace group information may be provided to the orchestrator service 1510 from the TIP IAM service 1512. The orchestrator service 1510 may validate whether the marketplace service 102 is a member of the marketplace group. A task entry may be created by the orchestrator service 1510 in a task table with a status of "in progress" in the secure DB 1516 while the asset encryption process is taking place in the package function services 1505-1508. The orchestrator service 1510 may then send a receipt confirmation message to the marketplace service 102 and / or the ORH 400.

[0176] Step 1.171.21 (asynchronous task): Package asset content and generate KID, facts For certain content (e.g., video and / or audio content), the Kafka service 1508 may notify the media packager service 1506 when the asset finishes uploading. The media packager service 1506 may encrypt the content file and store the encrypted asset content on a file storage service 1504 (e.g., S3), and the media packager service 1506 may then return the KID, URL(*), and transaction ID to the orchestrator service 1510. In some embodiments, the orchestrator service 1510 may use the transaction ID to correlate the KID and URL and / or ORH ID and / or other information set by the ORH 400.

[0177] To protect the content, a private key may be obtained from the TIP service vault. A new private key may be generated and stored in the TIP service vault if one does not already exist. A content key may be generated and the asset file may be encrypted using the content key. The encrypted asset may be stored by the file storage service 1504. The content key may be encrypted using the private key. An entry may be created in an asset table containing the asset information in DB 1516. The entry may be updated in the task table and the status may be set to "completed". The asset ID may also be updated in the task table of DB 1516.

[0178] The orchestrator service 1510 may generate an asset fact. The asset fact may include one or more of an owner ID (e.g., ORH wallet ID), an asset type, a KID, a URL, and / or a serial number. The contents of the URL may depend on the implementation and may include, for example, and without limitation, one or more of a link to the asset in IPFS, a link to a JSON that may contain a copy of the asset in IPFS, one or more links to a manifest file (e.g., DASH, HLS), etc.

[0179] Steps 1.22-1.25 (asynchronous tasks): Initiate asset token creation The orchestrator service 1510 may provide the asset facts to the blockchain connector service 1514 to initiate asset token creation with the blockchain 1512, which may include the FLOW blockchain. The blockchain connector service 1514 may retrieve blockchain credentials (e.g., private key) from the TIP service vault. A transaction requesting minting of the asset token may be generated by the blockchain connector service. The transaction may be signed with the private key as the proposer and payer. The blockchain connector service may send the signed transaction to the blockchain 1514 (e.g., via the orchestrator service 1510). For example, in some embodiments, the blockchain connector service 1510 may invoke a mintNFT function in a smart contract in the FLOW blockchain by providing the signed transaction.

[0180] Step 1.26 (asynchronous task): Mint asset tokens Once the signed transaction is provided, the smart contract may transfer the newly minted asset token to the ORH's blockchain account storage. The remaining objects may be stored in the asset fact as metadata. The minted asset token may be configured to make the asset token ID, KID, URL, and / or serial number immutable (e.g., read-only), such that specific values ​​may be securely bound to the asset token and the owner of the asset token is identified with the owner wallet ID and / or ORH wallet ID. These boundary values ​​may include, for example and without limitation, one or more of the asset token ID, which may be immutable, and metadata, which may include one or more of the asset type, the KID, which may be immutable, the URL, and / or the serial number, which may be immutable.

[0181] Steps 1.27-1.29 (asynchronous tasks): Create an asset entry The blockchain connector service 1514 may receive the updated asset token minting result by polling the blockchain 1512 and confirm the update by the orchestrator service 1510. Upon receiving the result, the blockchain connector service 1514 may create a new entry in the asset table in DB 1516 with all the newly created asset information. The task entry in the task table may be changed to a status of "completed" in DB 1516. After the update is successful, the marketplace service 102 may fetch the asset detail information from DB 1516. In some implementations, after minting the asset token, the asset may not be listed on the marketplace service 102 until the ORH 400 updates the asset and lists the asset for the marketplace service 102.

[0182] Step 1.30: Delete the original asset content files The marketplace service 102 may delete the originally uploaded asset content file in the file storage (e.g., AWS S3 storage).

[0183] Update an asset 16A-16C illustrate a non-limiting example of an asset update process using a blockchain ledger consistent with certain embodiments disclosed herein.

[0184] Step 1.1~1.2: User login The owner 100 may log into the wallet service 1500 via the marketplace service 102. In the FLOW blockchain, the marketplace service 102 may authenticate the owner 100 with the wallet service 1500 using the FCL. After authentication, the marketplace service 102 may obtain details about the owner account corresponding to the owner 100, such as the wallet ID.

[0185] Steps 1.3-1.6: Search for asset information The marketplace service 102 can use the TIP IAM service 1512 API key and secret to obtain an access token from the TIP IAM service 1512. The marketplace service 102 can use the TIP DS service 1512 access token to fetch a list of assets created by the owner 100 from the DB 1516 via the TIP DS service 1512.

[0186] Steps 1.7-1.8: Request an asset update The owner 100 may select an asset from the list and choose to update the owner's asset information by sending an associated request to the marketplace service 102. For example, and without limitation, the owner 100 may update one or more of the following: ·title Asset Type - Asset types can be public, where any consumer can access (e.g., view and / or listen to) the asset, or private, where a consumer can access (e.g., view and / or listen to) the asset after completing a purchase transaction (e.g., buy, rent, etc.). Business Terms - The business terms may include, for example and without limitation, one or more of sale and / or rental. If sale and / or rental is selected as the business terms, the asset may be listed in the marketplace service 102 after updating the asset. If neither sale and / or rental is selected as the business terms, the asset may be removed from the listing in the marketplace service after updating the asset. · Rental Period - This may be set if the business terms include "rental". Price - Price may include, for example and without limitation, price for sale, price for rental, etc. A description and / or any other metadata defined by the marketplace service 102.

[0187] The marketplace service 102 may send the updated information to the orchestrator service 1510 along with the owner wallet ID, asset token, ID, and / or access token.

[0188] Steps 1.9-1.11: Verify the Marketplace The orchestrator service 1510 may validate the marketplace access token using the TIP IAM service 1512. The marketplace group information may be obtained by the orchestrator service 1510 from the TIP IAM service 1512. The orchestrator service 1510 may validate whether the marketplace is a member of the marketplace group.

[0189] Step 1.12: Generate the update facts The orchestrator service 1510 may generate an update fact, which may be an object that includes one or more of the owner wallet ID, the access token ID, and / or the update data.

[0190] Steps 1.13-1.15: Start asset update The orchestrator service 1510 may provide the update facts to the blockchain connector service 1514 to initiate the asset update in the blockchain 1502. The blockchain connector service 1514 may generate a transaction requesting an update to the asset token and / or proceeds. The blockchain connector service 1514 may then send the transaction to the marketplace service 102 via the orchestrator service 1510.

[0191] Steps 1.16-1.20: Update assets on the blockchain The marketplace may request the owner 100 to sign the transaction via the wallet service 1500. Once the owner 100 confirms the transaction, the wallet service 1500 may sign the transaction with the owner's signing key. The wallet service may send the signed transaction to the blockchain 1502. Given the signed transaction, the smart contract may update the asset tokens and / or sales collections in response to the update request.

[0192] Steps 1.21-1.23: Update asset entries The blockchain connector service 1514 may obtain the asset update result by polling the blockchain 1502. When the blockchain connector service 1514 gets the result, it may call the orchestrator service API and provide the transaction details information to the orchestrator service 1510. The orchestrator service 1510 may store the updated result in the DB 1516. The blockchain 1502 may send a success message to the wallet service 1500, which may then send a success message to the marketplace service 102 and / or the owner 100.

[0193] Sell ​​assets 17A and 17B illustrate a non-limiting example of an asset purchasing process using a blockchain ledger consistent with certain embodiments disclosed herein.

[0194] Steps 1.1-1.4: Find asset information The marketplace service 102 can obtain an access token from the TIP IAM service 1512 using the TIP IAM service 1512 API key and secret. The list of listed assets can be fetched by the marketplace service 102 from the TIP DS service 1512 dataset using the TIP DS service 1512 access token.

[0195] Steps 1.5-1.6: User login A buyer 1700 may log into the wallet service 1500 via the marketplace service 102. In the FLOW blockchain, the marketplace service 102 may use the FCL to authenticate the buyer 1700 with the wallet service 1700. After authentication, the marketplace service may obtain details about the account associated with the buyer 1700, such as the wallet ID.

[0196] Steps 1.7-1.8: Request asset purchase The buyer 1700 may select an asset from the list and may purchase the asset. The marketplace service 102 may send the owner wallet ID, asset token ID, and / or access token for the asset to the orchestrator service 1510.

[0197] Steps 1.9-1.11: Verify the Marketplace The orchestrator service 1510 may validate the marketplace access token at the TIP IAM service 1512. The marketplace group information may be obtained by the orchestrator service 1510 from the TIP IAM service 1512. The orchestrator service 1510 may validate whether the marketplace service 102 is a member of the marketplace group.

[0198] Step 1.12: Generate purchasing facts The orchestrator service 1510 may generate a purchase fact, which may include one or more of an owner wallet ID and / or an asset token ID.

[0199] Steps 1.13-1.15: Start asset transfer The orchestrator may provide the purchase facts to the blockchain connector service 1514 to initiate the asset transfer in the blockchain 1502. The blockchain connector service 1514 may generate a transaction requesting the transfer of the asset token. The transaction may be sent by the blockchain connector service to the marketplace service 102 via the orchestrator service 1510.

[0200] Steps 1.16-1.21: Purchase assets on the blockchain The marketplace service 102 may request the buyer 1700 to sign the transaction via the wallet service 1500. Once the buyer confirms the transaction, the wallet service 1500 may sign the transaction using the buyer's signing key. The wallet service 1500 may send the signed transaction to the blockchain 1502. Given the signed transaction, the smart contract may transfer ownership of the asset token to the buyer 1700, update the owner's sale proceeds by removing the asset token ID, and initiate a payment (e.g., a payment in FUSD or some other cryptocurrency). In some embodiments, the custodian may receive a percentage of the transaction defined by a discount rate (e.g., 5% of the sale) and the owner may receive the remaining payment, although it will be understood that in further embodiments, various other discount rates may be offered to various parties.

[0201] Steps 1.22-1.24: Update asset entries The blockchain connector service 1514 may determine the asset transfer result by polling the blockchain 1502. When the blockchain connector gets the result, it may call the API of the orchestrator service 1510 and provide the transaction details information to the orchestrator service 1510. The orchestrator service 1510 may store the updated result in the DB 1516. The blockchain 1502 may send a success message to the wallet service 1500, which may send a success message to the marketplace service 102 and / or the buyer 1700.

[0202] Rent an asset 18A-18C illustrate a non-limiting example of an asset rental process using a blockchain ledger consistent with certain embodiments disclosed herein.

[0203] Steps 1.1-1.4: Find asset information The marketplace service 102 can use the TIP IAM service 1512 API key and secret to obtain an access token from the TIP IAM service 1512. The marketplace service 102 can use the TIP DS 1512 access token to fetch listed assets from the dataset in the TIP DS 1512.

[0204] Step 1.1~1.2: User login A borrower 1800 may log into the wallet service 1500 via the marketplace service 102. In the FLOW blockchain, the marketplace service 102 may use the FCL to authenticate the borrower 1800 with the wallet service 1500. After authentication, the marketplace service 102 may obtain details about the account associated with the borrower 1800, such as the wallet ID.

[0205] Steps 1.7-1.8: Request an asset rental The borrower 1800 may select an asset from the list, choose to rent the asset, and issue a request to the marketplace service 102. The marketplace service 102 may send the owner wallet ID, asset token ID, and access token for the asset to the orchestrator service 1510.

[0206] Steps 1.9-1.11: Verify the Marketplace The orchestrator service 1510 may validate the marketplace access token using the TIP IAM service 1512. The marketplace group information may be obtained by the orchestrator service 1510 from the TIP IAM service 1512. The orchestrator service 1510 may validate whether the marketplace service 102 is a member of the marketplace group.

[0207] Step 1.12: Generate rental facts The orchestrator service 102 may generate a rental fact, which may include one or more of an owner wallet ID and / or an asset token ID.

[0208] Steps 1.13-1.15: Start asset rental The orchestrator service 1510 may provide the generated rental facts to a blockchain connector service to initiate the minting of rental tokens in the blockchain 1502. The blockchain connector service 1510 may generate a transaction and send the transaction to the marketplace service 102 via the orchestrator service 1510.

[0209] Steps 1.16-1.21: Rent assets on the blockchain The marketplace service 102 may request the borrower 1800 to sign the transaction via the wallet service 1500. Once the borrower confirms the transaction, the wallet service 1500 may sign the transaction with the borrower's signing key. The wallet service may send the signed transaction to the blockchain 1502.

[0210] Once the signed transaction is provided, the smart contract may mint and transfer the rental tokens to the borrower's blockchain account storage. The smart contract may further initiate a payment (e.g., in a cryptocurrency such as FUSD). In some embodiments, the custodian may receive a percentage of the transaction defined by a discount rate (e.g., 5% of the sale) and the owner may receive the remaining payment, although it will be understood that in further embodiments, various other discount rates may be provided to various parties.

[0211] A minted rental token may be configured to make the rental token ID, asset token ID, KID, URL, and / or expiration date immutable (e.g., read-only) such that specific values ​​can be securely bound to a rental token owned by a borrower.

[0212] These boundary values ​​may include, for example, and without limitation, one or more of a rental token ID, which may be immutable, and metadata, which may include one or more of an asset token ID, which may be immutable, a KID, which may be immutable and / or may be the same KID as included in the asset token identified with the asset token ID, a URL, which may be immutable and / or may be the same URL as included in the asset token identified with the asset token ID, and / or an expiration date, which may be immutable and may be a date, after which the rental token becomes invalid for playback of asset content. In some embodiments, the expiration date may be initialized to the current date plus the rental period specified in the asset token.

[0213] Steps 1.22-1.24: Create a transaction entry The blockchain connector service 1514 may obtain the rental token minting result by polling the blockchain 1502 and share it with the orchestrator 1510. The orchestrator service 1510 may store the updated result in the DB 1516. The blockchain 1502 may send a success message to the wallet service 1500, which may then send a success message to the marketplace service 102 and / or the borrower 1800.

[0214] Regenerate assets 19A-19C illustrate a non-limiting example of an asset regeneration process using a blockchain ledger consistent with certain embodiments disclosed herein.

[0215] Steps 1.1-1.4: Find asset information The marketplace service 102 can obtain an access token from the TIP IAM service 1512 using the API key and secret of the TIP IAM service 1512. The list of assets can be fetched from the DB 1516 by the marketplace service 102 using the TIP DS service 1512 and its access token.

[0216] Steps 1.5-1.6: User login A consumer 1900 may log into the wallet service 1500 through the marketplace service 102. In the FLOW blockchain, the marketplace service 102 may authenticate the consumer 1900 with the wallet service 1500 using the FCL. After authentication, the marketplace service 102 may obtain details about the consumer account 1900, such as the wallet ID.

[0217] Steps 1.7-1.8: Request asset reclamation The consumer 1900 may select an asset from the list and may choose to play the asset by making a request to the marketplace service 102. The marketplace service 102 may send the consumer wallet ID, asset token ID, and / or access token for the asset to the orchestrator service 1510.

[0218] Steps 1.9-1.11: Verify the Marketplace The orchestrator service 1510 may validate the marketplace access token at the TIP IAM service 1512. The marketplace group information may be obtained by the orchestrator service 1510 from the TIP IAM service 1512. The orchestrator service 1510 may validate whether the marketplace service 102 is a member of the marketplace group.

[0219] Step 1.12: Start your evaluation The orchestrator service 1510 may provide the asset token ID and the consumer wallet ID to the blockchain connector service 1514 to initiate execution of the script.

[0220] Steps 1.14-1.15: Evaluate the use After initiation, the script may evaluate the use of the asset in the blockchain 1502. If the asset type is "public", the process may proceed to a "success" outcome. If the asset type is "private" and the consumer 1900 is the owner of the asset token, the process may proceed to a "success" outcome.

[0221] If the asset type is "private" and the consumer 1900 is not the owner of the asset token, a check may be performed to determine whether a rental token exists associated with the asset token and the consumer 1900. If a rental token does not exist associated with the asset token and the consumer 1900, the process may proceed to a "fail" outcome.

[0222] If there is a rental token associated with the asset token and consumer 1900, the expiration date may be checked in the rental token. If the expiration date has already passed at the current time, the process may proceed to a "failure" outcome. If the expiration date has not yet passed at the current time, the process may proceed to a "success" outcome.

[0223] Steps 1.16-1.17: Submit evaluation results If there is a “success” result, the KID and URL for the asset token may be sent from the blockchain 1502 to the blockchain connector service 1514, which may forward the KID and URL to the orchestrator service 1510.

[0224] Steps 1.18-1.24: Play assets If the orchestrator service 1510 receives a “success” result from the blockchain connector service 1514 along with the KID and / or URL, the orchestrator service 1510 may proceed to engage in a transaction, which in some embodiments may depend on the DRM implementation and / or use case. For example, in at least one DRM use case that may be used in implementations involving audio, image, and / or video content, the orchestrator service 1510 may search for a KEK stored in a TIP vault. The orchestrator service 1510 may call the KMS 404 via a DRM service API to issue a token for the DRM license by providing the KEK and the KID. The KMS 404 may verify the K from the KEK and the KID before issuing the DRM token. Once the token is issued by the KMS 404, the orchestrator service 1510 may return the token and the URL to the marketplace service 102. The marketplace service 102 may use a DRM client (e.g., KMS 404) to redeem the token from the DRM service, fetch the encrypted asset data by using a given URL, and initiate playback of the asset in a player application.

[0225] For non-DRM cases, the orchestrator service 1510 may retrieve the private key from the TIP vault and retrieve the encrypted content key from the asset table in DB 1516. The orchestrator service 1510 may decrypt the encrypted content key with the private key. The orchestrator service 1510 may retrieve the encrypted asset from a given URL and decrypt the asset with the content key. The orchestrator service 1510 may then make the decrypted asset available to the marketplace service 102, and the consumer 1900 may access the asset on the marketplace service 102.

[0226] 20 illustrates a flow diagram of a non-limiting example of a method 2000 for managing digital assets consistent with certain embodiments of the present disclosure. The illustrated method 2000 may be implemented in a variety of manners, including using software, firmware, hardware, and / or any combination thereof. In certain embodiments, various aspects of the method 2000 and / or constituent steps thereof may be performed by a service, system, and / or device configured to implement an embodiment of a TRM service (and / or associated services, such as a marketplace service, a TIP service, a TIDAL service, a DRM service, and / or a KMS service) and / or any other suitable application, device, system, and / or service, or combination of applications, devices, systems, and / or services.

[0227] At 2002, the TRM service may receive a DRM data access request from a marketplace service. In some embodiments, the TRM service may include a service of a TIP service. The DRM access request may include, among other things, a marketplace access token and / or an identifier associated with a user. In further embodiments, the DRM access request may further include an identifier associated with the digital asset and / or an identifier associated with a product that includes the digital asset. In some embodiments, the DRM access request may be issued by the marketplace service to the TRM service in response to receiving a user request to access the digital asset from a user associated with the identifier.

[0228] At 2004, asset information associated with the marketplace service may be obtained based on the marketplace access token included in the DRM access request. In some embodiments, the asset information may include, among other things, a hash of the digital asset.

[0229] In some embodiments, obtaining asset information associated with the marketplace service may include obtaining asset information from a DB associated with the TIP service. For example, in some embodiments, the marketplace service may be verified with the TIP service using a marketplace access token. Based on successful verification of the marketplace service, an indication may be received from the TIP service regarding an account identifier associated with the marketplace service, and the indication may be used to obtain asset information associated with the marketplace.

[0230] At 2006, an asset rights assertion may be generated based on a hash of the digital asset and an identifier associated with the user received in the DRM access request. The TRM service may perform a query at 2008 to query a trusted ledger for the asset rights assertion, which may include the TIDAL ledger and / or the blockchain ledger. If the asset rights assertion is recorded in the trusted ledger, it may be determined that the user has the right to access the digital asset. In some embodiments, it may be determined that the user is the owner of the digital asset. A check may be performed to determine if there are any remaining copies of the digital asset available for consumption and / or further management.

[0231] Based on the determination, a query may be issued to a DRM service at 2010. In some embodiments, the DRM service may include a KMS service (which in some implementations may be a TIP service). In various embodiments, the TRM service, marketplace service, TIP service, DRM service (and / or KMS service), and TIDAL may run on a single system and / or any suitable combination of systems.

[0232] The query to the DRM service may include a KID and / or a KEK, which may include a public encryption key associated with the user. In some embodiments, the KID and / or KEK may be accessed from a DB associated with the TIP service.

[0233] In response to the query, the DRM service may issue a DRM token at 2012. The DRM token may include an encrypted version of a content key that may be used to decrypt the digital asset. The DRM service may send the DRM token and the location (e.g., a URL) of the digital asset to the marketplace service at 2014 for communication to a system associated with the user.

[0234] System and / or Service Architecture Figure 21 illustrates a non-limiting example of a system 2100 that may be used to implement certain embodiments of the disclosed systems and methods. The system 2100 of Figure 21 and / or aspects thereof may be included in systems, services, and / or devices associated with an owner, an ORH, a consumer, a buyer, a borrower, a marketplace service, a TRM service, a TIP service, a TIDAL service and / or associated services, a DRM service and / or a KMS service, a DB, a file storage service, a payment gateway service, a wallet service, a blockchain service, a media packager service, an orchestrator service, a blockchain connector service, and / or any other service, which may include trusted services, systems, and / or components configured to implement embodiments of the disclosed systems and methods and / or aspects thereof.

[0235] Various systems and / or devices used in connection with aspects of the disclosed embodiments may be communicatively coupled using various networks and / or network connections (e.g., network 2112). In certain embodiments, network 2112 may include various network communication devices and / or channels and may utilize any suitable communication protocol and / or standard that facilitates communication between the systems and / or devices. Network 2112 may include the Internet, a local area network, a virtual private network, and / or any other communication network utilizing one or more electronic communication technologies and / or standards (e.g., Ethernet, etc.). In some embodiments, network 2112 may include a wireless carrier system, such as a personal communications system ("PCS"), and / or any other suitable communication system incorporating any suitable communication standard and / or protocol. In further embodiments, network 2112 may include analog mobile communications networks and / or digital mobile communications networks utilizing, for example, code division multiple access ("CDMA"), Global System for Mobile Communications or Groupe Special mobile ("GSM"), frequency division multiple access ("FDMA"), and / or time divisional multiple access ("TDMA") standards. In certain embodiments, network 2112 may incorporate one or more satellite communications links. In still further embodiments, network 2112 may utilize the IEEE 802.11 standard, Bluetooth, ultra-wide band ("UWB") Zigbee, and / or any other suitable standard or standards.

[0236] The various systems and / or devices used in connection with aspects of the disclosed embodiments may comprise a variety of computing devices and / or systems, including any computing system or systems suitable for implementing the systems and methods disclosed herein. For example, the connected devices and / or systems may include a variety of computing devices and systems, including laptop computer systems, desktop computer systems, server computer systems, distributed computer systems, smartphones, tablet computers, etc.

[0237] In certain embodiments, the systems and / or devices may comprise at least one processor system configured to execute instructions stored on an associated non-transitory computer-readable storage medium. As discussed in more detail below, systems used in connection with implementing various aspects of the disclosed embodiments may further comprise a secure processing unit ("SPU") configured to perform sensitive operations such as trusted credential and / or key management, cryptographic operations, secure policy management, and / or other aspects of the systems and methods disclosed herein. The systems and / or devices may further comprise software and / or hardware configured to enable electronic communication of information between the devices and / or systems over a network using any suitable communication technology and / or standard.

[0238] As illustrated in FIG. 21, the exemplary system 2100 includes a processing unit 2102 and a system memory 2104, which may include high-speed random access memory (RAM) for storing programs and other data for use and execution by the processing unit 2102. the system may comprise a system memory 2104 which may include one or more bulk non-volatile non-transitory computer-readable storage media (e.g., hard disk, flash memory, etc.); a port 2106 for interfacing with a removable memory 608 which may include one or more diskettes, optical storage media (e.g., flash memory, thumb drives, USB dongles, compact discs, DVDs, etc.) and / or other non-transitory computer-readable storage media; a network interface 2110 for communicating with other systems over one or more network connections and / or networks 2112 using one or more communications technologies; a user interface 2114 which may include a display and / or one or more input / output devices such as, for example, a touch screen, keyboard, mouse, track pad, etc.; and one or more buses 2116 for communicatively coupling the elements of the system.

[0239] In some embodiments, the system 2100 may alternatively or additionally include a trusted execution environment and / or an SPU 2118 that is protected from tampering by a user of the system or other entities by utilizing secure physical and / or virtual security techniques. The trusted execution environment and / or SPU 2118 may help to enhance security of sensitive operations such as personal information management, trusted credentials and / or key management, privacy and policy management, and other aspects of the systems and methods disclosed herein. In certain embodiments, the trusted execution environment and / or SPU 2118 may operate in a logically secure processing domain and may be configured to protect and operate on sensitive information, as described herein. In some embodiments, the trusted execution environment and / or SPU 2118 may include an internal memory that stores executable instructions or programs configured to enable the SPU 2118 to perform secure operations, as described herein.

[0240] Operation of the system 2100 may generally be controlled by the processing unit 2102 and / or SPU 2118, which operate by executing software instructions and programs stored in the system memory 2104 (and / or other computer-readable media, such as memory 2108, which may be removable). The system memory 2104 may store various executable programs or modules for controlling operation of the system. For example, the system memory may include, at least in part, an operating system ("OS") 2120, which may manage and coordinate system hardware resources and provide common services for running various applications.

[0241] The system memory 2104 may further include, without limitation, communications software 2122 configured to enable partial communication with and by the system, one or more applications, a cryptographic operations module 2124 configured to perform various aspects of the disclosed embodiments (e.g., cryptographic key and hash generation operations, key management operations, etc.), one or more validation digital asset and / or token management modules 2126 configured to perform various aspects of the methods disclosed herein, and / or any other information, modules, and / or applications configured to implement embodiments of the systems and methods disclosed herein.

[0242] The systems and methods disclosed herein are not inherently related to any particular computer, electronic control unit, or other apparatus, but may be implemented by any suitable combination of hardware, software, and / or firmware. A software implementation may include one or more computer programs that include executable code / instructions that, when executed by a processor, cause the processor to perform a method defined at least in part by the executable instructions. The computer programs may be written in any form of programming language, including compiled or interpreted languages, and may be deployed in any form, such as a stand-alone program or as a module, component, subroutine, or other unit suitable for use in a computing environment. Furthermore, the computer programs may be deployed to be executed on one computer or on multiple computers at one site or distributed multiple sites, interconnected by a communication network.

[0243] A software embodiment may be implemented as a computer program product including a computer program and a non-transitory storage medium configured to store instructions that, when executed by a processor, are configured to cause the processor to perform a method in accordance with the instructions. In certain embodiments, the non-transitory storage medium may take any form capable of storing processor-readable instructions on the non-transitory storage medium. The non-transitory storage medium may be embodied by a compact disc, a digital video disk, a magnetic disk, a flash memory, an integrated circuit, or any other non-transitory digital processing apparatus memory device.

[0244] Although the foregoing has been described in some detail for clarity, it will be apparent that certain changes and modifications may be made without departing from the principles of the present invention. It should be noted that there are many alternative ways of implementing both the system and the method described herein. Thus, the present embodiments should be considered as illustrative and not restrictive, and the present invention is not limited to the details described herein, but may be modified within the scope of the appended claims and their equivalents.

Claims

1. 1. A method for managing digital assets implemented by a token rights management service, the method comprising: receiving digital assets from the marketplace service; generating a first hash using the digital asset; receiving a digital rights management data access request from the marketplace service, the digital rights management data access request including a marketplace access token and an identifier associated with a user; obtaining asset information associated with the marketplace service based on the marketplace access token, the asset information including the first hash; generating a second hash using a structured combination of at least the first hash and the identifier associated with the user; generating a property rights assertion that includes the second hash; generating a trusted ledger query, the trusted ledger query including the asset rights assertion; issuing the generated trusted ledger query to a trusted ledger service that maintains a trusted ledger containing a plurality of cryptographically linked ledger entries; receiving, in response to the issued trusted ledger query, an indication from the trusted ledger service verifying that the second hash included in the asset rights assertion is pre-recorded in a cryptographically linked ledger entry of the plurality of cryptographically linked ledger entries of the trusted ledger; determining, based on the received indication, that the user has a right to access the digital asset; generating a rights management query based on determining that the user has a right to access the digital asset, the rights management query including a key identifier and a key encryption key, the key encryption key including a public encryption key associated with the user; issuing the generated rights management query to a digital rights management service; receiving, from the digital rights management service in response to the issued rights management query, a digital rights management token associated with the digital asset, the digital rights management token including an encrypted content key, the encrypted content key including a content key for the digital asset encrypted with the key encryption key; and transmitting the digital rights management token and an access link for accessing the digital asset to the marketplace service for communication to a system associated with the user.

2. 10. The method of claim 1, wherein the method further comprises storing the first hash in a database associated with a trusted data management service, and wherein obtaining the asset information associated with the marketplace service comprises retrieving the asset information from the database associated with the trusted data management service.

3. The method comprises: validating the marketplace service with the trusted data management service using the marketplace access token, the validating including sending the marketplace access token to the trusted data management service; and receiving an indication from the trusted data management service of an account identifier associated with the marketplace service based on successful validation of the marketplace service; The method of claim 2 , wherein obtaining the asset information associated with the marketplace service is based on the account identifier associated with the marketplace service.

4. The method of claim 2 , wherein the token rights management service is a service of the trusted data management service.

5. The method of claim 1 , wherein the key identifier and the key encryption key are accessed from a database associated with a trusted data management service.

6. The method of claim 1 , wherein the access link for accessing the digital asset comprises a uniform resource locator associated with an electronic file corresponding to the digital asset.

7. The method of claim 1 , wherein determining that the user has rights to the digital asset comprises determining that the user is an owner of the digital asset.

8. 8. The method of claim 7, further comprising verifying, by the token rights management service, that there is a remaining supply of the digital asset.

9. 2. The method of claim 1, wherein the digital rights management data access request includes at least one of an identifier associated with the digital asset, an identifier associated with a user requesting access to the digital asset, and an identifier associated with a product that includes the digital asset.

10. 10. The method of claim 1, wherein the marketplace service runs on the same system as the token rights management service.

11. The method of claim 1 , wherein the trusted ledger comprises a trusted immutable distributed assertion ledger.

12. The method of claim 1 , wherein the trusted ledger comprises a blockchain ledger.

13. The method of claim 2 , wherein the digital rights management service is a service of the trusted data management service.

Images