WO2024159477A1

WO2024159477A1 - Systems and methods for nft-based secure management of digital assets

Info

Publication number: WO2024159477A1
Application number: PCT/CN2023/074230
Authority: WO
Inventors: Saeed Ranjbar ALVAR; Mohammad Akbari; Chendi WANG; Yong Zhang
Original assignee: Huawei Cloud Computing Technologies Co Ltd
Current assignee: Huawei Cloud Computing Technologies Co Ltd
Priority date: 2023-02-02
Filing date: 2023-02-02
Publication date: 2024-08-08
Anticipated expiration: 2025-08-02
Also published as: CN120641894A

Abstract

Methods and systems for secure management of a digital asset by a digital asset management system are described. The system is authorization to distribute, to a recipient user, a digital asset stored in a digital asset storage. Identifications of the recipient and/or owner user and a token identification of a non-fungible token (NFT) of the digital asset are provided. The digital asset is retrieved from the digital asset storage. The digital asset is watermarked to embed digital information uniquely indicative of the owner user and/or the recipient user. The watermarked digital asset is encrypted using an encryption key of the recipient user and the encrypted watermarked digital asset is stored in the digital asset storage. The asset record is updated to include the identification of the recipient user and the NFT is provided to the recipient user.

Description

SYSTEMS AND METHODS FOR NFT-BASED SECURE MANAGEMENT OF DIGITAL ASSETS

CROSS-REFERENCE TO RELATED APPLICATIONS

This is the first application related to the present disclosure.

FIELD

The present disclosure relates to systems and methods for secure management of digital assets, in particular secure management of digital assets using NFTs.

BACKGROUND

In recent years, there have been increasing amounts of data generated (e.g., by end consumers, institutions, etc. ) and increasing interest in making practical use of such data, such as in big data analytics and machine learning-based applications. Such data is a type of digital asset and can be valuable. Other types of digital assets include machine learning models, code, digital notebooks, online services, etc. Because such digital assets have value, there is a desire to ensure they are securely managed. It may be important to ensure digital assets are securely stored (e.g., cannot be easily leaked) , can be validated (e.g., to ensure the digital asset has not been corrupted or tampered with) and/or ownership of the digital asset can be traceable.

Accordingly, it would be useful to provide systems and methods for secure management of digital assets.

SUMMARY

In various examples, the present disclosure describes systems and methods for secure management of digital assets, using NFT and watermarking technologies. Examples of the present disclosure enable ownership of a digital asset to be traceable, and may enable traceable identification of both provider and consumer of a digital asset that has been traded. For example, provider-and consumer-specific watermarks may be embedded in a traded digital asset. A digital asset may be traded as an NFT, which assigns a unique indicator for the digital asset and serves to prove the ownership of the digital asset. Trading history of a digital asset may be stored in a blockchain, which may serve as an immutable history of transactions related to the digital asset. Technical advantages include enabling ownership of a digital asset to be traced and verified, for example in the event of disputed ownership and/or authorized distribution of the digital asset.

Examples of the present disclosure also provides for secure encryption and tamper-proofing of a digital asset. For example key-based encryption (e.g., asymmetric encryption) may be used to help ensure that a digital asset is assessable only by authorized parties (e.g., an authorized consumer or authorized user of the digital asset) . In some examples, content-based addressing may be used to generate a link for accessing a digital asset that is stored in a secure data storage. This may provide technical advantages such as preventing tampering of the digital asset and preventing unauthorized parties from accessing a digital asset even in the event the security of the data storage is compromised.

In some example aspects, the present disclosure describes a method for secure management of a digital asset by a digital asset management system. The method includes: receiving authorization to distribute, to a recipient user, a digital asset stored in a digital asset storage, the authorization including an identification of at least one of the recipient user or an owner user, and a token identification of a non-fungible token (NFT) stored on a blockchain; retrieving the digital asset from the digital asset storage using a link extracted from an asset record stored on the blockchain and related to the NFT; watermarking the digital asset to embed digital information uniquely indicative of at least one of the owner user or the recipient user; encrypting the watermarked digital asset using an encryption key of the recipient user; storing the encrypted watermarked digital asset in the digital asset storage; updating the asset record to include the identification of the recipient user; and providing the NFT to a user device of the recipient user.

In an example of the preceding example aspect of the method, the method may also include: generating a new link for retrieving the encrypted watermarked digital asset from the digital asset storage; and updating the asset record to further include the new link.

In an example of the preceding example aspect of the method, the digital asset storage may be a content-addressable storage, and the new link may be a content-based address of the encrypted watermarked digital asset in the digital asset storage.

In an example of any of the preceding example aspects of the method, the method may also include: generating a hash based on the digital asset and updating the NFT to include the hash.

In an example of the preceding example aspect of the method, the hash may be generated from the encrypted watermarked digital asset, may be generated from the watermarked digital asset prior to the encrypting, or may be generated from the digital asset prior to the watermarking.

In an example of any of the preceding example aspects of the method, the digital asset retrieved from the digital asset storage may be an encrypted digital asset that was encrypted using an encryption key of the digital asset management system, and the encrypted digital asset may be decrypted prior to the watermarking.

In an example of any of the preceding example aspects of the method, the encryption key used to encrypt the watermarked digital asset may be a public encryption key of the recipient user, and the encrypted watermarked digital asset may be decryptable using a private encryption key of the recipient user.

In an example of any of the preceding example aspects of the method, the digital information embedded in the watermarked digital asset may be a string containing at least one of the identification of the owner user or the identification of the recipient user.

In an example of some of the preceding example aspects of the method, the digital information embedded in the watermarked digital asset may be a digital signature that uniquely maps to at least one of the owner user or the recipient user.

In an example of some of the preceding example aspects of the method, the digital asset may be a computer executable program and the digital information embedded in the watermarked digital asset may be unique program behaviour of the computer executable program that uniquely maps to at least one of the owner user or the recipient user.

In an example of any of the preceding example aspects of the method, the method may include, prior to receiving the authorization to distribute the digital asset: receiving the digital asset and the identification of the owner user; storing the digital asset in the digital asset storage and generating the link for retrieving the digital asset from the digital asset storage; generating a contract entry to include in a smart contract stored on the blockchain, the contract entry including the identification of the owner user and the link for retrieving the digital asset from the digital asset storage; and minting the NFT for the digital asset and updating the contract entry to include the token identification of the NFT.

In an example of the preceding example aspect of the method, after receiving the digital asset, the digital asset may be encrypted using an encryption key of the digital asset management system and may be stored in the digital asset storage after the encryption.

In an example of some of the preceding example aspects of the method, the method may also include: including a description of the digital asset in a published listing of digital assets managed by the digital asset management system.

In some examples, the present disclosure describes a method, at a digital asset management system, for detecting at least one user associated with a digital asset. The method includes: receiving a request to identify one or more users associated with a watermarked digital asset, the request being associated with a user identification of a requestor, wherein the watermarked digital asset has been watermarked to embed digital information uniquely indicative of at least one of an owner user or a recipient user; extracting the embedded digital information from the watermarked digital asset; determining at least an identification of the recipient user from the extracted digital information; and providing at least the identification of the recipient user in response to the request.

In an example of the preceding example aspect of the method, both an identification of the owner user and the identification of the recipient user may be determined from the extracted digital information, and the method may include: comparing the identification of the owner user with the user identification of the requestor; and providing at least the identification of the recipient user when the user identification of the requestor matches the identification of the owner user.

In an example of some of the preceding example aspects of the method, the method may also include: determining an asset type of the watermarked digital asset; determining a watermarking technique that was used to embed the digital information in the watermarked digital asset, based on the asset type; and performing the extracting based on the determined watermarking technique.

In an example of the preceding example aspect of the method, the asset type may be indicated in the request and the asset type may be determined from the request.

In some examples, the present disclosure describes a method, at a digital asset management system, for tracing a transaction associated with a digital asset. The method includes: receiving a request to trace a transaction associated with a digital asset, the request including at least one of an identification of an owner user or an identification of a recipient user; obtaining an original copy of the digital asset; generating a hash based on the digital asset; searching a blockchain to identify a non-fungible token (NFT) having a hash matching the generated hash; extracting, from the identified NFT, a contract address for locating an asset record on the blockchain; extracting, from the asset record, transaction information related to the digital asset; and providing the extracted transaction information in response to the request.

In an example of the preceding example aspect of the method, the request may include the identification of the owner user, and the method may also include: prior to providing the extracted transaction information, comparing a user identification in the extracted transaction information with the identification of the owner user included in the request; and providing the extracted transaction information in response to the user identification in the extracted transaction information matching the identification of the owner user.

In an example of any of the preceding example aspects of the method, generating the hash may include: generating a watermarked digital asset by watermarking the original copy of the digital asset to embed digital information uniquely indicative of at least one of the identification of the owner user or the identification of the recipient user; encrypting the watermarked digital asset using an encryption key of the recipient user; and generating the hash from the encrypted watermarked digital asset.

In an example of some of the preceding example aspects of the method, generating the hash may include: generating a watermarked digital asset by watermarking the original copy of the digital asset to embed digital information uniquely indicative of at least one of the identification of the owner user or the identification of the recipient user; and generating the hash from the watermarked digital asset.

In an example of some of the preceding example aspects of the method, the method may also include: determining an asset type of the digital asset; determining an appropriate watermarking technique based on the asset type; and generating the watermarked digital asset using the determined appropriate watermarking technique.

In an example of some of the preceding example aspects of the method, generating the hash may include: generating the hash from the original copy of the digital asset.

In an example of any of the preceding example aspects of the method, obtaining the original copy of the digital asset may include receiving the original copy of the digital asset with the request.

In an example of some of the preceding example aspects of the method, obtaining the original copy of the digital asset may include retrieving the original copy of the digital asset from a storage of the digital asset management system.

In some example aspects, the present disclosure describes a computer-implemented digital asset management system including a processing unit configured to execute instructions to cause the system to perform any of the preceding example aspects of the method.

In an example of the preceding example aspect of the system, the processing unit may be configured to execute instructions to cause the system to implement a content-addressable storage as the digital asset storage.

In another example of the preceding example aspect of the system, the processing unit may be configured to execute instructions to cause the system to: communicate with a remote storage system providing the digital asset storage.

In some example aspects, the present disclosure describes a non-transitory computer readable medium having instructions stored thereon, wherein the instructions are executable by a processing unit of a computer-implemented digital asset management system to cause the system to perform any of the preceding example aspects of the method.

BRIEF DESCRIPTION OF THE DRAWINGS

Reference will now be made, by way of example, to the accompanying drawings which show example embodiments of the present application, and in which:

FIG. 1 is a block diagram illustrating an example computing system, which may be used to implement examples of the present disclosure;

FIG. 2 is a block diagram illustrating an example digital asset management system, in accordance with examples of the present disclosure;

FIGS. 3A and 3B illustrates an example operation of the digital asset management system of FIG. 2;

FIGS. 4A and 4B are flowcharts of example methods for managing a digital asset, in accordance with examples of the present disclosure;

FIG. 5 is a flowchart of an example method for detecting a user identity associated with a digital asset, in accordance with examples of the present disclosure; and

FIG. 6 is a flowchart of an example method for tracing a transaction associated with a digital asset, in accordance with examples of the present disclosure.

Similar reference numerals may have been used in different figures to denote similar components.

DETAILED DESCRIPTION

To assist in understanding the present disclosure, some technical terms are first discussed. It should be understood that the following discussion of terms is not intended to be limiting and is not intended to introduce any meaning to any term that is contrary to its interpretation by one of ordinary skill in the art. One of ordinary skill in the art may also understand that a particular term may encompass a meaning broader than that generally discussed below.

In the present disclosure, a digital asset may refer to a form of digital file that contains stored information, or a computer-executable method (e.g., computer-executable software algorithms, online web services, etc. ) for processing data. Examples of a digital asset include a text file, image file, video file, audio file, 3D object file, 1D digital signals recorded as a file, computer code file, online notebook file, machine learning model, etc. A digital asset may be static (such as a data file) or may be dynamic (e.g., time-varying data, such as stock market records or inventory records) .

The present disclosure refers to watermarking as a technique for embedding a digital message or pattern (referred to as a digital watermark) in a digital asset. The embedded digital watermark may be extracted and may be used to identify an owner and/or recipient of the digital asset, using techniques as disclosed herein.

In the present disclosure, a blockchain may refer to a distributed digital ledger that is used to maintain an immutable, time-ordered history of transactions, which are recorded in blocks. The general term blockchain may refer to a public blockchain or a private blockchain. A public blockchain is a form of blockchain in which anyone can join and participate in activities on the blockchain. In a public blockchain, the transactions and the addresses involved can be viewed publicly. A private blockchain has an administration who controls who can join and participate in the blockchain.

Content-based addressing (sometimes referred to as content-addressable storage or fixed-content storage) refers to a technique of generating a link to access a digital asset in a data storage, in which the link is generated based on the content of the stored digital asset. If the content of the stored digital asset changes, the link that is generated for accessing that digital asset in the data storage is also changed.

The present disclosure refers to a smart contract as a piece of self-executing software code that is stored on a blockchain. A smart contract typically is automatically executed when conditions of the smart contract are met.

An asset record, as used in the present disclosure, refers to a record, stored on the blockchain, containing information about a digital asset and any transactions related to the digital asset.

In the present disclosure, a non-fungible token (NFT) refers to a digital identifier that uniquely identifies a digital asset. The NFT and its transactions are recorded on a blockchain. Minting an NFT refers to the process of publishing the digital asset, which is identified by the NFT, on a blockchain. The NFT thus is a unique token ID that has a unique address on the blockchain.

As described above, it is desirable for digital assets to be managed in a secure manner, including secure storage, traceable ownership and tamper-proofing of the digital assets. There are existing platforms for managing digital assets, which support trading (e.g., buying and selling) of digital assets. however, a problem with existing platforms is that a digital asset can be easily copied and redistributed in an unauthorized manner. This can result in exposure of confidential or private information, as well as a loss in value of the digital asset. Detection and tracking of the source of unauthorized distribution is also a problem. Another drawback of existing platforms is that digital assets tend to be stored in a centralized data storage, which increases the vulnerability to data leaks and unauthorized access. In existing digital asset management platforms, there can also be a problem of ownership verification and data validation. That is, a user accessing a digital asset on the platform may not be able to verify whether the digital asset has been corrupted or tampered with, or whether the digital asset is being made available by an authorized owner. Ownership of digital assets can also be complex in existing approaches, for example by requiring ownership registration and verification with a third-party, which can be tedious, time-consuming and/or costly.

Examples of the present disclosure may address at least some of the above-noted problems.

FIG. 1 is a block diagram illustrating a simplified example implementation of a computing system 100 suitable for implementing embodiments described herein. Examples of the present disclosure may be implemented in other computing systems, which may include components different from those discussed below.

Although FIG. 1 shows a single instance of each component, there may be multiple instances of each component in the computing system 100. Further, although the computing system 100 is illustrated as a single block, the computing system 100 may be a single physical machine or device (e.g., implemented as a single computing device, such as a single workstation, single server, etc. ) , or may comprise a plurality of physical machines or devices (e.g., implemented as a server cluster) . For example, the computing system 100 may represent a group of servers or cloud computing platform providing a virtualized pool of computing resources (e.g., a virtual machine, a virtual server, etc. ) .

The computing system 100 includes at least one processing unit 102, such as a processor, a microprocessor, a digital signal processor, an application-specific integrated circuit (ASIC) , a field-programmable gate array (FPGA) , a dedicated logic circuitry, a dedicated artificial intelligence processor unit, a graphics processing unit (GPU) , a tensor processing unit (TPU) , a neural processing unit (NPU) , a hardware accelerator, or combinations thereof. Each of the processing unit (s) 102 may include one or more processing cores. In some examples, the processing unit 102 may perform operations in conjunction with a computing platform. Accordingly, the performance of operations may be distributed among one or more processing units 102, whether residing only within a single machine (e.g., a single computing system 100) or deployed across a number of machines (e.g., multiple computing systems 100) . For example, one or more processing units 102 may be located in a single geographic location (e.g., within a home environment, an office environment, or a server farm) , or may be distributed across a number of geographic locations.

The computing system 100 may include an optional input/output (I/O) interface 104, which may enable interfacing with an optional input device 106 and/or optional output device 108. In the example shown, the optional input device 106 (e.g., a keyboard, a mouse, a microphone, a touchscreen, and/or a keypad) and optional output device 108 (e.g., a display, a speaker and/or a printer) are shown as external to the computing system 100, however one or more input device (s) 106 and/or output device (s) 108 may be an integral component of the computing system 100. In other example embodiments, there may not be any input device 106 and output device 108, in which case the I/O interface 104 may not be needed.

The computing system 100 may include an optional network interface 110 for wired or wireless communication with other computing systems (e.g., other computing systems in a network) . The network interface 110 may include wired links (e.g., Ethernet cable) and/or wireless links (e.g., one or more antennas) for intra-network and/or inter-network communications.

The computing system 100 may include a storage unit 112, which may include a mass storage unit such as a solid state drive, a hard disk drive, a magnetic disk drive and/or an optical disk drive. The storage unit 112 may store data, for example. In some examples, the storage unit 112 may serve as a storage for digital assets managed by a digital asset management system 200, as discussed further below.

The computing system 100 includes at least one memory 114, which may include a volatile or non-volatile memory (e.g., a flash memory, a random access memory (RAM) , and/or a read-only memory (ROM) ) . The non-transitory memory 114 may store instructions for execution by the processing unit 102, such as to carry out example embodiments described in the present disclosure. For example, the memory 114 may store instructions for implementing a digital asset management system 200, discussed further below. In some examples, the memory 114 may serve as a storage for digital assets managed by the digital asset management system 200. The memory 114 may store other software instructions, such as for implementing an operating system and other applications/functions (e.g., other operations in digital chip design, such as placement, clock tree synthesis and/or routing operations) .

The computing system 100 may additionally or alternatively execute instructions from an external memory (e.g., an external drive in wired or wireless communication with the server) or may be provided executable instructions by a transitory or non-transitory computer-readable medium. Examples of non-transitory computer readable media include a RAM, a ROM, an erasable programmable ROM (EPROM) , an electrically erasable programmable ROM (EEPROM) , a flash memory, a CD-ROM, or other portable memory storage.

FIG. 2 is a block diagram illustrating details of an example digital asset management system 200, as disclosed herein. The digital asset management system 200 is a computer-implemented system (e.g., implemented using an online platform, a server, etc. ) that performs operations for secure management of digital assets, including secure storage and distribution of digital assets.

The digital asset management system 200 includes subsystems and storage including a digital asset storage 210, a blockchain 220, a watermarking subsystem 230, an encryption subsystem 240 and an NFT subsystem 250.

It should be understood that FIG. 2 is not intended to be limiting. For example, the digital asset management system 200 may include greater or fewer number of subsystems than that shown. Functions that are described as being performed by a particular subsystem may be performed by a different subsystem, and one subsystem may perform the functions described as being performed by two or more subsystems. Some subsystems, such as the digital asset storage 210, blockchain 220 and/or encryption subsystem 240 may be external to the digital asset management system 200 (e.g., may reside in a data storage unit external to the digital asset management system 200, or may reside in a trusted third-party system) . Some subsystems may be part of or closely related to another subsystem of the digital asset management system 200, for example the NFT subsystem 250 may be part of or closely related to the blockchain 220.

One or more user devices 260a, 260b (e.g., any end consumer electronic device, such as desktop computers, laptop computers, tablets, mobile devices, smartphones, etc. ) may communicate with the digital asset management system 200 (e.g., over a wired or wireless network, such as the Internet) . The digital asset management system 200 may enable users to securely manage their digital assets. For example, a first user device 260a may belong to a user who is an owner of a digital asset (e.g., a file, software, data, machine learning model, etc. ) . The user device 260a may use the digital asset management system 200 to securely store the digital asset and to securely distribute the digital asset to an authorized recipient (e.g., the user of the second user device 260b) . As will be discussed further below, the digital asset management system 200 provides services to ensure digital assets are distributed in a secure and traceable manner, to help decrease the risk of data leak and tampering, and to enable identification of the source of a data leak should such an event occur.

Unique users may each be associated with respective unique user identifiers (user ID) . User IDs may be assigned to users by the digital asset management system 200, or may be supplied by users (e.g., a user may use a blockchain wallet ID as their user ID) . When a user is registered with the digital asset management system 200, the digital asset management system 200 may generate unique public and private keys associated with the user, which will be used for encryption and decryption of digital assets.

The digital asset management system 200 stores digital assets in the digital asset storage 210. Digital assets may be stored in an encrypted form, for example encrypted using a public key associated with the digital asset management system 200. The digital asset storage 210 may support content-based addressing.

The blockchain 220 stores NFTs and associated asset records and smart contracts. Each NFT corresponds to a unique digital asset stored in the digital asset storage 210. Ownership information and transaction details related to a digital asset are stored on the blockchain 220, such that a history of the transactions can be preserved. The blockchain may be any suitable blockchain that supports NFTs, such as the Ethereum blockchain, Solana blockchain, Polygon blockchain or Cardano blockchain, among others. The blockchain 220 may be a public blockchain or a private blockchain.

The encryption subsystem 240 may be used to generate public and private keys for users of the digital asset management system 200. The encryption subsystem 240 may also store encryption keys used by the digital asset management system 200 itself and/or public keys of the users. The encryption subsystem 240 may use encryption keys to encrypt or decrypt digital assets as discussed further below.

When a new digital asset is added (e.g., by a user who is an owner of the digital asset) to the digital asset storage 210, the NFT subsystem 250 may perform operations to mint a new NFT for that digital asset. A contract entry of a smart contract is generated and associated with the new NFT. Both the smart contract and the NFT are registered on the blockchain 220. In some examples, the owner of the digital asset may already have a smart contract (e.g., generated at the time the owner registered with the digital asset management system 200) and the contract entry for the new digital asset may be added to the smart contract of the owner. In other examples, a smart contract may be newly generated for each newly added digital asset.

In some examples, the digital asset management system 200 may provide services to enable users to advertise or publish information about the digital assets being management by the digital asset management system 200. For example, the digital asset management system 200 may provide a public listing of available digital assets (e.g., an online marketplace) , on which a user may publish information about the digital asset (s) they wish to sell or distribute via the digital asset management system 200. The digital asset management system 200 may provide the public listing via a website, a cloud-based service, a mobile application, or any other online platform that may allow the published information to be viewed by users registered with the digital asset management system 200. In some examples, the published information may also be viewable by users who are not yet registered with the digital asset management system 200 (however, transactions of digital assets may only be between users who are registered with the digital asset management system 200) . The published information may include, for example, the name of the user who owns the digital asset, some general description of the digital asset (e.g., asset type) , terms and conditions for distribution of the digital asset (e.g., whether the recipient can redistribute or resell the digital asset) and/or a price for the asset. Another user may view the published information via the digital asset management system 200.

General operations of the digital asset management system 200 are now discussed.

FIG. 3A is a schematic diagram that illustrates further details of the operations of the digital asset management system 200. It should be understood that FIG. 3 is intended to be exemplary and not limiting.

As previously mentioned, users may access the digital asset management system 200 using respective user devices 260a, 260b (generically referred to as user devices 260) . Each user may register with the digital asset management system 200 and be associated with a unique user ID (which may be assigned to the user by the digital asset management system 200 or may be user-supplied, such as a blockchain wallet ID) . After registration, each user is issued their own unique public and private keys, which may be used for ownership registration and verification. In some examples, if symmetric encryption is used instead of asymmetric encryption, each user may be issued only one encryption key. In some examples, a user’s encryption key (e.g., the public key if asymmetric encryption is used) may be used as an identifier of the user.

If a first user is an owner of a digital asset (e.g., the user of the first user device 260a) , the user may upload the digital asset to be stored in the digital asset storage 210. The digital asset management system 200 may encrypt the digital asset using a public key of the digital asset management system 200, so that the digital asset is stored in an encrypted form.

A link is generated by the digital asset management system 200 to enable the stored digital asset to be retrievable from the digital asset storage 210. The digital asset storage 210 may be a content-addressable storage, such as the InterPlanetary File System (IPFS) or the like. This means that the generated link is for an address in the digital asset storage 210 that is based on the content of the stored digital asset. In other words, changing the content of the stored digital asset would change the address at which the stored digital asset is stored in the digital asset storage 210. This may help to prevent corruption or tampering of a stored digital asset, because the link (which is generated based on the content of the original stored digital asset) would not be able to retrieve the corrupted or tampered digital asset from the digital asset storage 210. If the stored digital asset is a dynamic digital asset (e.g., contains time-varying data) , each change to the content of the dynamic digital asset creates a new version of the digital asset and a new corresponding content-based address is required to access that new version. The history of the different versions of the dynamic digital asset may be stored on the blockchain 220.

A contract entry is also generated for a smart contract to be associated with the digital asset. In some examples, the smart contract may be associated with the first user (e.g., the smart contract may be linked to the user ID of the first user) and all digital assets owned by the first user may be associated with the first user’s smart contract. If the first user already has a smart contract (e.g., a smart contract was created when the first user has previously uploaded another digital asset to the digital asset management system 200 or when the first user previously registered with the digital asset management system 200) , the smart contract associated with the first user may be updated to include the new contract entry for the newly uploaded digital asset. If the first user does not already have a smart contract, the digital asset management system 200 may create a new smart contract for the first user and include the contract entry for the newly uploaded digital asset. The smart contract is stored on the blockchain 220 (which may be any blockchain that supports smart contract functionality, such as the Ethereum blockchain) at a contract address. An asset record (also referred to as the transactions history) on the blockchain 220 is automatically updated whenever there is a change associated with the digital asset, such as a new transaction of the digital asset and/or an updated link for accessing the digital asset in the digital asset storage 210. The asset record for a digital asset includes information that is related to the digital asset and is stored on the blockchain 220 so that the transaction history of the digital asset is traceable and immutable. Examples of information in the asset record may include the asset link (e.g., uniform resource identifier (URI) ) and/or ownership information for the asset.

An NFT is minted (i.e., generated) for the stored digital asset, for example by the NFT subsystem 250 of the digital asset management system 200. Each NFT is generally related to a smart contract that is used for managing the digital asset. The smart contract is updated with the token ID of the NFT associated with the digital asset. The NFT is also stored on the blockchain 220 along with the smart contract for the digital asset. The NFT may contain metadata stored on-chain such as the contract address for the smart contract related to the NFT. Other NFT metadata may also be stored on-chain, such as a description of the stored digital asset (which may be based on the description of the digital asset that is included in a public listing of the digital asset) or a file name of the stored digital asset. The NFT subsystem 250 may mint the NFT in accordance with any suitable NFT standard, such as the ERC-721 standard or the ERC-1155 standard. In some examples, in order to enable distribution of the stored digital asset to multiple recipients, multiple copies of the stored digital asset may be generated and respective multiple NFTs may be minted, and each NFT provides a unique token ID for a specific copy of the stored digital asset.

A second user (e.g., the user of the second user device 260b) may be a recipient of the digital asset that is owned by the first user. The second user is authorized by the first user to access and/or use the digital asset. A transaction of the digital asset to the recipient user may be authorized by the owner user, for example after a request (e.g., a purchase order or a non-commercial request) is made for the digital asset by the recipient user. In some examples, the transaction may be initiated by the recipient user making a request for the digital asset (e.g., via an online marketplace) , and explicit approval or authorization by the owner user may not be required to initiate the transaction. For example, the first and second users may have a provider/consumer relationship, an employer/employee relationship, a software distributer/licensed user relationship, a teacher/student relationship, etc. For convenience, the first user who is the owner of a piece of digital asset that is being securely managed by the digital asset management system 200 may be referred to herein as the owner user (or simply owner) , and the second user who is authorized to access and/or use the digital asset may be referred to herein as the recipient user (or simply recipient) . If the digital asset is a dynamic digital asset, the recipient user may be authorized to access a specific version of the digital asset (e.g., the latest version of the digital asset at the time of the authorization) . If the contents of the dynamic digital asset is later updated, the recipient user may be able to use the version history of the digital asset that is saved on the blockchain 220 to access the latest version of the digital asset.

The digital asset is not directly sent to the recipient user. Instead, the digital asset management system 200, using the watermarking subsystem 230, first watermarks the digital asset. The digital asset is retrieved from the digital asset storage 210 (e.g., using the link stored in the NFT associated with the digital asset) . If the digital asset was stored in an encrypted form (e.g., encrypted using the public key of the digital asset management system 200) , the digital asset may be decrypted (e.g., using the private key of the digital asset management system 200) . The digital asset management system 200 then digitally watermarks the digital asset using information that is uniquely associated with the owner user and/or the recipient user. In some examples, the digital asset is watermarked with information that is uniquely associated with both the owner user and the recipient user. This means that the digital asset is embedded with digital information that can be later extracted and used to uniquely identify the owner user (i.e., the first user) , the recipient user (i.e., the second user) or both the owner and recipient users (i.e., both the first and second users) of the watermarked digital asset. Details of example techniques for watermarking the digital asset with digital information that uniquely identifies the owner user, the recipient user or the owner-recipient user pair are provided further below.

Encryption is then applied to the watermarked digital asset. If asymmetric encryption is used, the watermarked digital asset is encrypted using the recipient user’s public key. Details of an example encryption and decryption process using asymmetric encryption are provided further below. If symmetric encryption is used, secure exchange of encryption keys between the owner and recipient users may be first necessary, and then encryption is performed using the exchanged keys.

A hash of the encrypted watermarked digital asset may be generated by the digital asset management system 200 (e.g., using any suitable hashing function, such as SHA256) and the generated hash may be stored as metadata in the NFT associated with the digital asset. The generated hash may be used for traceability purposes.

The encrypted watermarked digital asset is stored in the digital asset storage 210. The digital asset management system 200 uses content-based addressing to generate a new link for accessing the encrypted watermarked digital asset in the digital asset storage 210. A storage protocol that uses content-based addressing may help to ensure that the content of the digital asset is not corrupted, modified or replaced. For example, the digital asset storage 210 may be a centralized or decentralized storage that is based on IPFS. The encrypted digital asset may be fully stored in the digital asset storage 210. Alternatively (e.g., if the encrypted digital asset is very large) , a portion of the encrypted digital asset may be stored in the digital asset storage 210 and the remainder of the encrypted digital asset may be stored in another storage (which may or may not be internal to the digital asset management system 200) without content-based addressing.

In some examples, if the digital asset is not a digital file (e.g., the digital asset is an online service) the digital asset storage 210 may store an encrypted link to the digital asset instead of the encrypted digital asset itself.

The asset record on the blockchain 220 corresponding to the NFT is updated with information about the transfer of the digital asset from the owner user to the recipient user. For example, the unique user IDs of the owner and/or recipient users, and the generated link for accessing the encrypted watermarked digital asset may be written into the URI under the token ID of the NFT associated with the digital asset. Other information may be included in the asset record, depending on the transaction. For example, if the digital asset is being sold, the selling price of the digital asset may be included in the update to the asset record (stored on the blockchain 220) of the digital asset.

The recipient user is provided with the contract address of the smart contract on the blockchain 220 and the token ID of the NFT associated with the digital asset.

FIG. 3B is a simplified illustration of how the recipient user may retrieve the digital asset from the digital asset storage 210.

Each digital asset that is managed by the digital asset management system 200 is associated with a respective NFT and smart contract (it should be noted that a single smart contract may be associated with multiple digital assets, each of which may be identified in the smart contract by referencing the contract entry for the corresponding NFT token ID) . A contract entry in the smart contract stores information about a particular digital asset (e.g., identification of the owner user) , or stores a pointer to this information (which may be stored elsewhere in memory) . The smart contract assigns a token ID to each digital asset managed by the smart contract and the information corresponding to each token ID is stored on the blockchain 220. The asset record 240 on the blockchain 220 stores information about the digital asset and any transactions of that digital asset (e.g., identification of the owner user, recipient user, any transaction value, etc. ) . The link for retrieving the digital asset from the digital asset storage 210 is included in the asset record 224 related to the NFT. Other information may be included in the asset record 224, such as a hash of the digital asset, description of the digital asset, asset version controlling details, owner/consumer rights, etc.

In this example, the blockchain 220 stores the NFT 222 associated with the digital asset as well as the asset record 224 associated with the digital asset. In this example, the NFT 222 contains the unique token ID (e.g., “12345” ) and the contract address for the smart contract (e.g., “0x98765” ) . As previously mentioned, the NFT 222 may contain other metadata, such as a hash of the digital asset, a description of the digital asset, etc. In this example, the asset record 224 is stored on the blockchain 220 under the token ID of the NFT 222. The asset record 224, which may according to the token ID “12345” , includes identification of the owner user (e.g., “Bob” ) , the recipient user (e.g., “Tom” ) and other transaction data (e.g., date and time of the transaction, sale price of the transaction, etc. ) . It may be noted that if the digital asset associated with the NFT having the token ID “12345” has not yet been part of any transaction (e.g., the digital asset is newly uploaded to the digital asset management system 200) , the asset record 224 may omit the recipient user identification and transaction data. The asset record 224 also includes a link for accessing the digital asset in the digital asset storage 210.

The recipient user, using the received NFT token ID and smart contract address, may look up the smart contract and the particular asset record 224 for the NFT token ID in order to extract the link for the digital asset. Using the link, the recipient user may access the digital asset storage 210 and download the encrypted watermarked digital asset from the digital asset storage 210 onto the recipient user’s user device 260b.

The recipient user’s private key (or encryption key if symmetric encryption is used) is used to decrypt the downloaded digital asset. The recipient user now is able to make use of the digital asset. However, it should be noted that the digital asset that is available to be used by the recipient user is a watermarked version of the original digital asset that was uploaded to the digital asset management system 200 by the owner user. As will be discussed further below, this watermarking enables detectability and traceability, for example in the event the digital asset is distributed in an unauthorized manner.

Watermarking of the digital asset may be performed by the digital asset management system 200 using the watermarking subsystem 230 as shown in FIG. 2. Further details of the operations of the watermarking subsystem 230 are now discussed.

The watermark that is embedded in the watermarked digital asset contains information that can be used to uniquely identify the owner-recipient user pair, or used to uniquely identify at least one of the owner user or the recipient user. In some examples, the watermark may be used to uniquely identify the pair of user IDs of the owner and recipient users together. This enables identification of both the original owner user of the digital asset as well as the authorized recipient user of the digital asset. This means that if the owner user has authorized the same digital asset to be distributed to and used by multiple recipient users, each recipient user accesses a respective differently watermarked digital asset. If one recipient user distributes their copy of the watermarked digital asset in an unauthorized manner, it is possible using the watermark to identify which recipient user is the source of the unauthorized distribution. In some examples only the owner user identification or only the recipient user identification may be uniquely identifiable using the watermark.

The digital asset management system 200 may use various watermarking techniques (which may be implemented by the watermarking subsystem 230) to watermark a digital asset. The technique used to perform the watermarking (i.e., to embed a unique digital pattern or digital code into the digital asset) may depend on the type of the digital asset.

For example, frequency-domain based watermarking techniques may be suitable for watermarking image, video, audio and point cloud digital assets. In frequency-domain based watermarking, the watermark is embedded in the higher frequency components of the data.

For example, a string (e.g., a character string or text string that is a concatenation of the user ID (s) of the owner user and/or recipient user) may be embedded (i.e., watermarked) in the discrete cosine transform (DCT) coefficients of an RGB image. Let S denote the string to be embedded in the image, where the image is denoted as I, where H and W denote the height and the width of the image, respectively, and there are three channels, corresponding to the RGB channels. Each character in S may be first converted to its corresponding ASCII code, such that each character is represented by a bit string. The obtained bit strings may then be combined (using some known, defined technique, such as linear combination) to form a vector of bitsNote that the length ofshould be less than (H*W) /7, otherwise the vector of bits will exceed the image dimensions and will be truncated.

The vector of bits inmay then be embedded in the frequency coefficients of the luminance component of the image. The image is first converted from RGB to YCbCr as follows:

where R, G. B, Y, Cb, Cr and T denote red, green, blue, luminance component, chrominance component, chrominance component and the predefined transformation matrix, respectively.

Y is then transformed into DCT domain representation F as follows:

for u=0, 1, ..., H-1 and v=0, 1, ..., W-1, where Y (x, y) is the pixel in the x-th row and y-th column in luminance signal and,

The inverse DCT, which transforms F back to Y is defined as:

F is a vector forming the DCT coefficients of the image. After the DCT coefficientsF are obtained, the bits in the vector of bitsare embedded (i.e., watermarked) in selected N DCT coefficients of F, denoted {F₁, .... F_N} , using the following equation:for i=1: N

where α is a scaling factor, is the i-th element inand F′_i is the updated DCT coefficient after watermarking.

The N DCT coefficients that are selected for the watermarking may be selected from the higher frequency components in F, for example. Finally, inverse DCT is applied to the updated frequency components and the watermarked image is reconstructed as Y′.

To extract the watermark from the watermarked image Y′, the original image Y and the order of the selected frequency coefficients are required. The extracted watermark vectormay be obtained as follows:

for i=1: N

The ASCII code inis decoded (e.g., by performing the reverse of the known, defined combination technique that was used to generate) to recover the original stringS containing the user ID (s) of the owner user and/or the recipient user.

Similar DCT-based watermarking techniques can be applied to audio, video and point cloud digital assets by adjusting the selected DCT coefficients according to the dimensions of the data.

Different watermarking techniques may be used, for example depending on the desired robustness of the watermark (e.g., if it is known that the watermarked digital asset is likely to be communicated over a noisy channel, more robust watermarking techniques may be desired to avoid degrading the watermark due to noise) .

In some examples, the watermark embedded in a digital asset may not be a direct identifier of the owner user and recipient user (e.g., the watermark may not be generated using the user ID (s) of the owner and/or recipient users directly) . Instead, the watermark may be a digital signature or pattern that uniquely maps to the user ID (s) of the owner and/or recipient users. For example, a digital signature that is watermarked in a particular digital asset may be extracted and used to reference a secure lookup table stored by the digital asset management system 200, to look up the user ID identifying the owner user, to look up the user ID identifying the recipient use, or to look up the pair of user IDs identifying the owner-recipient user pair for that digital asset. In another example, a digital signature that is watermarked in a particular digital asset may be extracted and used as input to a secure algorithm in the digital asset management system 200 to obtain a piece of data (e.g., a feature vector or hash string) that can be matched up with the pair of user ID (s) identifying the owner user and/or recipient user for that digital asset.

An example of a watermarking technique that can be indirectly used to identify the owner user and/or recipient user of a digital asset is now described. A digital asset that is a text document may be watermarked according to the frequency or positions of key words in a selected portion of text. The frequency or positions of the key words may be encoded in a unique bit string that is associated with the particular owner user and/or recipient user. If the digital asset belonging to the owner user is authorized to be distributed to different recipient users, different portions of text (having different frequencies or positions of the key words) may be selected, so that different bit strings are associated with different recipient users. Then, when the watermark is later extracted from a particular digital asset, the recovered bit string can be used to look up the recipient user for that digital asset.

In another example, for computer executable digital assets such as software code and algorithms that are used to run certain computations or machine learning models, watermarking may be performed by encoding unique behavior into the digital asset. For example, a machine learning model may be trained to generate a unique output (which may be significantly different from its expected output) when a particular data sample is provided as input. The unique input and unique output may be uniquely mapped to a particular owner user and/or recipient user.

In general, the digital asset management system 200 may use any suitable watermarking technique (depending on the type of the digital asset) to watermark digital assets, to enable unique identification of the owner user, recipient user or owner-recipient user pair.

As discussed previously, after a digital asset is watermarked with information unique to the owner user and/or recipient user, the watermarked digital asset is encrypted. Encryption may be performed by the digital asset management system 200 using the encryption subsystem 240 as shown in FIG. 2. Further details of the operations of the encryption subsystem 240 are now discussed. In particular, the following discussion is in the context of asymmetrical encryption, in which each user registered with the digital asset management system 200 has both a private key and a public key. If symmetric encryption is used instead, each user may have only one encryption key and the digital asset management system 200 may facilitate secure exchange of keys between the owner user and the recipient user.

When asymmetric encryption is used, encryption of the watermarked digital asset is applied using the recipient user’s public key, to ensure that only the recipient user is able to decrypt the watermarked digital asset (using the recipient user’s private key) . It may be noted that, because watermarking is performed by the digital asset management system 200 and the watermarked digital asset is encrypted by the digital asset management system 200 using the recipient user’s public key afterwards, the owner user may have no access to the unencrypted and watermarked digital asset. This may help to detect the source of a data leak in the event unauthorized distribution of the digital asset occurs. Only the recipient user should have access to the unencrypted and watermarked digital asset and the data leak thus would not be attributable to the owner user.

Various methods may be used to encrypt a digital asset. An example encryption technique that may be performed by the encryption subsystem 240 is the Rivest–Shamir–Adleman (RSA) encryption algorithm. The RSA algorithm may be broken down into three stages, including key generation, encryption and decryption. As previously mentioned, key generation may occur at the time that each user initially registers with the digital asset management system 200. In the example where asymmetric encryption is used, a pair of public and private keys may be generated by the encryption subsystem 240 as follows.

First, two prime number, denoted p and q are chosen. The prime numbers may be selected in any arbitrary way for a given user who is being initially registered with the digital asset management system 200. Then two values, n and z, are obtained as follows: n=p*q, z= lcm (p-1, q-1) , where lcm (a, b) is a function that obtains the least common multiplier of two values a and b. An integer number, e, is selected such that 1＜e＜z. A value d is computed, where d is the modular multiplicative inverse of e (mod z) . The public key is (n, e) and the private key is (n, d) . Both the public and private keys are issued to the given user. A copy of the public key may be stored by the encryption subsystem 240 and may be used for encryption of a digital asset that is authorized to be accessed by the given user. The private key should be securely maintained by the given user, and may be used to decrypt the encrypted digital asset.

An example encryption and decryption is now described, where the digital asset being encrypted and decrypted is a plaintext message, denoted m. The encrypted message, denoted as c, may be obtained using the public key (n, e) as follows:
c(m) = me mod (n)

The encrypted message may subsequently be decrypted using the private key (n, d) to recover the plaintext message m as follows:

m (c) = c^d mod (n)

Other encryption techniques may be used, including other asymmetric encryption techniques as well as symmetric encryption techniques.

FIGS. 4A and 4B are flowcharts illustrating an example method 400 and an example method 450 that may be performed by the digital asset management system 200 for secure management of a digital asset between a first user (e.g., an owner user) and a second user (e.g., a recipient user) . The methods 400, 450 may be carried out by a computing system (e.g., the computing system 100) having one or more processing units to execute instructions (which may be stored in a non-transitory computer-readable medium, such as code stored in a tangible memory) . The methods 400, 450 may be performed together (e.g., the digital asset management system 200 may perform the method 400 followed by the method 450) , may be performed independently of each other (e.g., the method 400 may be performed, then some time later the method 450 may be triggered) or may be performed alone (e.g., the digital asset management system 200 may perform the method 450 only) .

It should be understood that the methods 400, 450 illustrate only some example operations of the digital asset management system 200. Steps of the method 400 or the method 450 may be performed in a different order than that shown, and two or more steps may be performed in parallel or together. Steps of the method 400 and the method 450 may be performed using subsystems of the digital asset management system 200 as described below, however this is not intended to be limiting. The method 400 is first described.

At 402, a digital asset is received by the digital asset management system 200. The digital asset belongs to a first user who may be referred to as the owner user (i.e., the owner of the received digital asset) . The owner user may, for example, upload the digital asset to the digital asset management system 200 via a communication link between the user device 260a and a web portal provided by the digital asset management system 200. In another example, the owner user may upload the digital asset to a third-party service and the digital asset may be sent to the digital asset management system 200 by the third-party service (e.g., the digital asset management system 200 may provide back-end secure management of the digital asset on behalf of the third-party service) . Regardless of how the digital asset is received, the digital asset management system 200 obtains information about the owner user, such as the user ID, the public encryption key of the owner user or the smart contract associated with the owner user (if any) .

At 404, the received digital asset is stored in the digital asset storage 210 and a link is generated for accessing the stored digital asset. The generated link may be a content-based address of the stored digital asset. The digital asset may be stored after being encrypted (e.g., by the encryption subsystem 240) using a public key of the digital asset management system 200, in some examples.

At 406, a contract entry is generated for a smart contract associated with the digital asset, in which the smart contract is stored on the blockchain 220 at a contract address. The smart contract may be an existing smart contract of the owner user or may be newly generated smart contract. The contract entry stores or points to information about the digital asset, such as the user ID of the owner user and the link for accessing the stored digital asset.

At 408, an NFT is minted (e.g., by the NFT subsystem 250) for the digital asset and the contract entry is updated with the token ID of the minted NFT. The NFT is related to the smart contract containing the contract entry for the digital asset (e.g., the NFT metadata includes the contract address for locating the smart contract on the blockchain 220) . An asset record related to the NFT is also stored on the blockchain 220 under the token ID of the NFT. In some examples, if the owner user wishes to make the digital asset distributable to multiple recipients, multiple copies of the digital asset may be stored in the digital asset storage 210 and corresponding multiple NFTs may be minted. Each copy of the digital asset is associated with a respective unique NFT and a respective unique contract entry in the smart contract.

The digital asset is now securely stored and is available for secure distribution. The digital asset may be securely stored in the digital asset storage 210 until distribution of the digital asset is authorized. For example, the availability of the digital asset may be included in a public listing, which may be viewed by other users via their user devices. A recipient user who wishes to access or use the digital asset may view the public listing and initiate a transaction (e.g., a purchase order) for the digital asset. In another example, the owner user may wish to make the digital asset securely available to a recipient user in a non-commercial scenario.

The method 450 is now described. As previously mentioned, the method 450 may be performed by the digital asset management system 200 without performing the method 400. For example, the digital asset may be securely stored in a content-addressable digital asset storage 210, and a NFT and contract entry for the stored digital asset may be generated and stored on the blockchain 220 without performing the method 400 (e.g., other steps may be performed) .

At 452, authorization is received by the digital asset management system 200 to distribute the digital asset to a recipient user. The authorization may be received in response to the recipient user requesting the digital asset and/or by the owner user providing instructions to distribute the digital asset to the recipient user. In general, the authorization to distribute the digital asset to the recipient user may be triggered when the conditions in the smart contract related to the digital asset have been satisfied. The authorization may include an identification (e.g., user ID) of the authorized recipient user, and may also identify the digital asset (e.g., by NFT token ID) that is to be distributed as well as the owner user (e.g., user ID) . If there are multiple copies of the digital asset that can be distributed, the digital asset management system 200 may select one of the copies at random or in order of their NFT token ID (e.g., select the next NFT that does not have any transaction data yet) , for example.

At 454, the digital asset is retrieved from the digital asset storage 210. For example, the digital asset management system 200 may use the link generated at step 404 (or generated at some other content-based addressing step) to retrieve the digital asset from the digital asset storage 210. The link for retrieving the digital asset may be obtained by using the NFT token ID to identify the asset record associated with the digital asset, then extracting the link from the asset record. If the digital asset was encrypted using the public key of the digital asset management system 200, the digital asset management system 200 may (e.g., using the encryption subsystem 240) decrypt the digital asset using a private key of the digital asset management system 200.

At 456, the digital asset is watermarked (e.g., by the watermarking subsystem 230) with digital information that is uniquely indicative of the owner user and/or recipient user. Various watermarking techniques, as discussed previously, may be used to embed (i.e., watermark) the digital information into the digital asset, for example depending on the type of the digital asset. The digital asset management system 200 may use the same watermarking technique for all digital assets of the same asset type (e.g., same technique for watermarking all image files) , so that the digital asset management system 200 can determine how to extract the watermark based on the asset type. In some examples, the digital asset management system 200 may automatically detect the asset type (e.g., based on the file extension of the digital asset, or based on metadata attached to the digital asset) and determine the appropriate watermarking technique to use based on the detected asset type. In other examples, the asset type may be indicated as part of the authorization received at step 452 and the digital asset management system 200 may determine the appropriate watermarking technique to use based on the indicated asset type.

At 458, the watermarked digital asset is encrypted using a key (e.g., public key) belonging to the recipient user. For example, the encryption subsystem 240 may use the public key that was generated and issued to the recipient user at the time the recipient user registered with the digital asset management system 200 to perform the encryption.

At 460, a hash may be generated based on the digital asset. The hash is generated based on the content of the digital asset and enables future traceability of the digital asset. The hashing function that is used to generate the hash may be known to both the owner user and the recipient user. In the example of FIG. 4B, the hash is generated from the encrypted watermarked digital asset and step 460 is illustrated as following step 458. However, in some examples the hash may be generated from the watermarked digital asset prior to encryption (i.e., step 460 is performed following step 456 and before step 458) or may be generated from the original digital asset prior to watermarking (i.e., step 460 is performed following step 454 and before step 456) . For example, to ensure that the hash is reproducible (e.g., for later traceability as discussed below with reference to FIG. 6) , the hash may be generated prior to any processing of the digital asset that would introduce randomness. For example, if watermarking of the digital asset introduced randomness the hash may be generated from the original digital asset (with the user ID (s) of the owner user and/or recipient user attached) prior to watermarking. In another example, if encryption introduces randomness, the hash may be generated from the watermarked digital asset prior to encryption.

At 462, the encrypted watermarked digital asset is stored in the digital asset storage 210 and a new link is generated. It should be noted that, because the encrypted watermarked digital asset has content that differs from the digital asset that was previously stored and retrieved from the digital asset storage 210, the content-based address of the new link may differ from the link that was used to retrieve the digital asset at step 454.

At 464, the NFT metadata and asset record associated with the digital asset are updated. The NFT and asset record to be updated may be identified using the token ID of the digital asset, which may be included in the authorization received at step 452. For example, the NFT token ID may be used to identify the NFT and asset record of the digital asset in the blockchain 220. The NFT metadata may be updated to include the hash generated at step 460. The asset record corresponding to the NFT token ID may be updated with the new link generated at step 462, the identification of the recipient user, and optionally other information about the transaction (e.g., date or time of the authorization, any transaction value, etc. ) .

At 466, the contract address of the smart contract and the token ID of the NFT are provided to the recipient user. For example, the digital asset management system 200 may communicate the contract address and the token ID to the user device 260b of the recipient user over a secure communication link. As discussed previously, the recipient user may use this information to retrieve the encrypted watermarked digital asset from the digital asset storage 210 and may use their private key to decrypt the watermarked digital asset. The recipient user may, prior to decryption, use the hash stored in the NFT metadata to help ensure that the content of the received encrypted watermarked digital asset was not changed or corrupted. In some examples, if the hash was not generated from the encrypted watermarked digital asset (e.g., if the hash was generated from the watermarked digital asset prior to encryption, or was generated from the original digital asset prior to watermarking) , the hash may not be used by the recipient user to verify the received encrypted watermarked digital asset. The recipient user can use the same hashing function (e.g., SHA256) that was used at step 460 to obtain a hash of the received encrypted watermarked digital asset. If the obtained hash matches the hash stored in the NFT, then this may validate received encrypted watermarked digital asset.

In addition to enabling traceability and verification by the recipient user, generating a hash based on the digital asset may in some examples enable the digital asset management system 200 to identify if there are any similar or identical digital assets being managed or distributed. For example, the digital asset management system 200 may hash original digital assets (prior to watermarking and encryption) . Then the hash generated from one digital asset may be used to search if there are similar or identical hashes stored in other NFTs on the blockchain 220. If so, this means that there is another digital asset with similar or identical content that was distributed on the digital asset management system 200. The digital asset management system 200 may generate a notification to alert the owner user that there is another digital asset with similar or identical content to the owner user’s digital asset. This may alert the owner user to the possibility of unauthorized redistribution of their digital asset.

In some cases, after the digital asset is distributed to the authorized recipient user, unauthorized distribution of the digital asset may occur. When an owner user finds that their owned digital asset has been distributed in an unauthorized manner, it may be necessary to detect the source of the unauthorized distribution. In particular, if the owner user has authorized the digital asset to be distributed to multiple different recipient users, it may be necessary to identify which particular recipient user was the source of the unauthorized distribution (also referred to as a data leak) . The digital asset management system 200 may provide services to enable detection of the source of the unauthorized distribution. For example, the digital asset management system 200 may offer detection as a service to registered users or as a backend service for a third-party platform. For example, the third-party platform may carry out the methods 400, 450 described above, and the digital asset management system 200 may provide detection services.

FIG. 5 is a flowchart illustrating an example method 500, which may be performed by the digital asset management system 200 for identifying one or more users (e.g., a recipient user) associated with a digital asset. The method 500 may be carried out by a computing system (e.g., the computing system 100) having one or more processing units to execute instructions (which may be stored in a non-transitory computer-readable medium, such as code stored in a tangible memory) . The method 500 may be performed separately from and independently of the method 400 and/or the method 450.

At 502, a request is received by the digital asset management system 200 to identify one or more users associated with a watermarked digital asset. For example, the digital asset management system 200 may receive the request from the owner user (e.g., the user device 260a of the owner user may communicate the request to the digital asset management system 200 via a web portal or other secure communication link) of the digital asset. In another example, the digital asset management system 200 may receive the request from a third-party service. The request may be a request to identify the recipient user authorized to access and use the watermarked digital asset. The digital asset management system 200 may require the identification of the user who made the request. The watermarked digital asset may have been watermarked as part of the operations to securely distribute the digital asset (e.g., using the method 450) . Notably, the watermark embedded in the digital asset contains digital information that uniquely indicates the owner user and/or recipient user who was/were involved in the authorized distribution of the watermarked digital asset. In particular, the watermark may contain digital information to enable at least the recipient user to be uniquely identified.

At 504, the watermark is extracted from the watermarked digital asset. That is, the digital information that is embedded in the watermarked digital asset is extracted. The technique for extracting the watermark may depend on the technique that was used to watermark the digital asset, for example depending on the asset type. For example, if the watermark is embedded in the DCT coefficients, then inverse DCT can be performed (e.g., as discussed previously) . In some examples, the digital asset management system 200 may automatically detect the asset type (e.g., based on the file extension of the watermarked digital asset, or based on metadata attached to the watermarked digital asset) and determine the technique for extracting the watermark based on the detected asset type. In other examples, the asset type may be indicated as part of the request received at step 502 and the digital asset management system 200 may determine the technique for extracting the watermark based on the indicated asset type.

At 506, the digital information contained in the extracted watermark is used to identify the recipient user associated with the digital asset. The extracted watermark may also contain digital information to enable the owner user associated with the digital asset to be identified. For example, if the digital information encodes the user IDs of the recipient user (and possibly also the user ID of the owner user) using some known scrambling, the digital asset management system 200 may perform unscrambling to recover the user ID of the recipient user (and possibly also the user ID of the owner user) . In another example, the digital information may contain a reference to a lookup table that contains the user ID of the recipient user (and possibly also the user ID of the owner user) associated with the watermarked digital asset.

At 508, if the extracted watermark also uniquely identifies the owner user, then the owner user identification is compared with the user identification associated with the received request. If the user identification associated with the request matches the owner user identification, the method proceeds to 510. If the user identification associated with the request does not match the owner user identification, the method proceeds to step 512. This comparison may be performed to help ensure that information about the authorized distribution of the digital asset is only provided to authorized parties (e.g., only to the owner user) . This may provide an additional layer of security in the event a malicious user attempts to tamper with the watermark to forge the identity of another recipient user.

At 510, after the user identification is found to match (if step 508 is performed) , the recipient user identification is provided (e.g., communicated to the user device 260a of the owner user) . Optionally, the owner user identification may also be provided. The recipient user identification enables the owner user to identify the recipient user whose copy of the digital asset has been distributed in an unauthorized manner. As previously noted, if there are multiple recipient users who are authorized to receive a copy of the digital asset, each recipient may receive a uniquely watermarked copy of the digital asset, where the watermark uniquely identifies each recipient user or owner-recipient user pair. Thus, the owner user is provided with the identification of the specific recipient user whose watermarked copy of the digital asset has been distributed in an unauthorized manner.

At 512, if step 508 is performed and the user identification is found to not match, the request is denied.

After the owner user obtains the identification of the recipient user who is potentially the source of an unauthorized distribution, the owner user may wish to obtain further information about the transaction of the digital asset. For example, the owner user may wish to obtain information about the date and time of the transaction and/or the value of the transaction. Information about the transaction may be useful as proof that a particular watermarked digital asset (which may have been distributed in an unauthorized manner) was actually received by the recipient user who is potentially the source of the unauthorized distribution. The digital asset management system 200 may provide services to enable tracing of the transactions associated with the digital asset. For example, the digital asset management system 200 may offer tracing as a service to registered users or as a backend service for a third-party platform. For example, the third-party platform may carry out the methods 400, 450 described above, and the digital asset management system 200 may provide tracing services.

FIG. 6 is a flowchart illustrating an example method 600, which may be performed by the digital asset management system 200 for tracing a transaction associated with a digital asset. It should be understood that tracing a transaction may include tracing non-commercial transactions (e.g., a non-commercial distribution) of the digital asset. That is, the method 600 is not limited to tracing transactions that involve selling or buying of the digital asset. The method 600 may be carried out by a computing system (e.g., the computing system 100) having one or more processing units to execute instructions (which may be stored in a non-transitory computer-readable medium, such as code stored in a tangible memory) . The method 600 may be performed separately from and independently of the method 400, the method 450 and/or the method 500.

At 602, a request is received by the digital asset management system 200 to trace a transaction associated with a digital asset. For example, the digital asset management system 200 may receive the request from the owner user (e.g., the user device 260a of the owner user may communicate the request to the digital asset management system 200 via a web portal or other secure communication link) of the digital asset. In another example, the digital asset management system 200 may receive the request from a third-party service. The request may be a request to trace transactions involving the digital asset. The digital asset management system 200 may require the request to include identification of the owner and/or recipient users involved in the transaction to be traced.

At 604, a copy of the original (non-watermarked) digital asset is obtained. The original digital asset may be provided to the digital asset management system 200 as part of the request received at 602 (e.g., uploaded by the owner user who requests the transaction tracing) . In some examples, the digital asset management system 200 may maintain a copy of the original digital asset (e.g., as a “master” copy) . For example, the digital asset management system 200 may maintain a database containing copies of all original data assets managed by the digital asset management system 200, and the database may be accessible only to the internal subsystems of the digital asset management system 200. In some examples, the original copies may be stored separately from the digital asset storage 210 storing minted (i.e., available for distribution) digital assets, and details of which original copy corresponds to which minted digital asset may be maintained by the digital asset management system 200.

At 610, a hash is generated for the digital asset. How the hash is generated should be identical to the steps for generating the hash when the digital asset was originally distributed. This means that the hash generated at step 610 should be identical to the hash that was previously (e.g., generated at step 460) and that was stored in the NFT metadata on the blockchain. For example, if the hash was previously generated after watermarking and encryption, then the hash at step 610 should also be generated from the encrypted watermarked digital asset after performing the same watermarking and encryption steps (e.g., repeating steps 456 to 460 as previously described) . If the hash was previously generated after watermarking but prior to encryption, then the hash at step 610 should also be generated from the (unencrypted) watermarked digital asset. If watermarking is performed as part of generating the hash, the watermarking technique may be determined based on the asset type (which may be determined based on the file extension of the digital asset or may be explicitly indicated in the trace request, for example) . If the hash was previously generated using the original digital asset (with user ID (s) of the owner user and/or recipient user attached) prior to watermarking, the hash at step 610 should be similarly generated from the original digital asset.

At 612, the digital asset management system 200 performs a search of the blockchain 220 for the NFT having the hash generated at step 610. The NFT having a matching hash is identified and the method 600 proceeds to step 614. The matching of the hash serves to verify that the content of the encrypted watermarked digital asset has not changed since the time of the authorized distribution to the recipient user. If there is no NFT found with a matching hash, then there may be no blockchain record of any transaction of the digital asset between the owner user and recipient user, or the information provided in the trace request received at step 602 may contain an error. The digital asset management system 200 may provide a negative or error response to the trace request.

At 614, the contract address is extracted from the identified NFT. The contract address is used to locate the smart contract associated with the digital asset on the blockchain 220.

At 616, the transaction information related to the identified NFT contained in the asset record on the blockchain 220 is extracted. The extracted transaction information may include, for example, identification of the owner user (e.g., owner’s user ID) , identification of the recipient user (e.g., recipient’s user ID) , identification of the NFT (e.g., token ID) , the contract address for the related smart contract, any transaction value, the date and time of the transaction, etc. The transaction information may be used to verify that the recipient user in fact did receive a watermarked digital asset from the owner user (because the transaction information stored on the blockchain 220 may serve as a digital signature from the recipient user) . The extracted transaction information may be provided as a response to the trace request (e.g., may be communicated to the user device 260a of the owner user who submitted the trace request) . In some examples, prior to providing the transaction information, the digital asset management system 200 may verify that the identification of the owner user matches the identification of the user who made the trace request at step 602. This may help to ensure that the transaction information is provided only to the owner user, to prevent potentially private information from being inadvertently provided to other users.

The method 600 thus uses a hash of the digital asset to enable transaction information related to the digital asset to be located on the blockchain 220. It may be noted that, in some examples, if the trace request includes the token ID of the digital asset’s NFT, then the transaction information may be located using the token ID instead of using a hash of the digital asset. However, the token ID may not always be known to the user making the trace request. For example, a token ID may be a long and complicated string of numbers that can be difficult for a user to keep track of, particularly if the user has other digital assets with other token IDs. Additionally, a user may use imperfect methods to record their token IDs (e.g., written records) which can introduce errors (e.g., reproduction error) or can be lost. Thus, the method 600 provides traceability without having to rely on an accurate record of token IDs being maintained by a user.

The digital asset management system 200 thus provides detectability and traceability of all digital assets distributed via the digital asset management system 200. Using digital information encoded in the watermarked digital asset, the digital asset management system 200 enables a recipient user to be detected as the source of an unauthorized distribution of the watermarked digital asset. Further, by providing traceability based on a hash, the digital asset management system 200 enables verification that a distribution of the watermarked digital asset to the recipient user actually took place.

In some examples, a recipient user may not be authorized to resell or redistribute the watermarked digital asset that the recipient user was authorized to receive via the digital asset management system 200. Thus, if the watermarked digital asset (which is uniquely watermarked such that the recipient user is identifiable, as described above) is found to be in the possession of any user other than the recipient user, this may be considered unauthorized distribution by the recipient user. In other examples, reselling or redistribution of the watermarked digital asset may be permitted (e.g., depending on the terms and conditions of the distribution, which may be described in the published listing of the digital asset) .

If the recipient user is authorized for reselling or redistribution of their watermarked digital asset, the recipient user may use the digital asset management system 200 to redistribute the watermarked digital asset.

In some examples, the recipient user may act as though they are the original owner user of the watermarked digital asset. The watermarked digital asset may be uploaded to the digital asset management system 200 and distributed to a further recipient user in the manner previously described (e.g., as described with respect to methods 400 and 450) . In this case, the redistribution may not be clearly linked back to the original distribution of the digital asset.

In other examples, the redistribution of the watermarked digital asset may be treated slightly differently from the original distribution. The recipient user may be considered a redistributor user. The redistributor user may upload the watermarked digital asset to the digital asset management system 200. The redistributor user may have a smart contract linked to their user ID. When the watermarked digital asset is uploaded to the digital asset management system 200, the digital asset management system 200 may detect that the watermarked digital asset was previously distributed and may use the hashing technique described previously to identify the original owner user’s smart contract related to the previous distribution of the watermarked digital asset. For example, the digital asset management system 200 may perform operations to check for the presence of a watermark and verify whether a user ID indicated by the watermark match the user ID of the user who is uploading the watermarked digital asset. Alternatively, when the watermarked digital asset is uploaded to the digital asset management system 200, the token ID of the NFT and the contract address of the smart contract that are related to the original distribution of the watermarked digital asset may be provided to the digital asset management system 200 by the redistributor user. The digital asset management system 200 may verify that the redistributor user is the authorized recipient of the watermarked digital asset by checking that the user ID of the redistributor user matches the user ID of the recipient user as indicated by the digital information embedded in the watermark.

A contract entry is generated in the redistributor user’s smart contract for the watermarked digital asset. The contract entry related to redistribution of the watermarked digital asset includes the contract address of the original owner user’s smart contract. In this way, the smart contract that contains information related to the redistribution of the watermarked digital asset is linked to the smart contract that contains information related to the original distribution of the watermarked digital asset. Then the redistributor user may redistribute the watermarked digital asset to a further recipient user, with watermarking and encryption similar to that described above. Note that because the smart contract related to the redistribution is linked to the smart contract related to the original distribution, the full history of the distribution of the digital asset is retained and traceable. In some examples, the asset record related to the original distribution (i.e., the original digital asset) may be updated to include information about the redistribution. The redistributor user thus may use the original smart contract related to the original distribution to redistribute the digital asset to the new recipient user. The transaction details regarding this redistribution may be linked to the existing transactions corresponding to the digital asset. In this way, the digital asset management system 200 may enable the existing smart contract for the digital asset to be used for redistribution of the digital asset.

In some examples, multiple digital assets may be distributed together as a group in one transaction. For example, a set of data samples (also referred to as a dataset) that may be used for training a machine learning model may contain data belonging to multiple owner users. In such scenarios, the group of data assets may be encrypted and stored together as a single encrypted asset group (similar to a single large digital asset) . The group of owner users may be assigned a single group ID that uniquely identifies the group of owner users and that can be used in a manner similar to the user ID for a single owner user. The digital asset management system 200 may store a database of the user IDs belonging to each group ID. Then distribution of the asset group may take place in a manner similar to that described previously. Alternatively, instead of using a single group ID, the user ID of each owner user in the group may be embedded in the digital information when the asset group is watermarked. By keeping the user IDs of each owner user in the group separate (rather than representing all owner users in the group using a single group ID) , it may be possible to separate out the digital asset (s) owned by a particular owner user in the group if that particular owner user does not wish to include their owned digital asset (s) in a distribution of the asset group. The remainder of the asset group may be distributed if the remaining owner users in the group authorizes the distribution.

The example systems and methods disclosed herein may provide secure management of digital assets. The examples of the present disclosure may provide security by ensuring digital assets are stored and distributed in an encrypted form. Storage of encrypted digital assets using content-addressable storage may also help to prevent tampering of the stored assets. The example systems and methods use NFT and blockchain techniques to enable traceability and verification of all distributions and transactions related to a digital asset. NFT and blockchain technologies provide a way to maintain a verifiable and unchangeable history of how the digital asset has been distributed. The use of NFTs enables digital assets to be uniquely owned and distributed, as well as enabling large scale adoption due to users’ familiarity with NFT-based transactions. Since most blockchain technologies enable real-time updating and tracing, registration and verification of distributions and transactions can be carried out in real-time. This may be useful to improve reliability of the system and to encourage transparency for both owner and recipient users. The example systems and methods make use of watermarking techniques to provide detectability and traceability, which may help to detect a source of any unauthorized distribution of digital assets managed by the disclosed systems.

Examples of the disclosed methods and systems may be implemented digital asset trading platforms, data marketplaces and/or machine learning hubs. Examples of the disclosed methods and systems may support secure management and distribution of digital assets in both commercial and non-commercial scenarios. The disclosed examples may be implemented by multiple different platforms that use the same watermarking, encryption and hashing techniques, disclosed herein, for NFT-based distribution of digital assets. The watermarking, encryption and hashing may be agreed upon by all of the platforms so that a user may distribute their digital asset over any of the platforms while maintaining the benefits of secure management, detectability and traceability.

Although the present disclosure describes methods and processes with steps in a certain order, one or more steps of the methods and processes may be omitted or altered as appropriate. One or more steps may take place in an order other than that in which they are described, as appropriate.

Although the present disclosure is described, at least in part, in terms of methods, a person of ordinary skill in the art will understand that the present disclosure is also directed to the various components for performing at least some of the aspects and features of the described methods, be it by way of hardware components, software or any combination of the two. Accordingly, the technical solution of the present disclosure may be embodied in the form of a software product. A suitable software product may be stored in a pre-recorded storage device or other similar non-volatile or non-transitory computer readable medium, including DVDs, CD-ROMs, USB flash disk, a removable hard disk, or other storage media, for example. The software product includes instructions tangibly stored thereon that enable a processing device (e.g., a personal computer, a server, or a network device) to execute examples of the methods disclosed herein. The machine-executable instructions may be in the form of code sequences, configuration information, or other data, which, when executed, cause a machine (e.g., a processor or other processing device) to perform steps in a method according to examples of the present disclosure.

The present disclosure may be embodied in other specific forms without departing from the subject matter of the claims. The described example embodiments are to be considered in all respects as being only illustrative and not restrictive. Selected features from one or more of the above-described embodiments may be combined to create alternative embodiments not explicitly described, features suitable for such combinations being understood within the scope of this disclosure.

All values and sub-ranges within disclosed ranges are also disclosed. Also, although the systems, devices and processes disclosed and shown herein may comprise a specific number of elements/components, the systems, devices and assemblies could be modified to include additional or fewer of such elements/components. For example, although any of the elements/components disclosed may be referenced as being singular, the embodiments disclosed herein could be modified to include a plurality of such elements/components. The subject matter described herein intends to cover and embrace all suitable changes in technology.

Claims

A method for secure management of a digital asset by a digital asset management system, the method comprising:

receiving authorization to distribute, to a recipient user, a digital asset stored in a digital asset storage, the authorization including an identification of at least one of the recipient user or an owner user, and a token identification of a non-fungible token (NFT) stored on a blockchain;

retrieving the digital asset from the digital asset storage using a link extracted from an asset record stored on the blockchain and related to the NFT;

watermarking the digital asset to embed digital information uniquely indicative of at least one of the owner user or the recipient user;

encrypting the watermarked digital asset using an encryption key of the recipient user;

storing the encrypted watermarked digital asset in the digital asset storage;

updating the asset record to include the identification of the recipient user; and

providing the NFT to a user device of the recipient user.
The method of claim 1, further comprising:

generating a new link for retrieving the encrypted watermarked digital asset from the digital asset storage; and

updating the asset record to further include the new link.
The method of claim 2, wherein the digital asset storage is a content-addressable storage, and the new link is a content-based address of the encrypted watermarked digital asset in the digital asset storage.
The method of any one of claims 1 to 3, further comprising:

generating a hash based on the digital asset and updating the NFT to include the hash.
The method of claim 4, wherein the hash is generated from the encrypted watermarked digital asset.
The method of claim 4, wherein the hash is generated from the watermarked digital asset prior to the encrypting.
The method of claim 4, wherein the hash is generated from the digital asset prior to the watermarking.
The method of any one of claims 1 to 7, wherein the digital asset retrieved from the digital asset storage is an encrypted digital asset that was encrypted using an encryption key of the digital asset management system, and wherein the encrypted digital asset is decrypted prior to the watermarking.
The method of any one of claims 1 to 8, wherein the encryption key used to encrypt the watermarked digital asset is a public encryption key of the recipient user, and wherein the encrypted watermarked digital asset is decryptable using a private encryption key of the recipient user.
The method of any one of claims 1 to 9, wherein the digital information embedded in the watermarked digital asset is a string containing at least one of the identification of the owner user or the identification of the recipient user.
The method of any one of claims 1 to 9, wherein the digital information embedded in the watermarked digital asset is a digital signature that uniquely maps to at least one of the owner user or the recipient user.
The method of any one of claims 1 to 9, wherein the digital asset is a computer executable program and the digital information embedded in the watermarked digital asset is unique program behaviour of the computer executable program that uniquely maps to at least one of the owner user or the recipient user.
The method of any one of claims 1 to 12, further comprising, prior to receiving the authorization to distribute the digital asset:

receiving the digital asset and the identification of the owner user;

storing the digital asset in the digital asset storage and generating the link for retrieving the digital asset from the digital asset storage;

generating a contract entry to include in a smart contract stored on the blockchain, the contract entry including the identification of the owner user and the link for retrieving the digital asset from the digital asset storage; and

minting the NFT for the digital asset and updating the contract entry to include the token identification of the NFT.
The method of claim 13, wherein, after receiving the digital asset, the digital asset is encrypted using an encryption key of the digital asset management system and is stored in the digital asset storage after the encryption.
The method of claim 13 or claim 14, further comprising:

including a description of the digital asset in a published listing of digital assets managed by the digital asset management system.
A method, at a digital asset management system, for detecting at least one user associated with a digital asset, the method comprising:

receiving a request to identify one or more users associated with a watermarked digital asset, the request being associated with a user identification of a requestor, wherein the watermarked digital asset has been watermarked to embed digital information uniquely indicative of at least one of an owner user or a recipient user;

extracting the embedded digital information from the watermarked digital asset;

determining at least an identification of the recipient user from the extracted digital information; and

providing at least the identification of the recipient user in response to the request.
The method of claim 16, wherein both an identification of the owner user and the identification of the recipient user are determined from the extracted digital information, the method further comprising:

comparing the identification of the owner user with the user identification of the requestor; and

providing at least the identification of the recipient user when the user identification of the requestor matches the identification of the owner user.
The method of claim 16 or 17, further comprising:

determining an asset type of the watermarked digital asset;

determining a watermarking technique that was used to embed the digital information in the watermarked digital asset, based on the asset type; and

performing the extracting based on the determined watermarking technique.
The method of claim 18, wherein the asset type is indicated in the request and the asset type is determined from the request.
A method, at a digital asset management system, for tracing a transaction associated with a digital asset, the method comprising:

receiving a request to trace a transaction associated with a digital asset, the request including at least one of an identification of an owner user or an identification of a recipient user;

obtaining an original copy of the digital asset;

generating a hash based on the digital asset;

searching a blockchain to identify a non-fungible token (NFT) having a hash matching the generated hash;

extracting, from the identified NFT, a contract address for locating a smart contract on the blockchain;

extracting, from the smart contract, transaction information related to the digital asset; and

providing the extracted transaction information in response to the request.
The method of claim 20, wherein the request includes the identification of the owner user, the method further comprising:

prior to providing the extracted transaction information, comparing a user identification in the extracted transaction information with the identification of the owner user included in the request; and

providing the extracted transaction information in response to the user identification in the extracted transaction information matching the identification of the owner user.
The method of claim 20 or 21, wherein generating the hash comprises:

generating a watermarked digital asset by watermarking the original copy of the digital asset to embed digital information uniquely indicative of at least one of the identification of the owner user or the identification of the recipient user;

encrypting the watermarked digital asset using an encryption key of the recipient user; and

generating the hash from the encrypted watermarked digital asset.
The method of claim 20 or claim 21, wherein generating the hash comprises:

generating a watermarked digital asset by watermarking the original copy of the digital asset to embed digital information uniquely indicative of at least one of the identification of the owner user or the identification of the recipient user; and

generating the hash from the watermarked digital asset.
The method of claim 22 or claim 23, further comprising:

determining an asset type of the digital asset;

determining an appropriate watermarking technique based on the asset type; and

generating the watermarked digital asset using the determined appropriate watermarking technique.
The method of claim 24, wherein the asset type is indicated in the request and the asset type is determined from the request.
The method of claim 20 or 21, wherein generating the hash comprises:

generating the hash from the original copy of the digital asset.
The method of any one of claims 20 to 26, wherein obtaining the original copy of the digital asset comprises receiving the original copy of the digital asset with the request.
The method of any one of claims 20 to 26, wherein obtaining the original copy of the digital asset comprises retrieving the original copy of the digital asset from a storage of the digital asset management system.
A computer-implemented digital asset management system comprising:

a processing unit configured to execute instructions to cause the system to perform the method of any one of claims 1 to 28.
The system of claim 29, wherein the processing unit is configured to execute instructions to cause the system to implement:

a content-addressable storage as the digital asset storage.
The system of claim 29, wherein the processing unit is configured to execute instructions to cause the system to:

communicate with a remote storage system providing the digital asset storage.
A non-transitory computer readable medium having instructions stored thereon, wherein the instructions are executable by a processing unit of a computer-implemented digital asset management system to cause the system to perform the method of any one of claims 1 to 28.