How to validate ownership and authentication of digital assets

Abstract

A computer-implemented method for validating ownership of a digital asset is disclosed. The computer-implemented method includes, in response to receiving a request for a public key for encrypting a digital asset, sending the public key to an owner of the digital asset. The computer-implemented method further includes receiving an encrypted digital asset and a first liveness hash from the owner of the digital asset, where the digital asset is encrypted using the public key and the first liveness hash is generated at least in part based on an unencrypted form of the digital asset and a first nonce. The computer-implemented method further includes determining whether the first liveness hash is valid. In response to determining that the first liveness hash is valid, the computer-implemented method further includes generating a digital asset record, where the digital asset record includes the encrypted digital asset and the first liveness hash.

Description

[Technical Field]

[0001] The present invention relates generally to the field of digital assets, and more particularly to authenticating digital assets and validating ownership of digital assets.

[0002] A blockchain is a shared, immutable ledger that facilitates the process of recording transactions and tracking assets in a business network. Assets can be tangible (houses, cars, cash, land) or intangible (intellectual property, patents, copyrights, brands). A non-fungible token (NFT) is a record on a blockchain associated with a specific digital or physical asset. NFT minting is the process of taking a digital file and converting it into a digital asset that can be stored on a blockchain. Once an NFT becomes a digital asset, it becomes negotiable and can be sold via a smart contract. A smart contract is a computer program or transaction protocol intended to automatically execute, control, or document legally relevant events and actions according to the terms of a contract or agreement. For example, when an NFT is transferred from one cryptocurrency wallet to another, the smart contract attached to the NFT is executed. A cryptocurrency wallet is a device, physical medium, program, or service that stores public and / or private keys for cryptocurrency transactions. Ownership of NFTs is recorded on the blockchain and can be transferred by owners, allowing NFTs to be sold and traded.

[0003] During the minting process, an NFT is created when the blockchain concatenates a record containing a cryptographic hash—a set of characters that identifies a set of data—onto a previous record, creating a chain of identifiable blocks of data. This cryptographic transaction process ensures the authentication of each digital asset by providing a digital signature that tracks ownership of the NFT. Digital assets are often downloadable from well-known repositories. Digital assets can also be held, sold, traded, or offered for sale on many different platforms or marketplaces. This means that someone can take a digital asset from one platform and create a replica in the image of the original digital asset on another platform or marketplace.

[0004] A cryptocurrency wallet is a device, physical medium, program, or service that stores public and / or private keys for cryptocurrency transactions. A cryptocurrency wallet is associated with a public key and a private key. The public key functions like an email address: it can be securely shared with others, allowing a person to send or receive assets. However, the private key is a secure code that allows digital asset holders to make transactions and prove ownership of their digital assets. The private key is typically a string of letters and numbers. The public key allows a person to receive cryptocurrency transactions. While anyone can send transactions to the public key, the private key is needed to "unlock" them and prove that they are the owner of the cryptocurrency received in the transaction.

[0005] With the advent of blockchain technology, content creators can now digitize their works and sell them on marketplaces as NFTs. One drawback of NFTs is that anyone can access the URL and download the asset from the repository using the link in the NFT. They can then mint a new NFT on another NFT marketplace and claim ownership of the asset. The next challenge is proving true ownership of the asset.

[0006] US20200242105A1 explains: "A distributed computing platform and method for creating utility digital assets and tokens (KNFTs) incorporating influence and outreach. A KNFT application server may be configured to receive requests for new non-fungible tokens from remote computing nodes via a distributed computing network, where the KNFT includes a unique KNFT identifier, at least one metadata element, and at least one social vector. ... The social action may include a user comment, connection, direct message, like, or favorable rating, and changes in ownership of the KNFT may be written to the social vector via a KNFT API. The social vector may include social vector data from at least one previous owner, and the KNFT may further include a circulation trail vector incorporating the ownership history of the KNFT." This reference fails to solve the problem of providing a secure mechanism for authenticating digital asset transactions on a ledger. Advantageously, embodiments of the present invention recognize the need and importance for a way to protect digital assets by providing a secure mechanism for authenticating digital asset transactions. Embodiments of the present invention solve this problem on a ledger by using liveness hashing for verification.

[0007] Another way to prevent digital asset fraud is to check against other registered or known marketplaces. Currently, when an NFT is generated, the metadata required to download the original asset may often be embedded as part of the NFT. Thus, anyone with access to the metadata may be able to download the original asset. This creates opportunities for counterfeiting, among other vulnerabilities. Furthermore, the asset itself may be stored on some third-party website, which may go out of business at some point, resulting in the loss of the original asset. However, embodiments of the present invention recognize that minting a digital asset using an encrypted image increases the likelihood of determining the authenticity of the digital asset.

[0008] Existing NFT creation and validation processes are publicly available. Existing NFT minting processes involve an image hash and the image's URL in an object store. This means that anyone can validate the hash with the asset hash or address in the NFT, calculate the hash, and verify the match. Furthermore, it is easy to commit NFT theft by copying the asset, creating a hash, and minting another NFT with the same image on either the same or a different platform. Embodiments of the present invention solve this problem through asset location and liveness hashing. Furthermore, the referenced asset is encrypted. In embodiments of the present invention, ownership validation does not rely on data in the NFT. In embodiments of the present invention, the claimant supplies a nonce, and the owner repository performs liveness hashing to prove ownership. Summary of the Invention

[0009] According to one embodiment of the present invention, a computer-implemented method for validating ownership of a digital asset is disclosed. The computer-implemented method includes one or more processors, in response to receiving a request for a public key for encrypting a digital asset, sending the public key to an owner of the digital asset. The computer-implemented method further includes the one or more processors receiving an encrypted digital asset and a first liveness hash from the owner of the digital asset, where the digital asset is encrypted using the public key and the first liveness hash is generated at least in part based on an unencrypted form of the digital asset and a first nonce. The computer-implemented method further includes, in response to receiving the first nonce and the first liveness hash from the encrypted digital asset from the owner of the digital asset, determining whether the first liveness hash is valid. The computer-implemented method further comprises generating a digital asset record in response to the one or more processors determining that the first liveness hash is valid, wherein the digital asset record includes the encrypted digital asset and the first liveness hash. Embodiments of the present invention are advantageous for generating a liveness hash instead of a hash.

[0010] According to another embodiment of the present invention, a computer program product for validating ownership of a digital asset is disclosed. The computer program product comprises one or more computer-readable storage media and program instructions stored on the one or more computer-readable storage media. The program instructions include instructions for, in response to receiving a request for a public key for encrypting a digital asset, sending the public key to an owner of the digital asset. The program instructions further include instructions for receiving an encrypted digital asset and a first liveness hash from the owner of the digital asset, where the digital asset is encrypted using the public key and the first liveness hash is generated at least in part based on an unencrypted form of the digital asset and a first nonce. The program instructions further include instructions for, in response to receiving the first nonce and the first liveness hash from the encrypted digital asset from the owner of the digital asset, determining whether the first liveness hash is valid. The program instructions further include instructions for generating a digital asset record in response to determining that the first liveness hash is valid, wherein the digital asset record includes the encrypted digital asset and the first liveness hash. Embodiments of the present invention are advantageous for generating a liveness hash instead of a hash.

[0011] According to another embodiment of the present invention, a computer system for validating ownership of a digital asset is disclosed. The computer system includes one or more computer processors, one or more computer-readable storage media, and computer program instructions stored on the one or more computer-readable storage media for execution by the one or more computer processors. The program instructions include instructions for, in response to receiving a request for a public key for encrypting a digital asset, sending the public key to an owner of the digital asset. The program instructions further include instructions for receiving an encrypted digital asset and a first liveness hash from the owner of the digital asset, where the digital asset is encrypted using the public key and the first liveness hash is generated at least in part based on an unencrypted form of the digital asset and a first nonce. The program instructions further include instructions for, in response to receiving the first nonce and the first liveness hash from the encrypted digital asset from the owner of the digital asset, determining whether the first liveness hash is valid. The program instructions further include instructions for generating a digital asset record in response to determining that the first liveness hash is valid, wherein the digital asset record includes the encrypted digital asset and the first liveness hash. Embodiments of the present invention are advantageous for generating a liveness hash instead of a hash.

[0012] According to another embodiment of the present invention, a computer-implemented method for validating ownership of a digital asset is disclosed. The computer-implemented method includes one or more processors receiving a request from a requesting entity to provide proof of ownership of the digital asset to an owner of the digital asset, the request including a first nonce. The computer-implemented method further includes responding to receiving the request to provide proof of ownership of the digital asset to the owner of the digital asset. The computer-implemented method further includes the one or more processors sending the first nonce to the owner of the digital asset. The computer-implemented method further includes the one or more processors receiving, from the owner of the digital asset, an image ID and a first liveness hash associated with the digital image. The computer-implemented method further includes the one or more processors validating the proof of ownership of the digital asset. Embodiments of the present invention are advantageous for generating a liveness hash instead of a hash. [Brief explanation of the drawings]

[0013] The drawings included in this disclosure are incorporated in and form a part of this specification. They illustrate embodiments of the present disclosure and, together with the description, serve to explain the principles of the present disclosure. The drawings are merely illustrative of particular embodiments and are not intended to limit the disclosure.

[0014] [Figure 1] FIG. 1 is a functional block diagram of a computing environment, generally designated 100, suitable for execution of at least a portion of the computer code involved in performing the methodology of the present invention, such as digital asset ownership validation code 150, in accordance with at least one embodiment of the present invention.

[0015] [Figure 2A] 2 illustrates an exemplary blockchain architecture configuration, generally designated 200, in accordance with at least one embodiment of the present invention.

[0016] [Figure 2B] 2 illustrates a blockchain transaction flow, generally designated 250, in accordance with at least one embodiment of the present invention.

[0017] [Figure 3] FIG. 3 is a functional block diagram of a digital asset ownership validation system, generally designated 300, suitable for operation of a digital asset transaction program 301, in accordance with at least one embodiment of the present invention.

[0018] [Figure 4] FIG. 4 is a flowchart diagram illustrating operational steps for a digital asset ownership validation program 301, generally designated 400, in accordance with at least one embodiment of the present invention.

[0019] [Figure 5] FIG. 5 is a flowchart diagram illustrating operational steps for a digital asset ownership validation program 301, generally designated 500, in accordance with at least one embodiment of the present invention.

[0020] [Figure 6] FIG. 6 is a flow chart diagram illustrating operational steps, generally designated 600, for registering image processing in accordance with at least one embodiment of the present invention.

[0021] [Figure 7] FIG. 7 is a flow chart diagram illustrating operational steps for registering image processing, generally designated 700, in accordance with at least one embodiment of the present invention.

[0022] [Figure 8A] 8 illustrates an exemplary system, generally designated 800, configured to perform one or more operations described herein, in accordance with at least one embodiment of the present disclosure.

[0023] [Figure 8B] 8 illustrates another exemplary system, generally designated 840, configured to perform one or more operations described herein, in accordance with at least one embodiment of the present disclosure.

[0024] [Figure 8C] 8 illustrates a further exemplary system configured to utilize smart contracts, generally designated 850, in accordance with at least one embodiment of the present disclosure.

[0025] [Figure 8D] 8 illustrates yet another exemplary system configured to utilize blockchain, generally designated 860, in accordance with at least one embodiment of the present disclosure.

[0026] [Figure 9A] 9 illustrates a process by which a new block is added to a distributed ledger, generally designated 900, in accordance with at least one embodiment of the present disclosure.

[0027] [Figure 9B] 9 illustrates the contents of a new data block, generally designated 930, in accordance with at least one embodiment of the present disclosure.

[0028] [Figure 9C] 9 illustrates a blockchain for digital content, generally designated 970, in accordance with at least one embodiment of the present disclosure.

[0029] [Figure 9D] 9 illustrates a block that may represent the structure of a block in a blockchain, generally designated 990, in accordance with at least one embodiment of the present disclosure.

[0030] While the embodiments described herein are amenable to various modifications and alternative forms, specific features thereof have been shown by way of example in the drawings and will be described in detail. It is to be understood, however, that the particular embodiments described are not to be construed in a limiting sense. On the contrary, the intention is to cover all modifications, equivalents, and alternatives falling within the spirit and scope of the present disclosure. DETAILED DESCRIPTION OF THE INVENTION

[0031] The present invention relates generally to the field of digital assets, and more particularly to authenticating digital assets and validating ownership of digital assets.

[0032] An NFT is a blockchain ledger entry / token that represents a unique physical or digital (non-fungible) asset. The current NFT minting process reveals a digital asset either directly by posting the asset on a blockchain ledger, or indirectly by posting the asset's location along with access information along with the asset's hash on a ledger entry. Digital asset validation is performed by comparing the hash stored in the NFT with the hash of the original asset.

[0033] Proof of ownership is a challenge from another client to the current owner to validate that the owner has access to the original digital asset. An NFT functions like a certificate of ownership, with a means for validation via a smart contract, a pointer to the asset, and other information. Like other certificates, this does not prevent fraud or theft because the solution is one-sided. An asset can only be validated against the blockchain instance on which it is stored, which does not prevent the asset from being stolen and the subsequent minting of a new NFT on another blockchain instance. This is especially true for digital assets that are too large to be encoded as part of the NFT. Without the ability to reference the NFT information from the asset, it is impossible to prove ownership of the asset and therefore does not reduce fraud. Current solutions include services for validating NFTs, checking for the existence of an NFT within a blockchain instance, adding social network vectors to an NFT, or scanning public sources for similar technology areas. When an NFT is minted, a token ID on the blockchain is returned. An NFT contains a reference to the original work and may include associated information needed to access the original work or a token to the original work if stored on a ledger. Embodiments of the present invention include a solution for proving ownership of an original asset without disclosing the ownership credentials or the original asset.

[0034] The current NFT minting process allows for local asset validation by the client and a ledger registry to track ownership without proof. Asset validation is performed by performing a hash of the asset and comparing the result to the hash stored in the NFT. This requires the asset to be globally visible, which allows any malicious actor to download the asset, mint a new NFT, claim ownership, and post it to the ledger. Embodiments of the present invention enhance the NFT minting process by using live hashes instead of regular hashes.

[0035] Embodiments of the present invention use encrypted digital assets when minting NFTs and enable ownership validation, allowing any potential purchaser of an NFT to confidently trust that the current owner of that NFT is legitimate. Because the digital asset is encrypted, image validation is performed by a smart contract. The smart contract runs on a node in a Trusted Execution Environment (TEE) and ensures that unencrypted assets are never revealed, ultimately resulting in a validation process that is trusted by all parties. The same validation smart contract is then used to prove ownership of the digital asset.

[0036] Embodiments of the present invention generate a nonce. A nonce is an arbitrary number that can be used only once in a cryptographic communication. A nonce is often a random or pseudo-random number used in authentication protocols to ensure that old communications cannot be fraudulently used. Embodiments of the present invention require the requester to supply the nonce, and the owner repository performs a liveness hash to prove ownership. Embodiments of the present invention improve on current methods by using a derived hash instead of a raw hash, making unauthorized copying more difficult.

[0037] Embodiments of the present invention improve upon existing NFT minting processes by using a liveness hash instead of a regular hash. Embodiments of the present invention prevent NFT fraud and theft by never revealing the original digital asset to potential malicious actors, securing all operations by referencing an encrypted instance of the original asset, preventing fraudulent validations by using a liveness hash, using smart contracts for the minting and validation process, and utilizing a secure environment for executing the smart contracts. Embodiments of the present invention perform registry operations within a ledger, thereby preventing single points of failure and providing the enhanced security provided by a blockchain environment.

[0038] Embodiments of the present invention perform verification by comparing a liveness hash provided by the digital asset owner with a liveness hash created by the smart contract. The liveness hash includes a hash of the combined hash of the decrypted digital image and a nonce. The entity requesting verification provides a nonce to be used in the liveness hash. Embodiments of the present invention use the nonce as a seed in the hashing algorithm. Providing a nonce ensures that the liveness hash must be calculated. Furthermore, it prevents a value cached by the digital asset owner from being used during verification.

[0039] Various aspects of the present disclosure are described through text, flowcharts, block diagrams of computer systems, and / or block diagrams of machine logic included in computer program product (CPP) embodiments. For any flowchart, depending on the technology involved, operations may be performed in an order different from that shown in a given flowchart. For example, again depending on the technology involved, two operations shown in successive flowchart blocks may be performed in reverse order, as a single integrated step, simultaneously, or in an at least partially overlapping manner.

[0040] A computer program product embodiment ("CPP embodiment" or "CPP") is a term used in this disclosure to describe any set of one or more storage media (also referred to as "media") collectively contained in one or more storage devices that collectively contain machine-readable code corresponding to instructions and / or data for performing the computer operations specified in a given CPP claim. A "storage device" is any tangible device that can hold and store instructions for use by a computer processor. The computer-readable storage medium may be, but is not limited to, an electronic storage medium, a magnetic storage medium, an optical storage medium, an electromagnetic storage medium, a semiconductor storage medium, a mechanical storage medium, or any suitable combination of the foregoing. Some known types of storage devices that include these media include diskettes, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), static random access memory (SRAM), compact disc read-only memory (CD-ROM), digital versatile disk (DVD), memory stick, floppy disk, mechanically encoded device (such as a punch card or pits / lands formed on a major surface of a disk), or any suitable combination of the foregoing. Computer-readable storage media, as the term is used in this disclosure, is not to be construed as storage in the form of a transitory signal per se, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through a waveguide, light pulses passing through fiber optic cables, electrical signals communicated through wires, and / or other transmission media.As will be appreciated by those skilled in the art, data is typically moved at some infrequent time during the normal operation of a storage device, such as during access, defragmentation, or garbage collection, but this does not make the storage device temporary because the data is not temporary while it is stored.

[0041] While the descriptions of various embodiments of the present invention have been presented for illustrative purposes, they are not intended to be exhaustive or limited to the disclosed embodiments. Many modifications and variations will be apparent to those skilled in the art without departing from the scope and spirit of the described embodiments. The terminology used herein has been chosen to best explain the principles, practical applications, or technical improvements of the embodiments over technologies found in the marketplace, or to enable others skilled in the art to understand the embodiments disclosed herein.

[0042] The flowcharts and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present invention. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of instructions, including one or more executable instructions, that implements a specified logical function. In some alternative implementations, the functions noted in the blocks may occur in an order other than that noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may possibly be executed in the reverse order, depending on the functionality involved. It should also be noted that each block of the block diagrams and / or flowchart diagrams, and combinations of blocks in the block diagrams and / or flowchart diagrams, may be implemented by a dedicated hardware-based system that performs the specified functions or operations, or that executes a combination of dedicated hardware and computer instructions.

[0043] The present invention will now be described in detail with reference to the figures. Figure 1 is a functional block diagram of a computing environment, generally designated 100, suitable for execution of at least a portion of the computer code involved in performing the method of the present invention, such as digital asset ownership validation code stored in block 150, in accordance with at least one embodiment of the present invention. In addition to block 150, computing environment 100 includes, for example, computer 101, wide area network (WAN) 102, end user device (EUD) 103, remote server 104, public cloud 105, and private cloud 106. In this embodiment, computer 101 includes a processor set 110 (including processing circuitry 120 and cache 121), a communications fabric 111, volatile memory 112, persistent storage 113 (including operating system 122 and the above-identified blocks 150), a peripheral device set 114 (including a user interface (UI) device set 123, storage 124, and an Internet of Things (IoT) sensor set 125), and a network module 115. The remote server 104 includes a remote database 130. The public cloud 105 includes a gateway 140, a cloud orchestration module 141, a set of host physical machines 142, a set of virtual machines 143, and a set of containers 144.

[0044] Computer 101 may take the form of a desktop computer, a laptop computer, a tablet computer, a smartphone, a smartwatch or other wearable computer, a mainframe computer, a quantum computer, or any other form of computer or mobile device now known or later developed that is capable of executing programs, accessing a network, or querying a database, such as remote database 130. As is well understood in the field of computer technology, and depending on the technology, execution of a computer-implemented method may be distributed among multiple computers and / or multiple locations. However, in this presentation of computing environment 100, to keep the presentation as simple as possible, the detailed discussion focuses on a single computer, specifically computer 101. Although computer 101 is not shown in FIG. 1 within a cloud, it may be located within a cloud. However, computer 101 is not required to reside within a cloud except to any extent that may be expressly indicated.

[0045] Processor set 110 includes one or more computer processors of any type now known or to be developed in the future. Processing circuitry 120 may be distributed across multiple packages, e.g., multiple tailored integrated circuit chips. Processing circuitry 120 may implement multiple processor threads and / or multiple processor cores. Cache 121 is memory located within the processor chip package and is typically used for data or code that should be available for fast access by threads or cores executing on processor set 110. Cache memory is typically organized into multiple levels depending on relative proximity to the processing circuitry. Alternatively, some or all caches for a processor set may be located “off-chip.” In some computing environments, processor set 110 may be designed to operate with qubits and perform quantum computing.

[0046] Computer-readable program instructions are typically loaded onto computer 101 and cause processor set 110 of computer 101 to execute a series of operational steps, thereby enabling a computer-implemented method, such that the instructions so executed instantiate the methods specified in the computer-implemented method flowcharts and / or descriptions contained herein (collectively referred to as the "methods of the present invention"). These computer-readable program instructions are stored in various types of computer-readable storage media, such as cache 121 and other storage media discussed below. The program instructions and associated data are accessed by processor set 110 to control and direct the execution of the methods of the present invention. In computing environment 100, at least a portion of the instructions for executing the methods of the present invention may be stored in block 150 in persistent storage 113.

[0047] Communications fabric 111 is the signal-conducting pathway that allows various components of computer 101 to communicate with one another. Typically, this fabric is made up of switches and conductive pathways, such as those that make up buses, bridges, physical input / output ports, and the like. Other types of signal communication pathways may be used, such as fiber optic and / or wireless communication pathways.

[0048] Volatile memory 112 may be any type of volatile memory now known or later developed. Examples include dynamic random access memory (RAM) or static RAM. Typically, volatile memory 112 is characterized by random access, although this is not required unless expressly indicated. In computer 101, volatile memory 112 is located in a single package and is internal to computer 101; however, alternatively or additionally, volatile memory may be distributed across multiple packages and / or located external to computer 101.

[0049] Persistent storage 113 is any form of non-volatile storage for a computer, now known or later developed. The non-volatility of this storage means that stored data is maintained regardless of whether power is supplied to computer 101 and / or to persistent storage 113 directly. While persistent storage 113 can be read-only memory (ROM), typically at least a portion of persistent storage allows data to be written, data to be deleted, and data to be rewritten. Some well-known forms of persistent storage include magnetic disks and solid-state storage devices. Operating system 122 can take several forms, including various known proprietary operating systems or open-source Portable Operating System Interface types that employ a kernel. The code contained in block 150 typically includes at least a portion of the computer code involved in performing the methods of the present invention.

[0050] The peripheral device set 114 includes a set of peripheral devices of the computer 101. Data communication connections between the peripheral devices and other components of the computer 101 can be implemented in various ways, such as Bluetooth connections, Near-Field Communication (NFC) connections, connections made by cable (such as a universal serial bus (USB)-type cable), insertion-type connections (e.g., a secure digital (SD) card), connections made through a local area communication network, and even connections made through a wide area network such as the Internet. In various embodiments, the UI device set 123 can include components such as a display screen, speakers, microphones, wearable devices (such as goggles and smartwatches), keyboards, mice, printers, touchpads, game controllers, and haptic devices. The storage 124 can be external storage, such as an external hard drive, or insertable storage, such as an SD card. The storage 124 can be persistent and / or volatile. In some embodiments, storage 124 may take the form of a quantum computing storage device for storing data in the form of qubits. In embodiments where computer 101 is required to have a large amount of storage (e.g., where computer 101 stores and manages large databases locally), this storage may be provided by a peripheral storage device designed to store very large amounts of data, such as a storage area network (SAN) shared by multiple geographically distributed computers. IoT sensor set 125 is made up of sensors that may be used in Internet of Things applications. For example, one sensor may be a thermometer and another may be a motion detector.

[0051] Network module 115 is a collection of computer software, hardware, and firmware that enables computer 101 to communicate with other computers over WAN 102. Network module 115 may include hardware such as a modem or Wi-Fi signal transceiver, software for packetizing and / or depacketizing data for communication network transmission, and / or web browser software for communicating data over the Internet. In some embodiments, the network control and network forwarding functions of network module 115 are performed on the same physical hardware device. In other embodiments (e.g., embodiments utilizing Software-Defined Networking (SDN)), the control and forwarding functions of network module 115 are performed on physically separate devices, such that the control function manages multiple different network hardware devices. Computer-readable program instructions for implementing the methods of the present invention may be downloaded to computer 101, typically from an external computer or external storage device, through a network adapter card or network interface included in network module 115.

[0052] WAN 102 is any wide area network (e.g., the Internet) capable of communicating computer data over non-local distances by any now known or later developed technology for communicating computer data. In some embodiments, WAN 102 may be replaced and / or supplemented by a local area network (LAN) designed to communicate data between devices located in a local area, such as a Wi-Fi network. WANs and / or LANs typically include computer hardware such as copper transmission cables, optical fiber transmissions, wireless transmissions, routers, firewalls, switches, gateway computers, and edge servers.

[0053] End-user device (EUD) 103 is any computer system used and controlled by an end user (e.g., a customer of the enterprise operating computer 101) and may take any of the forms discussed above in connection with computer 101. EUD 103 typically receives useful and useful data from the operation of computer 101. For example, in a hypothetical case where computer 101 is designed to provide recommendations to the end user, the recommendations would typically be communicated from computer 101's network module 115 over WAN 102 to EUD 103. In this manner, EUD 103 can display or otherwise present the recommendations to the end user. In some embodiments, EUD 103 may be a client device, such as a thin client, a heavy client, a mainframe computer, a desktop computer, and the like.

[0054] Remote server 104 is any computer system that provides at least some data and / or functionality to computer 101. Remote server 104 may be controlled and used by the same entity that operates computer 101. Remote server 104 represents a machine that collects and stores useful and useful data for use by other computers, such as computer 101. For example, in the hypothetical case where computer 101 is designed and programmed to provide recommendations based on past data, then this past data may be provided to computer 101 from remote database 130 of remote server 104.

[0055] A public cloud 105 is any computer system available for use by multiple entities that provides on-demand availability of computer system resources and / or other computer functionality, particularly data storage (cloud storage) and computing power, without direct active management by users. Cloud computing typically leverages resource sharing to achieve coherence and economies of scale. Direct active management of the computing resources of the public cloud 105 is performed by computer hardware and / or software in a cloud orchestration module 141. The computing resources provided by the public cloud 105 are typically implemented by virtual computing environments running on various computers comprising a host physical machine set 142, which is the universe of physical computers within and / or available in the public cloud 105. A virtual computing environment (VCE) typically takes the form of virtual machines from a virtual machine set 143 and / or containers from a container set 144. It is understood that these VCEs may be stored as images and transferred among and between various hosts of physical machines either as images or after instantiation of the VCE. Cloud orchestration module 141 manages the transfer and storage of images, deploys new instantiations of VCEs, and manages active instantiations of VCE deployments. Gateway 140 is a collection of computer software, hardware, and firmware that enables public cloud 105 to communicate over WAN 102.

[0056] Some further discussion of virtualized computing environments (VCEs) is now provided. A VCE can be stored as an "image." A new, active instance of a VCE can be instantiated from an image. Two well-known types of VCEs are virtual machines and containers. A container is a VCE that uses operating system-level virtualization. This refers to a feature of an operating system in which the kernel allows the existence of multiple isolated user space instances, called containers. These isolated user space instances typically behave as actual computers from the perspective of programs running within them. A computer program running on a typical operating system can utilize all of the computer's resources, such as connected devices, files and folders, network shares, CPU power, and quantifiable hardware capabilities. However, a program running inside a container can only use the contents of the container and of the devices assigned to the container; this feature is known as containerization.

[0057] A private cloud 106 is similar to a public cloud 105, except that its computing resources are available only for use by a single enterprise. While the private cloud 106 is shown in communication with the WAN 102, in other embodiments, the private cloud may be completely disconnected from the Internet and accessible only through a local / private network. A hybrid cloud is a composite of multiple clouds of different types (e.g., private, community, or public cloud types), often each implemented by a different vendor. While each of the multiple clouds remains a separate, discrete entity, the larger hybrid cloud architecture is bound together by standardized or proprietary technologies that enable orchestration, management, and / or data / application portability between the constituent clouds. In this embodiment, both the public cloud 105 and the private cloud 106 are part of a larger hybrid cloud.

[0058] FIG. 2A illustrates an exemplary blockchain architecture configuration in accordance with at least one embodiment of the present invention. The blockchain architecture 200 may include a group of specific blockchain elements, e.g., blockchain nodes 202. The blockchain nodes 202 may include one or more nodes 204-210 (these four nodes are shown merely by way of example). These nodes participate in multiple activities, such as blockchain transaction addition and validation processes (consensus). The blockchain nodes may initiate blockchain validation and attempt to write to a blockchain immutable ledger stored in a blockchain layer 216, a copy of which may also be stored on the underlying physical infrastructure 214. The blockchain configuration may include one or more applications 224 linked to an application programming interface (API) 222 to access and execute stored program / application code 220 (e.g., chaincode, smart contracts, etc.), which may be created according to customized configurations desired by participants and can maintain their own state, control their own assets, and receive external information. This can be deployed as a transaction and installed on all blockchain nodes 204 to 210 via an append to the distributed ledger.

[0059] The blockchain base or platform 212 may include various layers of blockchain data, services (e.g., cryptographic trust services, virtual execution environments, etc.), and underlying physical computer infrastructure that may be used to receive and store new transactions and provide access to auditors attempting to access data entries. The blockchain layer 216 may expose interfaces that provide access to the virtual execution environments necessary to process program code and engage the physical infrastructure 214. The cryptographic trust services 218 may be used to verify transactions, such as asset exchange transactions, and keep information confidential.

[0060] The blockchain architecture configuration of FIG. 2A may process and execute program / application code 220 through one or more interfaces and services exposed by the blockchain platform 212. The code 220 may control blockchain assets. For example, the code 220 may store and transfer data and, along with other code elements subject to conditions or their execution, may be executed by nodes 204-210 in the form of smart contracts and associated chaincode. As a non-limiting example, smart contracts may be created to perform tasks such as creating storage space, reserving storage space, updating current transaction agreements, etc. The smart contract itself may be used to identify authentication and access requirements and rules associated with ledger usage. For example, document attribute information 226 may be processed by one or more processing entities (e.g., virtual machines) included in the blockchain layer 216. Results 228 may include multiple linked shared documents (e.g., each linked shared document recording a smart contract issuance, etc.). The physical infrastructure 214 may be utilized to retrieve any of the data or information described herein.

[0061] Smart contracts may be created using high-level application and programming languages ​​and then written into blocks within a blockchain. Smart contracts may include executable code that is registered, stored, and / or replicated on a blockchain (e.g., a decentralized network of blockchain peers). A transaction is the execution of smart contract code that may be executed in response to a condition associated with a smart contract being satisfied. Execution of a smart contract may trigger trusted modifications to the state of a digital blockchain ledger. Modifications to the blockchain ledger caused by smart contract execution may be automatically replicated across a decentralized network of blockchain peers through one or more consensus protocols.

[0062] Smart contracts can write data to the blockchain in the format of key-value pairs. Additionally, smart contract code can read values ​​stored in the blockchain and use them in application operations. Smart contract code can write the output of various logical operations to the blockchain. This code can be used to create temporary data structures within a virtual machine or other computing platform. Data written to the blockchain can be public and / or encrypted and kept private. The temporary data used / generated by smart contracts is kept in memory by the provided execution environment and then deleted once the required data for the blockchain has been identified.

[0063] Chaincode may include a code interpretation of a smart contract with additional features. As described herein, chaincode may be program code deployed on a computing network, where it is executed and validated together during a consensus process by a chain validator. The chaincode receives the hash and retrieves from the blockchain a hash associated with a data template created by using a previously stored feature extractor. If the hash of the hash identifier and the hash created from the stored identifier template data match, the chaincode sends an authentication key to the requested service. The chaincode may write data associated with cryptographic details to the blockchain data (e.g., thus establishing a new smart contract between the user and the licensor).

[0064] FIG. 2B illustrates an example of a blockchain transaction flow 250 between nodes of a blockchain, in accordance with at least one embodiment of the present invention. Referring to FIG. 2B, the transaction flow may include a transaction proposal 291 sent by an application client node 260 to an endorsing peer node 281 (e.g., in some embodiments, the transaction proposal 291 may be sent to determine or authenticate ownership of a digital asset). The endorsing peer 281 may verify the client signature and execute a chaincode function to initiate the transaction. Outputs may include a chaincode result, a set of key / value versions read in the chaincode (the read set), and a set of keys / values ​​written to the chaincode (the write set). A proposal response 292, if approved, is sent back to the client 260 along with an approval signature. The client 260 assembles the approval into a transaction payload 293 and broadcasts it to the ordering service node 284. The ordering service node 284 then distributes the ordered transaction as a block to all peers 281-283 on the channel. Before committing to the blockchain, each peer 281-283 may validate the transaction. For example, the peer may check transaction conditions, ownership, or other digital asset data to ensure accurate allocation and distribution of assets for the transaction payload 293.

[0065] Referring again to FIG. 2B, a client node 260 initiates a transaction 291 by constructing a request and sending it to a peer node 281, which is an approver. The client 260 may include an application that utilizes a supported software development kit (SDK) to generate a transaction proposal using available APIs. The proposal is a request to invoke chaincode functions so that data can be read from and / or written to the ledger (e.g., writing a new key-value pair for an asset). The SDK may package the transaction proposal into a properly architected format (e.g., protocol buffers for remote procedure calls (RPCs)) and act as a shim to obtain the client's cryptographic credentials and generate a unique signature for the transaction proposal.

[0066] In response, the endorsing peer node 281 may verify that (a) the transaction proposal is well-formed, (b) the transaction has not already been submitted previously (replay attack protection), (c) the signature is valid, and (d) the submitter (in this example, client 260) is properly authorized to perform the proposed operation on that channel. The endorsing peer node 281 may obtain the transaction proposal input as an argument to a called chaincode function. The chaincode is then executed against the current state database to generate a transaction result that includes a response value, a read set, and a write set. However, the ledger is not updated at this point. At 292, the set of values, along with the endorsing peer node 281's signature, is returned as a proposal response 292 to the client 260's SDK, which parses the payload for the application to consume.

[0067] In response, the application at the client 260 checks / verifies the endorsing peer signature and compares the proposed response to determine whether the proposed response is the same. If the chaincode only queried the ledger, the application checks the query response and typically does not submit the transaction to the ordering node service 284. If the client application intends to submit a transaction to the ordering node service 284 to update the ledger, the application determines whether the specified endorsement policy has been satisfied (e.g., whether all required peer nodes for the transaction have endorsed the transaction) before submitting. Here, the client may include only one of multiple parties to a transaction. In this case, each client may have its own endorsing node, and each endorsing node must endorse the transaction. This architecture ensures that the endorsement policy is still enforced by peers and maintained during the commit validation phase, even if the application chooses not to check the response or otherwise forwards an unendorsed transaction.

[0068] After successful validation, in step 293, client 260 assembles the approvals into a transaction and broadcasts the transaction proposal and response in a transaction message to ordering node 284. The transaction may include a read / write set, an approval peer signature, and a channel ID. Ordering node 284 does not need to validate the entire contents of the transaction to perform its operation; instead, ordering node 284 may simply receive transactions from all channels in the network, order them chronologically by channel, and create a block of transactions per channel.

[0069] A block of transactions is distributed from the ordering node 284 to all peer nodes 281-283 on the channel. The transactions 294 within the block are validated to ensure that any authorization policies are satisfied and to ensure that no changes have been made to the ledger state with respect to the readset variable since the transaction execution generated the readset. The transactions within the block are tagged as valid or invalid. Furthermore, in step 295, each peer node 281-283 appends the block to the channel's chain, and for each valid transaction, the writeset is committed to the current state database. An event is emitted to notify the client application that the transaction (invocation) has been immutably appended to the chain, and whether the transaction was validated or not.

[0070] Figure 3 is a functional block diagram of a digital asset ownership validation system, generally designated 300, suitable for operation of a digital asset transaction program 301, in accordance with at least one embodiment of the present invention. As described with reference to Figure 1, digital asset ownership validation system 300 may be implemented within a computing environment, such as computing environment 100. Figure 3 provides an illustration of only one implementation and does not suggest any limitations with regard to the environments in which different embodiments may be implemented. Many modifications to the depicted environment may be made by one skilled in the art without departing from the scope of the present invention, as recited by the claims.

[0071] Digital asset ownership validation system 300 includes a user device 310, a server 320, a smart contract 330, a distributed ledger 350, ledgers 360A and 360B, blockchains 370A and 370B, blockchain nodes 380A-380N, and TEEs 390A-390N, interconnected via a network such as WAN 102. Generally, user device 310 may represent any programmable electronic device or combination of programmable electronic devices capable of executing machine-readable program instructions and communicating with server 320 and other devices (not shown) over a network such as WAN 102. In one embodiment, the user device 310 is an end-user device such as the EUD 103 shown in FIG. 1, and may be a mobile device, a laptop computer, a tablet computer, a netbook computer, a personal computer, a desktop computer, a personal digital assistant (PDA), a smartphone, a wearable device (e.g., smart glasses, a smart watch, an e-textile, an AR headset, etc.), or any programmable computer system known in the art.

[0072] User device 310 further includes a user interface 312, applications 314, and a wallet 316. User interface 312 is a program that provides an interface between a user of an end-user device, such as user device 310, and multiple applications (e.g., applications 314) resident on the device. A user interface, such as user interface 312, refers to the information (e.g., graphics, text, and sound) that a program presents to a user and the control sequences the user employs to control the program. There are various types of user interfaces. In one embodiment, user interface 312 is a graphical user interface. A graphical user interface (GUI) is a type of user interface that allows a user to interact with electronic devices, such as a computer keyboard and mouse, through graphical icons and visual indicators, such as secondary notation, as opposed to text-based interfaces, typed command labels, or text navigation. In computing, GUIs were introduced in response to the perceived steep learning curve of command line interfaces, which require commands to be typed on a keyboard. Actions in a GUI are often performed through direct manipulation of graphical elements. In another embodiment, the user interface 312 is a script or an application programming interface (API).

[0073] Application 314 may represent one or more applications (e.g., a suite of applications) running on user device 310. In one embodiment, application 314 represents one or more applications (e.g., an asset holding application, an asset marketplace application, and an asset authentication application) located on user device 310. For example, a user accesses asset holding software and purchases digital assets through application 314. In another example, a user uploads digital assets online through application 314. In various exemplary embodiments, application 314 may be an application utilized by a user of user device 310 to access an asset marketplace website and post about the sale, trade, offering, or purchase of digital assets. In one embodiment, application 314 may be a client-side application associated with a server-side application executing on server 320 (e.g., a client-side application associated with digital asset ownership validation program 301). In one embodiment, the application 314 may operate to perform the processing steps of the digital asset ownership validation program 301 (i.e., the application 314 may represent the digital asset ownership validation program 301 operating on the user device 310).

[0074] Wallet 316 is a digital or cryptocurrency wallet. In one embodiment, wallet 316 contains information associated with one or more public and private keys corresponding to digital assets. In one embodiment, wallet 316 contains information about one or more digital assets. In one embodiment, the digital assets include NFTs, cryptocurrencies, funds, or other digital assets. In one embodiment, wallet 316 is a hardware cryptocurrency wallet.

[0075] Server 320 is configured to provide resources to various computing devices, such as user device 310. Generally, server 320 represents any programmable electronic device or combination of programmable electronic devices capable of executing machine-readable program instructions and communicating with each other and with user device 310, smart contract 330, and other computing devices (not shown) in a network, such as WAN 102. In one embodiment, server 320 is a standalone device, such as computer 101 shown in FIG. 1, that executes programs and can access a network or query a database. In one embodiment, server 320 may be an administration server, web server, application server, mobile device, or any other electronic device or computing system capable of receiving, transmitting, and processing data. In one embodiment, server 320 represents a server computing system that utilizes multiple computers as a server system. In one embodiment, server 320 represents a computing system that utilizes clustered computers and components (e.g., database server computers, application server computers, web server computers, webmail server computers, media server computers, etc.) that function as a single pool of seamless resources. Server 320 further includes object store 322. In an exemplary embodiment, server 320 further includes digital asset owner verification program 301.

[0076] In one embodiment, object store 322 stores information about digital assets. In one embodiment, object store 322 is an object store service that runs on one or more servers.

[0077] Smart contract 330 includes information about one or more smart contracts attached to or associated with a digital asset. In one embodiment, smart contract 330 includes executable code that is registered, stored, and / or replicated with the blockchain. A transaction is the execution of smart contract code that may be executed in response to a condition associated with a smart contract being satisfied, such as transferring an NFT from one cryptocurrency wallet to another. In one embodiment, digital asset owner verification program 301 accesses a smart contract, such as smart contract 330, associated with the digital asset and verifies that a first liveness hash matches the hash of the digital asset and a first nonce.

[0078] In one embodiment, smart contract 330 includes digital asset ownership validation program 301. In one embodiment, digital asset ownership validation program 301 is a registry and is a subset of smart contract 330. Digital asset ownership validation program 301 may be formed, at least in part, from digital asset ownership validation code 150, as shown in and described with reference to FIG. 1. In one embodiment, digital asset ownership validation program 301 is separate from smart contract 330. For example, in some embodiments, digital asset ownership validation program 301 is included in server 320. In one embodiment, smart contract 330 and smart registry may be used interchangeably.

[0079] In one embodiment, the digital asset owner verification program 301 may be configured to access various data sources, such as a user's digital wallet, which may contain personal data, content, contextual data, or information that the user does not want processed. Personal data includes personally identifying or sensitive personal information, as well as user information, such as location tracking or geolocation information. Processing refers to any automated or non-automated action or set of actions, such as collecting, recording, organizing, structuring, storing, adapting, modifying, retrieving, querying, using, disclosing by transmission, distributing, or otherwise making available, combining, restricting, erasing, or destroying personal data. In one embodiment, the digital asset owner verification program 301 enables authorized and secure processing of personal data. In one embodiment, the digital asset owner verification program 301 provides informed consent along with notice of collection of personal data and allows the user to opt in or out of processing of their personal data. Consent can take multiple forms. Opt-in consent may require the user to take affirmative action before their personal data is processed. Alternatively, the opt-out consent may require the user to take affirmative action to prevent the processing of personal data before the personal data is processed. In one embodiment, the digital asset owner verification program 301 provides information about the nature (e.g., type, scope, purpose, duration, etc.) of the personal data and processing. In one embodiment, the digital asset owner verification program 301 provides the user with a copy of the stored personal data. In one embodiment, the digital asset owner verification program 301 allows for the correction or completion of inaccurate or incomplete personal data. In one embodiment, the digital asset owner verification program 301 allows for the immediate deletion of personal data.

[0080] In one embodiment, smart contracts 330 are written to the blockchain in the form of key-value pairs. Furthermore, smart contract code may be structured to read values ​​stored on the blockchain and use them in application operations. Smart contract code may be structured to write the output of various logical operations to the blockchain. Such code may be used to create temporary data structures within a virtual machine or other computing platform. Data written to the blockchain may be public and / or kept private and cryptographically secure. The temporary data used / generated by the smart contract is kept in memory by the provided execution environment and then deleted once the required data is identified for the blockchain.

[0081] In one embodiment, smart contract 330 executes on a node having TEEs 390A-390N. In one embodiment, smart contract 330 receives an encrypted digital asset, a nonce, and a liveness hash. In one embodiment, the liveness hash is a hash derived from the raw hash. In one embodiment, smart contract 330 determines a private key associated with a digital asset or wallet. In one embodiment, smart contract 330 performs a TEE action and returns the result to TEE 390A-390N.

[0082] In one embodiment, smart contract 330 executes in TEEs 390A-390N on blockchain nodes 380A-380N. In one embodiment, smart contract 330 receives an encrypted digital asset, a nonce, a private key, and a liveness hash. In one embodiment, the nonce is a randomly generated number that is used only once. In one embodiment, smart contract 330 decrypts the digital asset (A), calculates a liveness hash H', such as sha256(sha256(A)||nonce), and returns verification H==H'.

[0083] In one embodiment, digital asset ownership validation program 301 is a smart contract, such as smart contract 330. In these embodiments, digital asset ownership validation program 301 executes within a blockchain peer. In one embodiment, server 320 is a smart contract, such as smart contract 330. In these embodiments, key-value storage or object storage is configured to execute within each smart contract 330. In one embodiment, the key-value storage or object store is an object stored within a blockchain peer or a distributed object storage system accessible to blockchain peers as an oracle. A blockchain oracle is an entity that connects a blockchain to external systems, thereby enabling smart contracts to execute based on inputs and outputs.

[0084] Distributed ledger 350 includes one or more independent computers or nodes, such as ledgers 360A and 360B and blockchain nodes 380A-380N, used to share and synchronize transactions within their respective electronic ledgers. In one embodiment, distributed ledger 350 is stored on a local blockchain, such as blockchain 370A or 370B.

[0085] Ledgers 360A and 360B include one or more ledgers capable of implementing a blockchain, such as blockchains 370A and 370B.

[0086] Blockchains 370A and 370B may be configured to use one or more smart contracts, such as smart contract 330, that govern transactions for multiple participating nodes. In some embodiments, a cloud service provider may utilize neural networks and / or any form of machine learning to analyze the smart contract and / or transaction request and determine transaction terms or authentication information. In one embodiment, blockchains 370A and 370B may store data to be shared between nodes, such as blockchain node 380. In one embodiment, blockchains 370A and 370B may be represented by blockchain architecture configuration 200, as described with reference to FIG. 2A.

[0087] Blockchain nodes 380A-380N include one or more nodes. In one embodiment, blockchain nodes 380A-380N may be represented by blockchain node 202, as previously described with reference to FIG. 2A.

[0088] The TEEs 390A-390N are trusted execution environments and secure domains for the blockchain nodes 380A-380N. In one embodiment, the TEEs 390A-390N protect the confidentiality of code and data. In one embodiment, the smart contract 330 is executed by the TEEs 390A-390N within the blockchain nodes 380A-380N.

[0089] In one embodiment, the digital asset ownership validation program 301 receives a digital asset and generates a nonce for the digital asset. In one embodiment, the digital asset is an image or other multimedia, and the digital asset ownership validation program 301 receives the nonce in a request to validate the digital asset. In one embodiment, the nonce is a randomly generated number that is used only once. In one embodiment, the digital asset ownership validation program 301 adds the nonce to the hash of the encrypted image or digital asset. In one embodiment, image encryption is the process of encoding an image using an encryption algorithm in a way that prevents unauthorized users from accessing the image. In one embodiment, the digital asset ownership validation program 301 generates a liveness hash based on the image and nonce: liveness hash=sha256(sha256(image)||nonce). In one embodiment, the liveness hash includes the nonce, which is the challenge submitted by the user, and the returned hash of the image hash and the nonce is the response token for the challenge.

[0090] In one embodiment, the digital asset ownership validation program 301 receives an encrypted public key (PubKey). In one embodiment, the public key is paired with a private key. In one embodiment, the digital asset ownership validation program 301 encrypts the image and public key based on a nonce and liveness hash, such as Encrypt(image, PubKey), nonce, Liveness Hash.

[0091] In one embodiment, the digital asset ownership validation program 301 decrypts the encrypted image and private key, as follows: image = decrypt(enc image, PrivKey). In one embodiment, the digital asset ownership validation program 301 accesses the smart contract and verifies that the liveness hash matches the hash of the image and nonce, as follows: verify: liveness hash == sha256(sha256(image)||nonce). In one embodiment, the digital asset ownership validation program 301 stores the encrypted image record, including the liveness hash initial and the encrypted image, in the image record store:<liveness hash initial、image> It is stored on the blockchain as follows.

[0092] In one embodiment, the digital asset ownership validation program 301 receives a request to authenticate ownership of a digital asset. In one embodiment, the digital asset ownership validation program 301 decrypts the received image ID with a private key, such as image = decrypt(get(image id), PrivKey). In one embodiment, the digital asset ownership validation program 301 verifies that the second liveness hash matches the hash and nonce of the image, such as verify: liveness hash2 == sha256(sha256(image) || nonce2). In one embodiment, the digital asset ownership validation program 301 validates the ownership if the second liveness hash matches the liveness hash and nonce of the image.

[0093] In one embodiment, the digital asset ownership validation program 301 receives a request from a user to validate a digital asset currently owned by another user. In one embodiment, the digital asset validation program 301 receives a liveness hash of the hashed original asset and a nonce from the digital asset owner. In one embodiment, the digital asset validation program 301 receives the liveness hash, the nonce, and a reference to the encrypted image (image ID) from the digital asset owner. In one embodiment, the digital asset ownership validation program 301 generates an encrypted instance of the original asset and a liveness hash. In one embodiment, the digital asset ownership validation program 301 posts the encrypted instance of the original asset to a blockchain ledger and references the liveness hash of the original asset. In one embodiment, the digital asset ownership validation program 301 determines a consensus on the liveness hash using a smart contract, such as smart contract 330, executing in a trusted execution environment, such as a TEE 390A-390N, in the blockchain ledger.

[0094] In one embodiment, proof of ownership is requested directly from a user to the owner, or the request is forwarded to the owner and the digital asset validation program 301. In another embodiment, the digital asset ownership validation program 301 receives a validation request for a digital asset from a user and sends the request to a registry (NFT, Liveness Hash (H), Nonce (N)). In one embodiment, the digital asset ownership validation program 301 determines or receives a smart contract for the digital asset. In one embodiment, the digital asset ownership validation program 301 receives or determines an encrypted digital asset (Ae). In one embodiment, the digital asset ownership validation program 301 validates the hash (Ae, H, N). In one embodiment, the digital asset ownership validation program 301 determines or receives a registry private key (RPk). In one embodiment, the digital asset ownership validation program 301 validates the hash (Ae, H, N, RPk). In one embodiment, the digital asset ownership validation program 301 decrypts the digital asset. In one embodiment, the digital asset ownership validation program 301 calculates a liveness hash (H') for the digital asset. In one embodiment, the digital asset ownership validation program 301 performs validation based at least in part on a first liveness hash H matching a second liveness hash H' (H==H'). In one embodiment, the digital asset ownership validation program 301 sends the ownership validation to a user. In one embodiment, the digital asset ownership validation program 301 sends authentic ownership information from a smart contract TEE to a smart contract. In one embodiment, the digital asset ownership validation program 301 sends authentic ownership information from a smart contract to a registry.

[0095] In one example, the digital asset ownership validation program 301 authenticates a digital asset using a ledger using public and private key authentication. The digital asset ownership validation program 301 requests a registry public key (Rpk). The digital asset ownership validation program 301 generates a public and private key pair and registers the key pair. The digital asset ownership validation program 301 generates a nonce (Nr). The digital asset ownership validation program 301 generates a hash (Ah) of the digital asset, for example, sha256(Asset). The digital asset ownership validation program 301 generates a liveness hash (LHr), for example, sha256(Ah|Nr), by determining the nonce (Nr) and the liveness hash (Ah). The digital asset ownership validation program 301 encrypts the asset using the registry public key (Aenc) = encrypt(Rpk)(Asset). The digital asset ownership validation program 301 sends the encrypted asset, along with a unique key composed of a liveness hash and a nonce (LHr:Nr), to a registry store, such as the object store 322 shown in FIG. 3. For example, the registry may use an object store or other key / value store whose address is LHr:Nr and whose value is the encrypted asset. The digital asset ownership validation program 301 receives a request to mint an NFT digital asset from the registry using inputs including the public owner, owner public key, store key (store key:Sk)=LH:Nr, store URL, liveness hash (LHr), and nonce (Nr).

[0096] In another example, the digital asset ownership validation program 301 determines a validation nonce (Nv) for the digital asset. The digital asset ownership validation program 301 sends a validation request to the owner of the digital asset along with the validation nonce (Nv) and the digital asset address. The owner processes the request, and the digital asset ownership validation program 301 receives a response. The digital asset ownership validation program 301 retrieves the digital asset and calculates a liveness hash using the validation nonce (Nv) based at least in part on the asset hash (Ah) = sha256(image) and the liveness hash (H) = sha256(Ah|Nv). The digital asset ownership validation program 301 sends a response with the new liveness hash (H) to the user. The user submits the received liveness hash (H) along with the validation nonce (Nv) and the digital asset reference to the registry for validation. The registry receives an ownership validation request, where the input request includes a digital asset reference H and a nonce (Nv) from the user. The registry retrieves the encrypted asset from the address (URL) and retrieves the smart contract reference from the digital asset. The registry invokes the smart contract with inputs of the owner liveness hash (H), the encrypted asset, and the nonce (Nv). The digital asset ownership validation program 301 sends the consensus result from the smart contract to the user.

[0097] In one example, the owner requests a public key to encrypt an image from the smart contract 330. The public key (a public / private key pair stored in the blockchain environment) is then returned by the smart contract. The owner creates a nonce, calculates the liveness hash and nonce of the original image, encrypts the original image using the public key, and sends the encrypted image, nonce, and liveness hash to the registration smart contract. The digital asset ownership validation program 301 then receives the encrypted image, nonce, and liveness hash from the owner to the registration smart contract. The digital asset ownership validation program 301 performs verification of the liveness hash. The digital asset ownership validation program 301 uses the initial liveness hash as a key to store the encrypted image in a storage service or repository. The digital asset ownership validation program 301 creates an NFT that includes the storage service address and the key (initial liveness hash) for the encrypted image. The digital asset ownership validation program 301 stores the encrypted image in a storage service outside the blockchain environment, such as a Cloud Object Store (COS).

[0098] In another example, the digital asset ownership validation program 301 receives an image or NFT, a generated nonce, and a calculated liveness hash from a user. In one embodiment, the liveness hash is used in the creation of the NFT in place of the stand hash in the NFT minting process input. The input may include a storage address, an owner token, or a liveness hash.

[0099] In one embodiment, the digital asset ownership validation program 301 performs a registration process. In one embodiment, in response to receiving a request for a public key from a first user, the digital asset ownership validation program 301 sends the public key to the first user. In one embodiment, the digital asset ownership validation program 301 generates a public / private key pair and sends the public key to the first user. In one embodiment, the digital asset ownership validation program 301 receives an encrypted image, a nonce, and a liveness hash from user A. In one embodiment, the digital asset ownership validation program 301 decrypts the image and calculates the liveness hash of the image using the nonce received from user A. In one embodiment, if the digital asset ownership validation program 301 determines that the liveness hash received from user A matches the calculated liveness hash, the digital asset ownership validation program 301 stores the image. In one embodiment, the original liveness hash is used as a key for the encrypted image in the storage system.

[0100] In one embodiment, the digital asset ownership validation program 301 performs an ownership validation process. In one example, the second user sends proof of ownership claim along with a nonce to the first user. In one example, the first user determines a liveness hash using the nonce received from the second user. In one embodiment, the digital asset ownership validation program 301 sends the determined liveness hash along with the nonce received from the second user to the second user. In one embodiment, the digital asset ownership validation program 301 receives a validation request from the second user, including a nonce, an image ID, and a returned liveness hash. In one embodiment, the digital asset ownership validation program 301 decrypts the image and determines the liveness hash using the received nonce. In one embodiment, the digital asset ownership validation program 301 determines ownership is valid if both liveness hashes match. In one embodiment, the digital asset ownership validation program 301 determines ownership is valid if the liveness hashes do not match.

[0101] 4 is a flowchart diagram illustrating operational steps for a digital asset ownership validation program 301, generally designated 400, in accordance with at least one embodiment of the present invention. FIG. 4 is intended to be an illustration of only one implementation and does not imply any limitations with regard to the environments in which different embodiments may be implemented. Many modifications to the depicted environment may be made by one skilled in the art without departing from the scope of the present invention, as recited by the claims.

[0102] In step S402, User A acquires an image. In one embodiment, the image is a digital asset. In one embodiment, User A receives the image.

[0103] In step S404, User A generates a nonce. In one embodiment, the nonce is a randomly generated number.

[0104] In step S406, User A generates a first liveness hash. In one embodiment, User A generates a liveness hash based on the image and the nonce as follows: liveness hash=sha256(sha256(image)||nonce).

[0105] In step S408, the digital asset ownership validation program 301 receives an encryption public key (PubKey). In one embodiment, the digital asset ownership validation program 301 generates an encryption public key in response to receiving a request from User A for a public key to encrypt a digital asset. In one embodiment, the public key is paired with a private key for the user's cryptocurrency wallet. In one embodiment, the digital asset ownership validation program 301 receives the encryption public key from User A and sends the determined encryption public key to the registry smart contract.

[0106] In step S410, the digital asset ownership validation program 301 sends the encrypted public key for the image. In one embodiment, the digital asset ownership validation program 301 sends the public key from the registry smart contract to User A.

[0107] In step S412, the digital asset ownership validation program 301 encrypts the digital asset image and public key using the nonce and the first liveness hash. In one embodiment, the digital asset ownership validation program 301 encrypts the digital asset using the public key. In one embodiment, the digital asset ownership validation program 301 determines the liveness hash using the image hash and the nonce. In one embodiment, the digital asset ownership validation program 301 receives a registration request with the encrypted image, nonce, and liveness hash.

[0108] In step S414, the digital asset ownership validation program 301 decrypts the encrypted digital asset image and private key.

[0109] In step S416, the digital asset ownership validation program 301 verifies the first liveness hash=sha256(sha256(image)||nonce).

[0110] In step S418, the digital asset ownership validation program 301 validates the image record:<liveness hash initial、image> Remember.

[0111] In step S420, the digital asset ownership validation program 301 receives a request for proof of ownership, nonce 2. In one embodiment, the digital asset ownership validation program 301 receives a request for proof of ownership from user B.

[0112] In step S422, the digital asset ownership validation program 301 determines liveness hash2=sha256(sha256(image)||nonce2) and image ID. In one embodiment, the digital asset ownership validation program 301 sends the determined liveness hash, hash2=sha256(sha256(image)||nonce2), and image ID from user A to user B.

[0113] In step S424, the digital asset ownership validation program 301 verifies the liveness hash 2 and the image ID. In one embodiment, the digital asset ownership validation program 301 sends the verified liveness hash 2 and the image ID from User B to the registry smart contract.

[0114] In step S426, the digital asset ownership validation program 301 determines image=decrypt(get(image id), PrivKey). In one embodiment, the digital asset ownership validation program 301 decrypts the digital asset and the private key.

[0115] In step S428, the digital asset ownership validation program 301 verifies that liveness hash2 == sha256(sha256(image)||nonce2). In one embodiment, the digital asset ownership validation program 301 determines that the first liveness hash matches the second liveness hash.

[0116] In decision step S430, the digital asset ownership validation program 301 determines whether the digital asset has genuine ownership. In one embodiment, the digital asset ownership validation program 301 determines that the digital asset has genuine ownership if the first liveness hash matches the second liveness hash. In one embodiment, the digital asset ownership validation program 301 determines that the digital asset does not have genuine ownership if the first liveness hash does not match the second liveness hash. If the digital asset ownership validation program 301 determines that the digital asset has genuine ownership (decision step S430, "Yes" branch), the digital asset ownership validation program 301 proceeds to step S432. If the digital asset ownership validation program 301 determines that the digital asset does not have genuine ownership (decision step S430, "No" branch), the digital asset ownership validation program 301 proceeds to step S434.

[0117] In step S432, the digital asset ownership validation program 301 sends information associated with the genuine ownership to User A or User B.

[0118] In step S434, the digital asset ownership validation program 301 sends information associated with the inauthentic ownership to User A or User B.

[0119] 5 is a flowchart diagram illustrating operational steps for a digital asset ownership validation program 301, generally designated 500, in accordance with at least one embodiment of the present invention. FIG. 5 is provided only as an example of one implementation and does not imply any limitations with regard to the environments in which different embodiments may be implemented. Many modifications to the depicted environment may be made by one skilled in the art without departing from the scope of the present invention, as recited by the claims.

[0120] In step S502, the digital asset ownership validation program 301 receives a verification request for the digital asset (NFT, liveness hash (H), nonce (N)). In one embodiment, the digital asset ownership validation program 301 receives a verification request for the digital asset from User A.

[0121] In step S504, the digital asset ownership validation program 301 determines the smart contract.

[0122] In step S506, the digital asset ownership validation program 301 determines the encrypted asset (Ae). In one embodiment, the digital asset ownership validation program 301 receives the encrypted asset (Ae).

[0123] In step S508, the digital asset ownership validation program 301 validates the hash (Ae, H, N).

[0124] In step S510, the digital asset ownership validation program 301 determines the registry private key (RPK).

[0125] In step S512, the digital asset ownership validation program 301 validates the hash (Ae, H, N, Rpk).

[0126] In step S514, the digital asset ownership validation program 301 decrypts the asset.

[0127] In step S516, the digital asset ownership validation program 301 calculates the liveness hash (H').

[0128] In step S518, the digital asset ownership validation program 301 performs verification (H==H'). In one embodiment, the digital asset ownership validation program 301 determines that the hash (H) and the liveness hash (H') are the same.

[0129] In step S520, the digital asset ownership validation program 301 verifies the result. In one embodiment, the digital asset ownership validation program 301 sends the verified result from the smart contract TEE to the smart contract.

[0130] In step S522, the digital asset ownership validation program 301 verifies the result. In one embodiment, the digital asset ownership validation program 301 transmits the verified result from the smart contract to the registry. In one embodiment, the digital asset ownership validation program 301 transmits the verified result from the registry to the verification requester.

[0131] 6 is a flowchart diagram illustrating operational steps for registering image processing, generally designated 600, in accordance with at least one embodiment of the present invention. FIG. 6 is intended to be illustrative of only one implementation and does not imply any limitation with regard to the environments in which different embodiments may be implemented. Many modifications to the depicted environment may be made by one of ordinary skill in the art without departing from the scope of the present invention, as recited by the claims.

[0132] In step S602, in response to receiving the request for the public key to encrypt the digital asset, the digital asset ownership validation program 301 sends the public key to the owner of the digital asset. In one embodiment, sending the public key to encrypt the digital asset further includes generating a public / private key pair. In one embodiment, the public key of the public / private key pair is used to encrypt the digital asset. In one embodiment, the private key of the public / private key pair is used to decrypt the encrypted digital asset.

[0133] In step S604, the digital asset ownership validation program 301 receives an encrypted digital asset, a first liveness hash, and a first nonce from the owner of the digital asset. In one embodiment, the digital asset is encrypted using a public key. In one embodiment, the first liveness hash is generated based at least in part on the unencrypted form of the digital asset and the first nonce.

[0134] In decision step S606, the digital asset ownership validation program 301 determines whether the first liveness hash is valid. In one embodiment, the digital asset ownership validation program 301 uses a private key associated with the digital asset to convert the encrypted digital asset back into an unencrypted digital asset. In one embodiment, the digital asset ownership validation program 301 generates a second liveness hash based on the unencrypted digital asset and the first nonce. In one embodiment, the digital asset ownership validation program 301 compares the first liveness hash with the second liveness hash. If the digital asset ownership validation program 301 determines that the first liveness hash is valid (decision step S606, "Yes" branch), the digital asset ownership validation program 301 proceeds to step S608. If the digital asset ownership validation program 301 determines that the first liveness hash is not valid (decision step S606, "No" branch), the digital asset ownership validation program 301 terminates.

[0135] In step S608, the digital asset ownership validation program 301 generates a digital asset record. In one embodiment, the digital asset record includes the encrypted digital asset and the first liveness hash. In one embodiment, the digital asset ownership validation program 301 stores the digital asset record in at least one of a distributed ledger or a storage service external to the blockchain environment.

[0136] 7 is a flowchart diagram illustrating operational steps for registering image processing, generally designated 700, in accordance with at least one embodiment of the present invention. FIG. 7 is intended to be illustrative of only one implementation and does not imply any limitations with regard to the environments in which different embodiments may be implemented. Many modifications to the depicted environment may be made by one of ordinary skill in the art without departing from the scope of the present invention, as recited by the claims.

[0137] In step S702, the digital asset ownership validation program 301 receives a request from a requesting entity to provide proof of ownership of the digital asset to the owner of the digital asset. In one embodiment, the request includes a second nonce.

[0138] In step S704, in response to receiving a request from the digital asset owner to provide proof of ownership of the digital asset, the digital asset ownership validation program 301 sends a second nonce to the digital asset owner.

[0139] In step S706, the digital asset ownership validation program 301 receives from the digital asset owner an image ID associated with the digital image and a third liveness hash, in one embodiment, the second liveness hash being generated at least in part based on the unencrypted form of the digital asset and the second nonce.

[0140] In step S708, the digital asset ownership validation program 301 validates the proof of ownership of the digital asset. In one embodiment, validating the proof of ownership of the digital asset is based at least in part on retrieving the encrypted digital asset from the digital asset record using the image ID. In one embodiment, validating the proof of ownership of the digital asset is based at least in part on converting the encrypted digital asset back to an unencrypted digital asset using a private key associated with the digital asset. In one embodiment, validating the proof of ownership of the digital asset is based at least in part on generating a fourth liveness hash based on the unencrypted digital asset and the second nonce. In one embodiment, validating the proof of ownership of the digital asset is based at least in part on matching the first liveness hash with the second liveness hash.

[0141] In step S710, in response to validating the proof of ownership of the digital asset, the digital asset ownership validation program 301 sends a certification to the requesting entity that the owner of the digital asset is valid.

[0142] FIG. 8A illustrates an example system 800 including a physical infrastructure 810 configured to perform various operations according to embodiments of the present disclosure. Referring to FIG. 8A , the physical infrastructure 810 includes a module 812 and a module 814. The module 814 includes a blockchain 820 and a smart contract 830 (which may reside on the blockchain 820), which may perform any of the operational steps 808 (in module 812) included in any of the example embodiments. The steps / operations 808 may include one or more of the described or illustrated embodiments and may represent output or written information written to or read from one or more smart contracts 830 and / or the blockchain 820. The physical infrastructure 810, the module 812, and the module 814 may include one or more computers, servers, processors, memories, and / or wireless communication devices. Furthermore, the module 812 and the module 814 may be the same module.

[0143] FIG. 8B illustrates another exemplary system 840 configured to perform various operations according to embodiments of the present disclosure. Referring to FIG. 8B, system 840 includes module 812 and module 814. Module 814 includes a blockchain 820 and a smart contract 830 (which may reside on the blockchain 820), which may perform any of the operational steps 808 (in module 812) included in any of the exemplary embodiments. The steps / operations 808 may include one or more of the described or illustrated embodiments and may represent output or written information written to or read from one or more smart contracts 830 and / or the blockchain 820. Physical modules 812 and 814 may include one or more computers, servers, processors, memories, and / or wireless communication devices. Furthermore, modules 812 and 814 may be the same module.

[0144] FIG. 8C illustrates an exemplary system configured to utilize a smart contract configuration between contract parties and an intermediary server configured to enforce the smart contract terms on a blockchain, according to an embodiment of the present disclosure. Referring to FIG. 8C, configuration 850 may represent a communication session, an asset transfer session, or a process or procedure driven by a smart contract 830 that explicitly identifies one or more user devices 852 and / or 856. The execution, behavior, and results of smart contract execution may be managed by a server 854. The contents of the smart contract 830 may require digital signatures by one or more of the entities 852 and 856 that are parties to the smart contract transaction. The results of smart contract execution may be written to the blockchain 820 as a blockchain transaction. The smart contract 830 resides on the blockchain 820, which may reside on one or more computers, servers, processors, memories, and / or wireless communication devices.

[0145] 8D illustrates a system 860 including a blockchain, according to an embodiment of the present disclosure. Referring to the example of FIG. 8D , an application programming interface (API) gateway 862 provides a common interface for accessing blockchain logic (e.g., smart contract 830 or other chaincode) and data (e.g., a distributed ledger, etc.). In this example, API gateway 862 is a common interface for performing transactions (e.g., calls, queries, etc.) on the blockchain by connecting one or more entities 852 and 856 to a blockchain peer (e.g., server 854). Here, server 854 is a blockchain network peer component that maintains a copy of the world state and the distributed ledger, allowing clients 852 and 856 to query data related to the world state and submit transactions to the blockchain network, where authorized transactions will execute smart contract 830 according to the smart contract 830 and license terms.

[0146] The above embodiments may be implemented in hardware, in a computer program executed by a processor, in firmware, or in a combination of the above. The computer program may be embodied on a computer-readable medium, such as a storage medium. For example, the computer program may reside in random access memory ("RAM"), flash memory, read-only memory ("ROM"), erasable programmable read-only memory ("EPROM"), electrically erasable programmable read-only memory ("EEPROM"), registers, a hard disk, a removable disk, a compact disk read-only memory ("CD-ROM"), or any other form of storage medium known in the art.

[0147] An exemplary storage medium may be coupled to the processor such that the processor can read information from, and write information to, the storage medium. In the alternative, the storage medium may be integral to the processor. The processor and the storage medium may reside in an application-specific integrated circuit ("ASIC"). In the alternative, the processor and the storage medium may reside as discrete components.

[0148] Figure 9A illustrates a process 900 for adding a new block to a distributed ledger 920 (e.g., when a new smart contract is created), according to an embodiment of the present disclosure, and Figure 9B illustrates the contents of a new data block structure 930 for a blockchain, according to an embodiment of the present disclosure. The new data block 930 may include document linking data.

[0149] Referring to FIG. 9A , a client (not shown) may submit a transaction to blockchain nodes 911, 912, and / or 913. A client may be an instruction to perform an activity on the blockchain 922 received from any source. As an example, a client may be an application acting on behalf of a requester, such as a device, person, or entity, to propose a transaction on the blockchain. Multiple blockchain peers (e.g., blockchain nodes 911, 912, and / or 913) may maintain a copy of the blockchain network state and distributed ledger 920. Different types of blockchain nodes / peers may exist in a blockchain network, including nodes that simulate and approve transactions proposed by clients; recommending nodes that use natural language processing techniques to recommend entities to automatically enter into contracts with users; and committing peers that validate transactions and commit the transactions to the distributed ledger 920. In this example, blockchain nodes 911, 912, and / or 913 may perform the roles of an approver node, a committer node, a recommender node, or all three.

[0150] The distributed ledger 920 includes a blockchain 922, which stores immutable, sequenced records in blocks, and a state database 924 (current world state), which maintains the current state of the blockchain 922. There may be one distributed ledger 920 per channel, and each peer maintains its own copy of the distributed ledger 920 for each channel in which it is a member. The blockchain 922 is a transaction log structured as hash-linked blocks, with each block containing a sequence of N transactions. A block may include various components, such as those shown in FIG. 9B. Block linking (denoted by arrows in FIG. 9A) may be generated by adding a hash of the previous block's header into the block header of the current block. In this way, all transactions on the blockchain 922 are sequenced and cryptographically linked together, preventing tampering with the blockchain data without breaking the hash links. Furthermore, because of these links, the most recent block in the blockchain 922 represents all transactions that came before it. The blockchain 922 can be stored on a peer file system (local or attached storage) that supports append-only blockchain workloads.

[0151] The current state of the blockchain 922 and distributed ledger 920 may be stored in a state database 924, where current state data represents the latest values ​​for all keys included so far in the chain transaction log of the blockchain 922. Chaincode calls execute transactions against the current state in the state database 924. To make these chaincode interactions highly efficient, the latest values ​​for all keys may be stored in the state database 924. The state database 924 may contain an indexed view into the blockchain 922 transaction log, so it can be regenerated off-chain at any time. The state database 924 can be automatically repaired (or generated, if necessary) at peer startup and before transactions are accepted.

[0152] Nodes receive transactions from clients and approve the transactions based on simulated results. Nodes maintain smart contracts that simulate transaction proposals. If a node validates ownership of a digital asset, it creates a transaction approval, which is a signed response from the node to the client application indicating validation of ownership of the digital asset. The method for validating ownership of a digital asset depends on one or more of a liveness hash, a nonce, or a private and public key pair, which may be specified in the chaincode. Different channels may have different licensing conditions. Approved transactions are forwarded by the client application to the ordering service 910.

[0153] The ordering service 910 accepts authorized transactions, orders them into blocks, and distributes the blocks to committing peers. For example, the ordering service 910 may start a new block when a transaction threshold is reached, a timer times out, or another condition occurs. In the example of FIG. 9A , blockchain node 912 is a committing peer that receives a new block of data 930 for storage on the blockchain 922. The first block in a blockchain may be referred to as a genesis block, which contains information about the blockchain, its members, the data stored therein, etc.

[0154] The ordering service 910 may consist of a cluster of orderers. The ordering service 910 does not process transactions, smart contracts, or maintain a shared ledger. Rather, the ordering service 910 may accept authorized transactions and specify the order in which those transactions are committed to the distributed ledger 920. The architecture of the blockchain network may be designed so that specific implementations of "ordering" are pluggable components.

[0155] Transactions are written to the distributed ledger 920 in a consistent order. The order of transactions is established to ensure that updates to the state database 924 are valid when they are committed to the network. Unlike cryptocurrency blockchain systems where ordering is achieved through solving cryptographic puzzles or mining, in this example, the parties to the distributed ledger 920 can choose the ordering mechanism that best suits their network.

[0156] When the ordering service 910 initializes a new data block 930, the new data block 930 may be broadcast to the committing peers (e.g., blockchain nodes 911, 912, and 913). If the transaction is approved, it is written to the blockchain 922 on the distributed ledger 920, and the state database 924 is updated with the write data from the read-write set. If the transaction fails, i.e., if the committing peers find that the read-write set does not match the current world state in the state database 924, the transactions that were ordered into the block are still included in the block but are marked as invalid, and the state database 924 is not updated.

[0157] Referring to FIG. 9B , a new data block 930 (also referred to as a data block) stored on the blockchain 922 of the distributed ledger 920 may include multiple data segments, such as a block header 940, block data 950, and block metadata 960. It should be understood that the various blocks and their contents shown, such as the new data block 930 and its contents shown in FIG. 9B , are merely examples and are not intended to limit the scope of the illustrative embodiments. The new data block 930 may store transaction information for N transactions (e.g., 1, 10, 100, 500, 1000, 2000, 3000, etc.) in the data block 950. The new data block 930 may also include a link to a previous block (e.g., on the blockchain 922 in FIG. 9A ) in the block header 940. In particular, the block header 940 may include a hash of the header of the previous block. The block header 940 may also include a unique block number, a hash of the block data 950 of the new data block 930, and the like. The block numbers of the new data blocks 930 are unique and may be assigned in various orders, such as an incremental / sequential order starting from 0.

[0158] The data block 950 may store transaction information for each transaction recorded in the new data block 930. For example, the transaction data may include one or more of the following: transaction type, version, timestamp, distributed ledger 920 channel ID, transaction ID, epoch, payload visibility, chaincode path (deployment tx), chaincode name, chaincode version, inputs (chaincode and function), client (creator) identification such as public key and certificate, client signature, licensor signature, licensor identity, proposal hash, chaincode event, response status, namespace, read set (e.g., list of keys and versions read by the transaction), write set (e.g., list of keys and values), start key, end key, list of keys, Merkle tree query summary, and the like. Transaction data may be stored for each of the N transactions.

[0159] In some embodiments, data block 950 may also store new data 962 that adds additional information to the hash-linked chain of blocks in blockchain 922. The additional information may include one or more of the steps, features, processes, and / or actions described or illustrated herein. Accordingly, new data 962 may be stored in an immutable log of blocks on distributed ledger 920. Some of the benefits of storing such new data 962 are reflected in various embodiments disclosed and illustrated herein. In FIG. 9B , new data 962 is shown in data block 950, but may also be located in block header 940 or block metadata 960. New data 962 may include a document decryption key used to link documents within an organization.

[0160] Block metadata 960 may store multiple fields of metadata (e.g., as a byte array, etc.). The metadata fields may include a signature for the block creation, a reference to the last constituent block, a transaction filter that identifies valid and invalid transactions in the block, the last persisted offset of the ordering service that ordered the block, and the like. The signature, last constituent block, and ordering metadata may be added by the ordering service 910. Alternatively, the block's committer (e.g., blockchain node 912) may add validity / invalidity information based on authorization policies, validation of read / write sets, and the like. The transaction filter may include a byte array of size equal to the number of transactions in data block 950 and a validation code that identifies whether the transaction was valid or invalid.

[0161] 9C illustrates one embodiment of a blockchain 970 for digital content, according to embodiments described herein. The digital content may include one or more files and associated information. The files may include media, images, video, audio, text, links, graphics, animations, web pages, documents, or other forms of digital content. The immutable, append-only aspects of the blockchain serve as safeguards to protect the integrity, validity, and authenticity of the digital content, making it suitable for use in legal proceedings where admissibility rules apply, or in other settings where evidence is considered or the presentation and use of digital information is otherwise beneficial. In this case, the digital content may be referred to as digital evidence.

[0162] A blockchain can be formed in a variety of ways. In one embodiment, digital content can be contained in and accessed from the blockchain itself. For example, each block in the blockchain can store a hash value of reference information (e.g., headers, values, etc.) along with associated digital content. The hash value and associated digital content can then be encrypted together. Thus, the digital content of each block can be accessed by decrypting each block in the blockchain, and the hash value of each block can be used as a basis to reference previous blocks. This can be shown as follows: Block 1 Block 2 ....... Block N Hash value 1 Hash value 2 Hash value N Digital Content 1 Digital Content 2 Digital Content N

[0163] In one embodiment, the digital content may not be included in the blockchain. For example, the blockchain may store an encrypted hash of the content of each block without any of the digital content. The digital content may be stored in a separate storage area or memory address in association with the hash value of the original file. The other storage area may be the same storage device used to store the blockchain, or it may be a different storage area, or even a separate relational database. The digital content of each block may be referenced or accessed by obtaining or querying the hash value of the block in question and then looking up the value in the storage area where it is stored in correspondence with the actual digital content. This operation may be performed, for example, by a database gatekeeper. This may be illustrated as follows: Blockchain Storage Area Block 1 hash value Block 1 hash value ... Contents Block N hash value Block N hash value ... Contents

[0164] In the exemplary embodiment of FIG. 9C, the blockchain 970 comprises a plurality of blocks 9781, 9782...978 that are cryptographically linked in an ordered sequence. N where N≧1. Blocks 9781, 9782...978 N The encryption used to link the blocks 9781, 9782, ... 978 can be any of a number of keyed or non-keyed hash functions. N is the subject of a hash function that generates an n-bit alphanumeric output (where n is 256 or another number) from an input based on the information in the block. Examples of such hash functions include, but are not limited to, SHA-type (SHA stands for Secure Hash Algorithm) algorithms, Merkle-Dangard algorithms, HAIFA algorithms, Merkle tree algorithms, nonce-based algorithms, and collision-resistant PRF algorithms. In another embodiment, blocks 9781, 9782...978 N may be cryptographically linked by a function different from the hash function. For illustrative purposes, the following description is made with reference to a hash function, e.g., SHA-2.

[0165] Blocks 9781, 9782...978 in the blockchain N Each of the files includes a header, a file version, and a value. The header and value are different for each block as a result of hashing in the blockchain. In one embodiment, the value may be included in the header. As described in more detail below, the file version may be the original file or a different version of the original file.

[0166] The first block 9781 in a blockchain is called the genesis block and includes a header 9721, an original file 9741, and an initial value 9761. The hashing scheme used for the genesis block, and indeed for all subsequent blocks, may be different. For example, all of the information in the first block 9781 may be hashed together at once, or each or portions of the information in the first block 9781 may be hashed separately, and then a hash of the separately hashed portions may be performed.

[0167] The header 9721 may include one or more initial parameters, which may include, for example, a version number, a timestamp, a nonce, root information, difficulty, consensus protocol, duration, media format, source, descriptive keywords, and / or other information associated with the original file 9741 and / or the blockchain. The header 9721 may be generated automatically (e.g., by a blockchain network that manages the software) or manually by a blockchain participant. Other blocks 9782-9788 in the blockchain N Unlike headers in the , the header 9721 in the genesis block does not reference a predecessor block simply because there is no predecessor block.

[0168] The original file 9741 in the genesis block may be, for example, data captured by a device with or without processing before its inclusion in the blockchain. The original file 9741 is received from a device, media source, or node through an interface of the system. The original file 9741 is associated with metadata, which may be generated, for example, by a user, device, and / or system processor, either manually or automatically. The metadata may be included in the first block 9781 in association with the original file 9741.

[0169] The value 9761 in the genesis block is an initial value that is generated based on one or more unique attributes of the original file 9741. In one embodiment, the one or more unique attributes may include a hash value for the original file 9741, metadata about the original file 9741, and other information associated with the file. In one implementation, the initial value 9761 may be based on the following unique attributes: 1) SHA-2 calculated hash value for the original file; 2) Originating Device ID; 3) The start timestamp for the original file; 4) the initial storage location of the original file; and 5) The blockchain network member ID for the software that currently controls the original file and associated metadata.

[0170] Other blocks in the blockchain: 9782-978 N However, unlike the first block 9721, the headers 9722 to 9723 in the other blocks also have a header, a file, and a value. N Each of the remaining blocks contains the hash value of the immediately preceding block. The hash value of the immediately preceding block may simply be the hash of the header of the preceding block, or it may be the hash value of the entire preceding block. By including the hash value of the preceding block in each of the remaining blocks, a block-by-block tracing can be performed, as shown by arrow 980, from the Nth block back to the genesis block (and associated original file), establishing an auditable and immutable evidence chain.

[0171] Also, headers 9722 to 972 in other blocks N may include other information, such as a version number, a timestamp, a nonce, root information, difficulty level, a consensus protocol, and / or other parameters or information associated with the corresponding file and / or the blockchain in general.

[0172] Files 9742 to 974 in other blocks N may be equal to the original file or may be a modified version of the original file in the genesis block, depending on, for example, the type of processing performed. The type of processing performed may vary from block to block. Processing may involve any modification of the file in the preceding block, such as, for example, editing or otherwise changing content from the file, deleting information, or adding or appending information to the file.

[0173] Additionally or alternatively, processing may involve simply copying a file from a previous block, changing the storage location of a file, analyzing a file from one or more previous blocks, moving a file from one storage or memory location to another, or performing an action on a file on the blockchain and / or its associated metadata. Processing involving analysis of a file may include, for example, appending, including, or otherwise associating various analytical, statistical, or other information associated with the file.

[0174] Other blocks in other blocks 9762~976 N The value in each of the blocks is unique and is different as a result of the operations that have been performed. For example, the value in any one block corresponds to an updated version of the value in the previous block. The update is reflected in the hash of the block to which the value is assigned. Thus, the value of a block provides an indication of what operations have been performed within the block and allows tracing back through the blockchain to the original file. This tracing ensures the integrity of the file throughout the blockchain.

[0175] For example, consider the case where a portion of a file in a previous block has been redacted, blocked out, or pixelated to protect the identity of a person depicted in the file. In this case, the block containing the edited file includes metadata associated with the edited file, such as how the edits were performed, who performed the edits, a timestamp when the edits occurred, etc. The metadata may be hashed to form a value. Because the metadata for the block is different from the information hashed to form the value in the previous block, these values ​​will be different from each other and can be recovered when decrypted.

[0176] In one embodiment, the value of a previous block may be updated (e.g., a new hash value may be calculated) to form the value of a current block if any one or more of the following occurs: The new hash value, in this example embodiment, may be calculated by hashing all or part of the information described below: a) a new SHA-2 calculated hash value if the file has been processed in any way (e.g., if the file has been edited, copied, modified, accessed, or any other action taken); b) a new storage location for the file; c) identified new metadata associated with the file; d) Transfer of access or control of a file from one blockchain participant to another.

[0177] FIG. 9D illustrates an embodiment of a block that may represent the structure of a block in a blockchain 990, according to one embodiment. i Header 972 i , File 974 i , and value 976 i Includes.

[0178] Header 972 i is the preceding block Block i-1and additional reference information, which may be, for example, any of the types of information discussed herein (e.g., header information containing references, properties, parameters, etc.). Every block, except of course for the genesis block, references the hash of its predecessor block. The hash value of a predecessor block may simply be a hash of the header in the predecessor block, or a hash of all or part of the information in the predecessor block, including files and metadata.

[0179] File 974 i includes multiple pieces of data, such as Data1, Data2, ..., DataN, in order. The data are tagged with Metadata1, Metadata2, ..., MetadataN, which describe the content and / or characteristics associated with the data. For example, the metadata for each piece of data may include information indicating a timestamp for the data, information for processing the data, keywords indicating people or other content depicted in the data, and / or other features that may be useful for establishing the validity and content of the file as a whole, and, among other things, its use as digital evidence, e.g., as described in connection with one embodiment discussed below. In addition to the metadata, each piece of data may include references REF1, REF2, ..., REF to previous pieces of data to prevent tampering, gaps within the file, and sequential referencing through the file. N It can be tagged with.

[0180] Once metadata is assigned to data (e.g., through a smart contract), it cannot be altered without a hash change that can be easily identified to invalidate it. Thus, the metadata creates a data log of information that can be accessed for use by participants in the blockchain.

[0181] Value 976 i is a hash value or other value calculated based on any of the type information described above. For example, for any given block, Block i, the value for that block may be updated to reflect the processing performed on that block, such as a new hash value, a new storage location, new metadata for the associated file, a transfer of control or access, an identifier, or other action or information to be added. Although the values ​​in each block are shown to be separate from the metadata for the file and header data, in other embodiments the values ​​may be based in part or in whole on this metadata.

[0182] Once the blockchain 990 is formed, at any point in time, an immutable evidence chain for a file can be obtained by querying the blockchain for a transaction history of values ​​across blocks. This query, or tracking procedure, can begin by decrypting the value of the most recently included block (e.g., the last (Nth) block), and then continue decrypting values ​​of other blocks until the genesis block is reached and the original file is restored. Decryption can also involve decoding the header and file and associated metadata in each block.

[0183] Decryption is performed based on the type of encryption performed on each block. This may involve the use of a private key, a public key, or a public-private key pair. For example, if asymmetric encryption is used, blockchain participants or processors in the network may use a predetermined algorithm to generate a public and private key pair. The public and private keys are related to each other through some mathematical relationship. The public key may be publicly distributed to serve as an address for receiving messages from other users, such as an IP address or home address. The private key is kept secret and is used to digitally sign messages sent to other blockchain participants. The signature is included in the message so that the recipient can verify it using the sender's public key. In this way, the recipient can be sure that only the sender could have sent the message.

[0184] Generating a key pair can be similar to creating an account on the blockchain, but without the need to actually register it anywhere. Also, all transactions performed on the blockchain are digitally signed by the sender using their private key. This signature ensures that only the account owner can track and transact files on the blockchain (within the scope of permissions determined by the smart contract).

Claims

1. 1. A computer-implemented method for validating ownership of a digital asset, comprising: one or more processors, in response to receiving a request for a public key for encrypting a digital asset, sending the public key to an owner of the digital asset; receiving, by the one or more processors, from the owner of the digital asset, an encrypted digital asset and a first liveness hash, where the digital asset is encrypted using the public key and the first liveness hash is generated based at least in part on an unencrypted form of the digital asset and a first nonce; In response to receiving the first nonce and the first liveness hash from the encrypted digital asset from the owner of the digital asset, determining whether the first liveness hash is valid; and generating a digital asset record in response to the one or more processors determining that the first liveness hash is valid, wherein the digital asset record includes the encrypted digital asset and the first liveness hash.

1. A computer-implemented method comprising:

2. 2. The computer-implemented method of claim 1, wherein transmitting the public key to encrypt the digital asset further comprises generating a public / private key pair, wherein the public key of the public / private key pair is used to encrypt the digital asset and the private key of the public / private key pair is used to decrypt the encrypted digital asset.

3. storing the digital asset record in at least one of a distributed ledger or a storage service external to the blockchain environment; The computer-implemented method of claim 1 further comprising:

4. The step of determining whether the first liveness is valid includes: converting the encrypted digital asset back into an unencrypted digital asset using a private key associated with the digital asset by the one or more processors; the one or more processors generating a second liveness hash based on the unencrypted digital asset and the first nonce; and the one or more processors matching the first liveness hash with the second liveness hash. The computer-implemented method of claim 1 , comprising:

5. receiving, by the one or more processors, a request from a requesting entity to provide proof of ownership of the digital asset to the owner of the digital asset, wherein the request includes a second nonce; and In response to receiving the request to the owner of the digital asset to provide proof of ownership of the digital asset: the one or more processors transmitting the second nonce to the owner of the digital asset. The computer-implemented method of claim 1 further comprising:

6. receiving, by the one or more processors, from the owner of the digital asset, an image ID associated with the digital image and a third liveness hash, wherein the second liveness hash is generated based at least in part on the unencrypted form of the digital asset and the second nonce. The computer-implemented method of claim 5 further comprising:

7. 7. The computer-implemented method of claim 6, comprising: the one or more processors retrieving the encrypted digital asset from the digital asset record using the image ID; converting the encrypted digital asset back into an unencrypted digital asset using a private key associated with the digital asset by the one or more processors; the one or more processors generating a fourth liveness hash based on the unencrypted digital asset and the second nonce; and the one or more processors matching the first liveness hash with the second liveness hash. the one or more processors validating proof of ownership of the digital asset based at least in part on

8. In response to validating the proof of ownership of the digital asset, the one or more processors transmit to a requesting entity an authentication that the owner of the digital asset is valid. The computer-implemented method of claim 4 further comprising:

9. the one or more processors determining a consensus of the first liveness hash using a smart contract executing in a trusted execution environment within a blockchain ledger. The computer-implemented method of claim 1 further comprising:

10. the one or more processors accessing a smart contract associated with the digital asset and verifying that the first liveness hash matches the hash of the digital asset and the first nonce. The computer-implemented method of claim 1 further comprising:

11. The computer-implemented method of claim 1 , wherein the digital asset is an image or multimedia.

12. transmitting genuine ownership information from the smart contract TEE to the smart contract; The computer-implemented method of claim 5 further comprising:

13. transmitting true ownership information from said smart contract to a registry; The computer-implemented method of claim 9 further comprising:

14. 1. A computer program for validating ownership of a digital asset, comprising: In response to receiving a request for a public key for encrypting a digital asset, sending the public key to the owner of the digital asset; receiving an encrypted digital asset and a first liveness hash from the owner of the digital asset, where the digital asset is encrypted using the public key and the first liveness hash is generated based at least in part on an unencrypted form of the digital asset and a first nonce; In response to receiving the first nonce and the first liveness hash from the encrypted digital asset from the owner of the digital asset, determining whether the first liveness hash is valid; and In response to determining that the first liveness hash is valid, generate a digital asset record, where the digital asset record includes the encrypted digital asset and the first liveness hash.

11. A computer program having instructions to:

15. 15. The computer program product of claim 14, wherein the instructions to send the public key for encrypting the digital asset further comprise instructions to generate a public / private key pair, wherein the public key of the public / private key pair is used to encrypt the digital asset and the private key of the public / private key pair is used to decrypt the encrypted digital asset.

16. Storing the digital asset record in at least one of a distributed ledger or a storage service external to the blockchain environment.

15. The computer program of claim 14, further comprising instructions to:

17. The instructions to determine if the first liveness hash is valid include: converting the encrypted digital asset back into an unencrypted digital asset using a private key associated with the digital asset; generating a second liveness hash based on the unencrypted digital asset and the first nonce; and Matching the first liveness hash with the second liveness hash 15. A computer program product as claimed in claim 14, comprising instructions to:

18. receiving a request from a requesting entity to provide proof of ownership of the digital asset to the owner of the digital asset, wherein the request includes a second nonce; and In response to receiving the request to the owner of the digital asset to provide proof of ownership of the digital asset: Sending the second nonce to the owner of the digital asset.

15. The computer program of claim 14, further comprising instructions to:

19. receiving from the owner of the digital asset an image ID associated with the digital image and a third liveness hash, wherein the second liveness hash is generated based at least in part on the unencrypted form of the digital asset and a second nonce; 15. The computer program of claim 14, further comprising instructions to:

20. 1. A computer system for validating ownership of a digital asset, comprising: one or more computer processors; one or more computer-readable storage media; computer program instructions; the computer program instructions are stored on the one or more computer-readable storage media for execution by the one or more computer processors; The computer program instructions: In response to receiving a request for a public key for encrypting a digital asset, sending the public key to the owner of the digital asset; receiving an encrypted digital asset and a first liveness hash from the owner of the digital asset, where the digital asset is encrypted using the public key and the first liveness hash is generated based at least in part on an unencrypted form of the digital asset and a first nonce; In response to receiving the first nonce and the first liveness hash from the encrypted digital asset from the owner of the digital asset, determining whether the first liveness hash is valid; and In response to determining that the first liveness hash is valid, generate a digital asset record, where the digital asset record includes the encrypted digital asset and the first liveness hash.

11. A computer system having instructions to:

21. 1. A computer-implemented method for validating ownership of a digital asset, comprising: receiving, by one or more processors, a request from a requesting entity to an owner of a digital asset to provide proof of ownership of the digital asset, wherein the request includes a first nonce; and In response to receiving the request to the owner of the digital asset to provide proof of ownership of the digital asset: the one or more processors transmitting the first nonce to the owner of the digital asset; receiving, by the one or more processors, from the owner of the digital asset, an image ID and a first liveness hash associated with a digital image; and the one or more processors validating proof of ownership of the digital asset. A computer-implemented method comprising:

22. 22. The computer-implemented method of claim 21, wherein the first liveness hash is generated based at least in part on an unencrypted form of the digital asset and the first nonce.

23. The one or more processors validating proof of ownership of the digital asset includes: the one or more processors retrieving an encrypted digital asset from a digital asset record using the image ID; converting the encrypted digital asset back into an unencrypted digital asset using a private key associated with the digital asset by the one or more processors; the one or more processors generating a second liveness hash based on the unencrypted digital asset and a second nonce; and the one or more processors matching the first liveness hash with the second liveness hash.

22. The computer-implemented method of claim 21, based at least in part on

24. in response to validating the proof of ownership of the digital asset, the one or more processors transmitting authentication to the requesting entity that the owner of the digital asset is valid.

22. The computer-implemented method of claim 21, further comprising:

25. 22. The computer-implemented method of claim 21, wherein the digital asset is an image or multimedia.

Images