Method for verifying ownership of digital assets and authenticating digital assets

Abstract

A computer-implemented method for verifying 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 activeness hash from an owner of the digital asset, where the digital asset is encrypted using the public key, the first activeness hash generated based at least in part on the digital asset in unencrypted form and the first one-time number. The computer-implemented method also includes determining whether the first activeness hash is valid. The computer-implemented method further includes, in response to determining that the first activeness hash is valid, generating a digital asset record, where the digital asset record includes the encrypted digital asset and the first activeness hash.

Description

Background Art

[0001] The present invention generally relates to the field of digital assets, and more particularly to authenticating digital assets and verifying the 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 turning it into a digital asset that can be stored on a blockchain. Once an NFT becomes a digital asset, the NFT can be put into circulation and the NFT can be sold via a smart contract. A smart contract is a computer program or transaction protocol that is designed to automatically execute, control, or record legal-related events and actions. 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 the public key and / or private key used for cryptocurrency transactions. The ownership of an NFT is recorded in the blockchain and can be transferred by the owner, allowing the NFT to be sold and traded.

[0003] During the minting process, an NFT is created when the blockchain links a record containing a cryptographic hash (which is a character set that identifies a data set) to a previous record, thus creating an identifiable blockchain of data. This cryptographic transaction process ensures the authentication of each digital asset by providing a digital signature that tracks the ownership of the NFT. Digital assets are typically downloadable from well-known repositories. Digital assets can also be held, sold, traded, or offered for sale on many different platforms or markets. This means that someone can obtain a digital asset from one platform and create a forgery of the original digital asset's image on another platform or market.

[0004] A cryptocurrency wallet is a device, physical medium, program, or service that stores the public key and / or private key used for cryptocurrency transactions. A cryptocurrency wallet is attached with a public key and a private key. The public key functions similar to an email address, which means it can be safely shared with others, allowing you to send or receive assets. However, the private key is a security code that enables the holder of a digital asset to conduct transactions and prove the ownership of their digital asset. The private key is usually a string of letters and numbers. The public key allows you to receive cryptocurrency transactions. While anyone can send a transaction to the public key, you need the private key to "unlock" them and prove that you are the owner of the cryptocurrency received in the transaction.

[0005] With the emergence of blockchain technology, content creators have been able to digitize their creations and sell them as NFTs in the market. One of the drawbacks of NFTs is that anyone can use the link in the NFT to access the URL and download the asset from the repository. Then, they can mint a new NFT on another NFT market and claim to be the owner of the asset. Then, the challenge becomes proving the true ownership of the asset.

[0006] US20200242105A1 describes "a distributed computing platform and method for creating actionable digital assets and tokens that combine influence and extensibility ('KNFT'). The KNFT application server can 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... Social actions can include user comments, connections, direct messages, likes, or positive reviews, and changes in the ownership of the KNFT can be written to the social vector by the KNFT API. The social vector can include social vector data from at least one previous owner, and the KNFT can also include a circulation trace vector that incorporates the ownership history of the KNFT." This reference fails to address the problem of providing a security mechanism on the ledger to authenticate digital asset transactions. Embodiments of the present invention are advantageous and recognize the need and importance of a method for protecting digital assets by providing a security mechanism for authenticating digital asset transactions. Embodiments of the present invention solve this problem on the ledger by using a liveness hash for verification.

[0007] Another way to prevent digital asset fraud is to check other registered or known markets. Currently, NFTs are generated, and the metadata required to download the original asset is typically embedded as part of the NFT. Therefore, anyone with access to the metadata can download the original asset. This provides opportunities for forgery, counterfeiting, and other vulnerabilities. Additionally, the asset itself can be stored in a third-party website that may stop operating at some point, which may result in the loss of the original asset. However, embodiments of the present invention recognize that minting digital assets with encrypted images increases the likelihood of determining the authenticity of digital assets.

[0008] The existing NFT creation and verification processes are open to the public. The existing NFT minting process includes the image hash in the object repository and the URL of the image. This means that anyone can verify the hash through the asset hash or address in the NFT and calculate the hash to check for a match. Additionally, NFT theft is easily implemented by copying the asset, creating a hash, and minting another NFT with the same image on the same or a different platform. Embodiments of the present invention solve this problem through asset location and activity hashes. Additionally, the referenced assets are encrypted. In embodiments of the present invention, ownership verification does not rely on the data in the NFT. In embodiments of the present invention, the requester provides a one-time digital (nonce), and the owner repository performs an activity hash to prove ownership. Summary of the Invention

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

[0010] According to another embodiment of the present invention, a computer program product for verifying the ownership of a digital asset is disclosed. The computer program product includes 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 to send the public key to the owner of the digital asset in response to receiving a request for the public key for encrypting the digital asset. The program instructions further include instructions to receive the encrypted digital asset and a first activity hash from the owner of the digital asset, wherein the digital asset is encrypted using the public key, and the first activity hash is generated at least in part based on the digital asset in unencrypted form and a first one-time number. The program instructions further include instructions to determine whether the first activity hash is valid in response to receiving the first one-time number and the first activity hash from the encrypted digital asset from the owner of the digital asset. The program instructions further include instructions to generate a digital asset record in response to determining that the first activity hash is valid, wherein the digital asset record includes the encrypted digital asset and the first activity hash. Embodiments of the present invention facilitate generating an activity hash to replace a hash.

[0011] According to another embodiment of the present invention, a computer system for verifying the 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 media for execution by the one or more computer processors. The program instructions include instructions to send the public key to the owner of the digital asset in response to receiving a request for the public key for encrypting the digital asset. The program instructions further include instructions to receive the encrypted digital asset and a first activity hash from the owner of the digital asset, wherein the digital asset is encrypted using the public key, and the first activity hash is generated at least in part based on the digital asset in unencrypted form and a first one-time number. The program instructions further include instructions to determine whether the first activity hash is valid in response to receiving the first one-time number and the first activity hash from the encrypted digital asset from the owner of the digital asset. The program instructions further include instructions to generate a digital asset record in response to determining that the first activity hash is valid, wherein the digital asset record includes the encrypted digital asset and the first activity hash. Embodiments of the present invention facilitate generating an activity hash to replace a hash.

[0012] According to another embodiment of the present invention, a computer-implemented method for verifying the ownership of a digital asset is disclosed. The computer-implemented method includes: receiving, by one or more processors, from a requesting entity, a request for the owner of a digital asset to provide proof of ownership of the digital asset, wherein the request includes a first one-time number. The computer-implemented method further includes: in response to receiving the request for the owner of the digital asset to provide proof of ownership of the digital asset. The computer-implemented method further includes: sending, by the one or more processors, the first one-time number to the owner of the digital asset. The computer-implemented method further includes: receiving, by the one or more processors, from the owner of the digital asset, an image id associated with a digital image and a first activity hash. The computer-implemented method further includes: verifying, by the one or more processors, the proof of ownership of the digital asset. Embodiments of the present invention facilitate generating an activity hash instead of a hash. BRIEF DESCRIPTION OF THE DRAWINGS

[0013] The drawings included in this disclosure are incorporated into the specification and form a part of the specification. They illustrate embodiments of the disclosure and, together with the specification, are used to explain the principles of the disclosure. The drawings merely illustrate specific embodiments and do not limit the disclosure.

[0014] Figure 1 is a functional block diagram of a computing environment (generally designated 100) suitable for executing at least some of the computer code involved in performing the methods of the present invention (e.g., digital asset ownership verification code 150).

[0015] Figure 2A illustrates an example blockchain architecture configuration generally designated 200 according to at least one embodiment of the present invention.

[0016] Figure 2B illustrates a blockchain transaction flow generally designated 250 according to at least one embodiment of the present invention.

[0017] Figure 3 is a functional block diagram of a digital asset ownership verification system (generally designated 300) suitable for the operation of a digital asset trading program 301 according to at least one embodiment of the present invention.

[0018] Figure 4 is a flowchart (generally designated 400) depicting the operational steps of a digital asset ownership verification program 301 according to at least one embodiment of the present invention.

[0019] Figure 5is a flowchart (generally designated as 500) depicting the operational steps of a digital asset ownership verification procedure 301 according to at least one embodiment of the present invention.

[0020] Figure 6 is a flowchart (generally designated as 600) depicting the operational steps of a process for registering an image according to at least one embodiment of the present invention.

[0021] Figure 7 is a flowchart (generally designated as 700) depicting the operational steps of a process for registering an image according to at least one embodiment of the present invention.

[0022] Figure 8A illustrates an example system (generally designated as 800) configured to perform one or more operations described herein according to at least one embodiment of the present disclosure.

[0023] Figure 8B illustrates another example system (generally designated as 840) configured to perform one or more operations described herein according to at least one embodiment of the present disclosure.

[0024] Figure 8C illustrates another example system (generally designated as 850) configured to utilize a smart contract according to at least one embodiment of the present disclosure.

[0025] Figure 8D illustrates yet another example system (generally designated as 860) configured to utilize a blockchain according to at least one embodiment of the present disclosure.

[0026] Figure 9A illustrates a process (generally designated as 900) for a new block to be added to a distributed ledger according to at least one embodiment of the present disclosure.

[0027] Figure 9B illustrates the content of a new data block (generally designated as 930) according to at least one embodiment of the present invention.

[0028] Figure 9C illustrates a blockchain of digital content (generally designated as 970) according to at least one embodiment of the present disclosure.

[0029] Figure 9D illustrates a block (generally designated as 990) that can represent the structure of a block in a blockchain according to at least one embodiment of the present disclosure.

[0030] While the embodiments described herein may have various modifications and alternative forms, details thereof have been shown by way of example in the drawings and will be described in detail. However, it should be understood that the particular embodiments described should not be construed as limiting. On the contrary, the invention will cover all modifications, equivalents, and alternatives falling within the spirit and scope of the present disclosure. Detailed Description

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

[0032] An NFT is a blockchain ledger entry / token representing a unique physical or digital (non-fungible) asset. The current NFT minting process directly reveals the digital asset by publishing the asset on the blockchain ledger, or indirectly reveals the digital asset by publishing the location and access information of the asset along with the hash of the asset on the ledger entry. Digital asset verification 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 for verifying that the owner has access to the original digital asset. The NFT functions similarly to a certificate of ownership, having means of verification via smart contracts, asset pointers, and other information. Just like other certificates, this does not prevent fraud or theft as the solution is one-sided. The asset can only be verified against the blockchain instance in which it is stored, which does not prevent the asset from being stolen and a new NFT from being subsequently minted on another blockchain instance. This is especially true for digital assets that are too large to be encoded as part of an NFT. Without the ability to reference NFT information from the asset, it is impossible to prove asset ownership, which in turn will not reduce fraud. Current solutions include services for verifying an NFT or checking if an NFT exists in a blockchain instance, adding a social network vector to the NFT, or scanning public sources for similar tricks. When an NFT is minted, the token id on the blockchain is returned. The NFT contains a reference to the original work and may contain relevant information required to access the original work or a token for the original work when stored in the ledger. Embodiments of the present invention include a solution for proving the ownership of an original asset without exposing the ownership certificate or the original asset.

[0034] The current NFT minting process allows for local asset verification by the client and ledger registry for tracking ownership without proof. Asset verification is performed by hashing the asset and comparing the result with the hash stored in the NFT. This requires the asset to be world visible, which enables any bad actor to download the asset, mint a new NFT claiming ownership, and publish it to the ledger. Embodiments of the present invention augment the NFT minting process by using an active hash instead of a regular hash.

[0035] Embodiments of the present invention use encrypted digital assets when minting NFTs and enable ownership verification to ensure that any potential buyer of an NFT can trust that the current owner of the NFT is legitimate. Since the digital assets are encrypted, image verification is performed by a smart contract. The smart contract is executed on a node within a trusted execution environment (TEE) to ensure that the unencrypted assets are never leaked, which ultimately results in a verification process trusted by all parties. Then, the same verification smart contract is used to prove ownership of the digital assets.

[0036] Embodiments of the present invention generate one-time numbers. A one-time number is any number that can only be used once in a cryptographic communication. One-time numbers are typically random or pseudo-random numbers used in authentication protocols to ensure that old communications cannot be fraudulently used. Embodiments of the present invention require a requester to provide a one-time number, and the owner repository performs an activity hash to prove ownership. Embodiments of the present invention improve the current method by using a derived hash instead of the original hash, making fraudulent duplication more difficult.

[0037] Embodiments of the present invention improve the existing NFT minting process by using an activity hash instead of a conventional hash. Embodiments of the present invention prevent NFT fraud and theft by never leaking the original digital assets to potential bad actors, protecting all operations by referencing encrypted instances of the original assets, preventing verification fraud by using an activity hash, using smart contracts for the minting and verification processes, and executing smart contracts using a secure environment. Embodiments of the present invention perform registry operations in the ledger, thus preventing single points of failure and enhancing the security provided by the blockchain environment.

[0038] Embodiments of the present invention perform verification by comparing the activity hash provided by the owner of the digital assets with the activity hash created by the smart contract. The activity hash consists of the hash of the combined hash of the decrypted digital image and the one-time number. The entity requesting verification provides the one-time number to be used in the activity hash. Embodiments of the present invention use the one-time number as a seed in the hash algorithm. Providing the one-time number ensures that the activity hash will have to be computed. Additionally, the use of a cashed value by the owner of the digital assets during verification is prevented.

[0039] Aspects of the present invention are described by way of textual descriptions, flowcharts, block diagrams of computer systems, and / or block diagrams of machine logic included in embodiments of a computer program product (CPP). 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 consecutive flowchart blocks may be performed in reverse order, as a single integrated step, simultaneously, or in a manner that at least partially overlaps in time.

[0040] The term "embodiment of a computer program product" ("CPP embodiment" or "CPP") as used in the present invention is used to describe any collection of one or more storage media (also referred to as "media") that together are included in a collection of one or more storage devices that together include 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 retain and store instructions for use by a computer processor. A computer-readable storage medium can be 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: floppy disks, 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 disc (DVD), memory stick, floppy disk, mechanically encoded devices (such as punch cards or pits / islands formed in the main surface of a disc), or any suitable combination of the foregoing. As used in the present invention, a computer-readable storage medium is not construed to be 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, optical pulses passing through an optical fiber, electrical signals transmitted through a wire, and / or other transmission media. As will be understood by those skilled in the art, data is typically moved at certain occasional points in time during the normal operation of a storage device, such as during access, defragmentation, or garbage collection, but this does not render the storage device transitory because the data is not transitory when stored.

[0041] The description of the various embodiments of the present invention has been presented for purposes of illustration, but is not intended to be exhaustive or limited to the disclosed embodiments. Many modifications and variations will be apparent to a person of ordinary skill in the art without departing from the scope and spirit of the described embodiments. The terms used herein were chosen to best explain the principles of the embodiments, the practical application, or the technical improvement over technologies found in the marketplace, or to enable other persons of ordinary skill in the art to understand the embodiments disclosed herein.

[0042] The flowcharts and block diagrams in the accompanying drawings illustrate the possible architectures, functions, and operations of systems, methods, and computer program products according to various embodiments of the present invention. In this regard, each block in the flowchart or block diagram may represent a module, segment, or portion of an instruction that includes one or more executable instructions for implementing the specified logical function. In some alternative embodiments, the functions recited in the blocks may occur out of the order recited in the figures. For example, two blocks shown in succession may in fact be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams and / or flowchart illustrations, and combinations of blocks in the block diagrams and / or flowchart illustrations, can be implemented by special purpose hardware-based systems that perform the specified functions or acts or combinations of special purpose hardware and computer instructions.

[0043] The present invention will now be described in detail with reference to the accompanying drawings. Figure 1 is a functional block diagram of a computing environment (generally designated 100) suitable for executing at least some of the computer code involved in performing the method of the present invention (e.g., the digital asset ownership verification code stored in block 150). In addition to block 150, the computing environment 100 also includes, for example, a computer 101, a wide area network (WAN) 102, an end user device (EUD) 103, a remote server 104, a public cloud 105, and a private cloud 106. In this embodiment, the computer 101 includes a processor group 110 (including processing circuitry 120 and cache 121), a communication fabric 111, volatile memory 112, a persistent storage device 113 (including an operating system 122 and block 150, as described above), a peripheral group 114 (including a user interface (UI) device group 123, a storage device 124, and an Internet of Things (IoT) sensor group 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 host physical machine group 142, a virtual machine group 143, and a container group 144.

[0044] The computer 101 can take the form of a desktop computer, a laptop computer, a tablet computer, a smart phone, a smart watch or other wearable computer, a mainframe computer, a quantum computer or any other form of computer or mobile device, which are now known or will be developed in the future and are capable of running programs, accessing networks or querying databases, such as the remote database 130. As understood in the field of computer technology, according to this technology, the execution of computer-implemented methods can be distributed among multiple computers and / or among multiple locations. On the other hand, in the presentation of this computing environment 100, the detailed discussion focuses on a single computer, specifically the computer 101, to keep the presentation as simple as possible. The computer 101 may be located in the cloud, although Figure 1 it is not shown in the cloud in Figure 1 . On the other hand, the computer 101 does not need to be in the cloud, unless it can be definitely pointed out to any extent.

[0045] The processor group 110 includes one or more computer processors of any type that are now known or will be developed in the future. The processing circuit 120 can be distributed over multiple packages, such as multiple coordinated integrated circuit chips. The processing circuit 120 can implement multiple processor threads and / or multiple processor cores. The cache 121 is a memory located in the processor chip package and is generally used for data or code that the threads or cores running on the processor group 110 should be able to access quickly. According to the relative proximity to the processing circuit, the cache memory is generally organized into multiple levels. Alternatively, some or all of the caches of the processor group may be located "off-chip". In some computing environments, the processor group 110 can be designed to use qubits and perform quantum computing.

[0046] Computer-readable program instructions are generally loaded onto the computer 101 so that the processor group 110 of the computer 101 executes a series of operation steps, thereby implementing the computer-implemented method, such that the instructions so executed will instantiate the flowcharts and / or the method specified in the illustrative description of the computer-implemented method contained in this document (collectively referred to as "the method of the present invention"). These computer-readable program instructions are stored in various types of computer-readable storage media, such as the cache 121 and other storage media discussed below. The program instructions and the associated data are accessed by the processor group 110 to control and directly execute the method of the present invention. In the computing environment 100, at least some of the instructions for executing the method of the present invention can be stored in block 150 of the persistent storage device 113.

[0047] The communication structure 111 is a signal conduction path that allows various components of the computer 101 to communicate with each other. Generally, this structure consists of switches and conductive paths, such as the switches and conductive paths that make up a bus, a bridge, a physical input / output port, etc. Other types of signal communication paths can be used, such as fiber optic communication paths and / or wireless communication paths.

[0048] The volatile memory 112 is any type of volatile memory known currently or developed in the future. Examples include dynamic type random access memory (RAM) or static type RAM. Generally, the volatile memory 112 is characterized by random access, but this is not required unless explicitly indicated. In the computer 101, the volatile memory 112 is located in a single package and inside the computer 101. However, optionally or additionally, the volatile memory can be distributed across multiple packages and / or be located externally relative to the computer 101.

[0049] The persistent storage device 113 is any form of non-volatile storage device of a computer known currently or to be developed in the future. The non-volatility of this storage device means that the stored data will be retained regardless of whether power is supplied to the computer 101 and / or whether power is directly supplied to the persistent storage device 113. The persistent storage device 113 can be a read-only memory (ROM), but generally at least a part of the persistent storage device allows writing, deleting, and rewriting of data. Some common forms of persistent storage devices include magnetic disks and solid-state storage devices. The operating system 122 can take various forms, such as various known proprietary operating systems or open-source portable operating system interface type operating systems that employ a kernel. The code included in block 150 generally includes at least some computer code involved in performing the method of the present invention.

[0050] The peripheral device group 114 includes the peripheral device group of the computer 101. The data communication connection between the peripheral devices and other components of the computer 101 can be implemented in various ways, such as a Bluetooth connection, a Near Field Communication (NFC) connection, a cable connection (such as a Universal Serial Bus (USB) type cable), a plug-in connection (such as a Secure Digital (SD) card), a connection through a local communication network, or even a connection through a wide area network such as the Internet. In various embodiments, the UI device group 123 may include components such as a display screen, a speaker, a microphone, wearable devices (such as goggles and smartwatches), a keyboard, a mouse, a printer, a touchpad, a game controller, and a haptic device. The storage device 124 is an external storage device (such as an external hard disk drive) or a plug-in memory (such as an SD card). The storage device 124 can be persistent and / or volatile. In some embodiments, the storage device 124 may take the form of a quantum computing storage device for storing data in the form of qubits. In embodiments where the computer 101 needs to have a large amount of storage (for example, the computer 101 locally stores and manages a large database), the storage device may be provided by a peripheral storage device designed to store a very large amount of data, such as a Storage Area Network (SAN) shared by multiple geographically dispersed computers. The IoT sensor group 125 includes sensors that can be used in Internet of Things applications. For example, one sensor can be a thermometer and another sensor can be a motion detector.

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

[0052] The WAN 102 is any wide area network (such as the Internet) capable of transmitting computer data over non-local distances by any technique for transmitting computer data, now known or hereafter developed. In some embodiments, the WAN 102 may be replaced and / or supplemented by a local area network (LAN) designed to transmit data between devices located in a local area such as a Wi-Fi network. The WAN and / or LAN typically includes computer hardware such as copper transmission cables, optical transmission fibers, wireless transmissions, routers, firewalls, switches, gateway computers, and edge servers.

[0053] The end user device (EUD) 103 is any computer system used and controlled by an end user (e.g., a customer of the enterprise operating the computer 101) and may take any form discussed above in connection with the computer 101. The EUD 103 typically receives helpful and useful data from the operation of the computer 101. For example, in the hypothetical case where the computer 101 is designed to provide recommendations to an end user, the recommendation will typically be transmitted from the network module 115 of the computer 101 through the WAN 102 to the EUD 103. Thus, the EUD 103 can display or otherwise present the recommendation to the end user. In some embodiments, the EUD 103 can be a client device such as a thin client, thick client, mainframe, desktop, etc.

[0054] The remote server 104 is any computer system that provides at least some data and / or functionality to the computer 101. The remote server 104 may be controlled and used by the same entity that operates the computer 101. The remote server 104 represents a machine for collecting and storing useful data for use by other computers (such as the computer 101). For example, in the hypothetical case where the computer 101 is designed and programmed to provide recommendations based on historical data, the historical data may be provided to the computer 101 from the remote database 130 of the 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 computing capabilities (notably data storage (cloud storage) and computing power) without the need for direct active management by the user. Cloud computing typically exploits resource sharing to achieve consistency and economies of scale. The direct active management of the public cloud 105 computing resources is performed by the computer hardware and / or software of the cloud orchestration module 141. The computing resources provided by the public cloud 105 are typically implemented by virtual computing environments running on various computers that make up the host physical machine group 142, which are the various physical computers within and / or available for the public cloud 105. A virtual computing environment (VCE) typically takes the form of virtual machines from a virtual machine group 143 and / or containers from a container group 144. It will be appreciated that these VCEs can be stored as images and can be transferred between individual physical machine hosts either as an image or after the VCE has been instantiated. The cloud orchestration module 141 manages the transfer and storage of the images, deploys new instances of the VCE, and manages the active instances of the VCE deployment. The gateway 140 is a collection of computer software, hardware, and firmware that allows the public cloud 105 to communicate over the WAN 102.

[0056] Some further explanation of virtualized computing environments (VCEs) will now be provided. A VCE can be stored as an "image". New active instances of a VCE can be instantiated from the image. Two familiar types of VCEs are virtual machines and containers. A container is a VCE that uses operating system-level virtualization. This refers to an operating system feature where the kernel allows for the existence of multiple isolated user space instances (called containers). From the perspective of the programs running within them, these isolated user space instances typically appear as real computers. A computer program running on a normal operating system can utilize all the resources of that computer, such as connected devices, files and folders, network shares, CPU capabilities, and quantifiable hardware capabilities. However, a program running within a container can only use the contents of that container and the devices allocated to that container, a feature known as containerization.

[0057] A private cloud 106 is similar to the public cloud 105, except that the computing resources are only available for use by a single enterprise. Although the private cloud 106 is depicted as communicating with the WAN 102, in other embodiments, the private cloud can be completely disconnected from the Internet and only accessible through a local / private network. A hybrid cloud is a combination of multiple clouds of different types (such as private, community, or public cloud types), typically implemented separately by different providers. Each of the multiple clouds remains an independent discrete entity, but the larger hybrid cloud architecture is bound together through standardized or proprietary technologies to support orchestration, management, and / or data / application portability between the multiple component clouds. In this embodiment, the public cloud 105 and the private cloud 106 are both part of a larger hybrid cloud.

[0058] Figure 2A Illustrates an example blockchain architecture configuration according to at least one embodiment of the present invention. The blockchain architecture 200 may include specific blockchain elements, such as a set of blockchain nodes 202. The blockchain nodes 202 may include one or more nodes 204 and 210 (these four nodes are depicted by way of example only). These nodes participate in multiple activities, such as the blockchain transaction addition and verification process (consensus). The blockchain nodes may initiate blockchain authentication and attempt to write to the blockchain immutable ledger stored in the blockchain layer 216, and a copy of this immutable ledger may also be stored on the underlying physical infrastructure 214. The blockchain configuration may include one or more applications 224, and one or more applications 224 are linked to an application programming interface (API) 222 to access and execute the stored program / application code 220 (e.g., chain code, smart contracts, etc.), and these program / application codes 220 may be created according to the customized configuration sought by the participants, and may maintain their own states, control their own assets, and receive external information. This may be deployed as a transaction and installed on all blockchain nodes 204 - 210 via attachment to the distributed ledger.

[0059] The blockchain foundation 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, which may be used to receive and store new transactions and provide access to auditors attempting to access data entries. The blockchain layer 216 may publicly provide an interface for accessing the handler code and the virtual execution environment necessary for participating in the physical infrastructure 214. The cryptographic trust service 218 may be used to verify transactions such as asset exchange transactions and keep information private.

[0060] Figure 2AThe blockchain architecture configuration can process and execute program / application code 220 via one or more interfaces exposed by blockchain platform 212 and services provided by blockchain platform 212. The code 220 can control blockchain assets. For example, the code 220 can store and transmit data and can be executed by nodes 204 - 210 in the form of smart contracts and associated chain codes, which have conditions or other code elements restricted to their execution. As a non - limiting example, a smart contract can be created to perform generation of storage space, reservation of storage space, update of current transaction protocols, etc. The smart contract itself can be used to identify rules associated with authorization and access requirements to the ledger and its use. For example, document attribute information 226 can be processed by one or more processing entities (e.g., virtual machines) included in blockchain layer 216. The result 228 can include multiple linked shared documents (e.g., where each linked shared document records the issuance of the smart contract, etc.). Physical infrastructure 214 can be used to obtain any data or information described herein.

[0061] Smart contracts can be created via high - level application and programming languages and then written into blocks in the blockchain. A smart contract can include executable code that is registered, stored, and / or replicated to the blockchain (e.g., a distributed network of blockchain peers). A transaction is the execution of smart contract code, and the transaction can be executed in response to conditions associated with the smart contract being met. The execution of a smart contract can trigger a (one or more) trusted modification to the state of the digital blockchain ledger. The (one or more) modifications to the blockchain ledger caused by the execution of the smart contract can be automatically replicated across the distributed network of blockchain peers via one or more consensus protocols.

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

[0063] The chaincode can include the code interpretation of the smart contract and have additional features. As described herein, the chaincode can be program code deployed on a computing network, where it is executed and verified together by the chain validators during the consensus process. The chaincode receives a hash and obtains 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 matches the hash created from the stored identifier template data, the chaincode sends an authorization key to the requested service. The chaincode can write data associated with password details to the blockchain (e.g., thus establishing a new smart contract between a user and a licensor).

[0064] Figure 2B An example of the blockchain transaction flow 250 between nodes of a blockchain according to at least one embodiment of the present invention is shown. Referring Figure 2B , the transaction flow can include a transaction proposal 291 sent by an application client node 260 to an endorsing peer node 281 (e.g., in some embodiments, a transaction proposal 291 can be sent to determine the ownership or authentication of a digital asset). The endorsing peer 281 can verify the client signature and execute the chaincode function to initiate the transaction. The output can include the chaincode result, a set of key / value versions read in the chaincode (read set), and a set of key / values written in the chaincode (write set). If approved, the proposal response 292 is sent back to the client 260 along with the endorsement signature. The client 260 assembles the endorsements into a transaction payload 293 and broadcasts it to the ordering service node 284. Then, the ordering service node 284 delivers the ordered transactions as blocks on the channel to all peers 281 - 283. Before submitting to the blockchain, each peer 281 - 283 can verify the transaction. For example, a peer can check the transaction terms, ownership, or other digital asset data to ensure the correct allocation and distribution of the assets used for the transaction payload 293.

[0065] Referring again Figure 2B , the client node 260 initiates a transaction 291 by constructing a request and sending the request to a peer node 281 acting as an endorser. The client 260 can include an application that utilizes a supported software development kit (SDK), which utilizes available APIs to generate a transaction proposal. The proposal is a request to invoke a chaincode function such that data can be read and / or written to the ledger (e.g., writing a new key - value pair for an asset). The SDK can act as a shim to encapsulate the transaction proposal into an appropriate structured format (e.g., protocol buffers over remote procedure call (RPC)) and take the client's cryptographic certificate to produce a unique signature for the transaction proposal.

[0066] In response, the endorsing peer 281 can verify (a) whether the transaction proposal is in the correct format, (b) that the transaction has not been submitted in the past (replay attack protection), (c) that the signature is valid, and (d) that the submitter (the client 260 in this example) is properly authorized to perform the proposed operation on the channel. The endorsing peer 281 can input the transaction proposal as an argument to the invoked chaincode function. The chaincode is then executed against the current state database to produce a transaction result that includes a response value, a read set, and a write set. However, the ledger is not updated at this time. At 292, this set of values, along with the signature of the endorsing peer 281, is passed back as a proposal response 292 to the SDK of the client 260, which parses the payload for use by the application.

[0067] In response, the application of the client 260 checks / verifies the endorsing peer signature and compares the proposal response to determine if the proposal responses are the same. If the chaincode only queries the ledger, the application will check the query response and generally does not submit the transaction to the ordering node service 284. If the client application intends to submit the transaction to the ordering node service 284 to update the ledger, the application determines whether the specified endorsement policy has been satisfied before submission (e.g., whether all peers required for the transaction have endorsed the transaction). Here, the client can include only one of the multiple parties to the transaction. In such a case, each client can have its own endorsing node, and each endorsing node will need to endorse the transaction. This architecture enables the endorsement policy to be enforced by the peers and supported during the commit confirmation phase even if the application chooses not to check the response or otherwise forward unendorsed transactions.

[0068] After successful checking, at step 293, the client 260 assembles the endorsements into a transaction and broadcasts the transaction proposal and response within the transaction message to the ordering node 284. The transaction can include the read / write set, the endorsing peer signature, and the channel ID. The ordering node 284 does not need to check the entire contents of the transaction to perform its operation. Instead, the ordering node 284 can simply receive transactions from all channels in the network, sort them in chronological order by channel, and create transaction blocks by channel.

[0069] The transaction block is delivered from the ordering node 284 to all peer nodes 281 - 283 on the channel. The transactions 294 within the block are verified to ensure that any endorsement policies are met and to ensure that there have been no changes to the ledger state of the read set variables since the read set was generated by the transaction execution. The transactions in the block are marked as valid or invalid. Additionally, at step 295, each peer node 281 - 283 appends the block to the chain of that block, and for each valid transaction, the write set is committed to the current state database. Events are emitted to notify the client application that the transaction (call) has been immutably appended to the chain and to notify whether the transaction is valid or invalid.

[0070] Figure 3 is a functional block diagram of a digital asset ownership verification system (generally designated 300) operative for a digital asset trading program 301 in accordance with at least one embodiment of the present invention. The digital asset ownership verification system 300 may be implemented in a computing environment such as the computing environment 100 described in reference Figure 1 and provides an illustration of only one implementation and does not imply any limitation as to the environments in which different embodiments may be implemented. Those skilled in the art may make many modifications to the depicted environment without departing from the scope of the present invention as claimed. Figure 3

[0071] The digital asset ownership verification system 300 includes a user device 310, a server 320, a smart contract 330, an untrusted ledger 350, ledgers 360A and 360B, blockchains 370A and 370B, blockchain nodes 380A - 380N, and TEEs 390A - 390N interconnected via a network such as the WAN 102. Generally, the 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 the server 320 and other devices (not shown) via a network such as the WAN 102. In one embodiment, the user device 310 is an end-user device such as the EUD 103 depicted in Figure 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 smart phone, a wearable device (e.g., smart glasses, smart watches, e-textiles, AR headsets, etc.), or any programmable computer system known in the art.

[0072] ​The user device 310 further includes a user interface 312, an application 314, and a wallet 316. The user interface 312 is a program that provides an interface between the user of an end-user device such as the user device 310 and multiple applications (e.g., the application 314) residing on the device. A user interface such as the user interface 312 is concerned with the information (such as graphics, text, and sound) presented to the user by the program, as well as the control sequences used by the user to control the program. There are various types of user interfaces. In one embodiment, the 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 an electronic device (such as a computer keyboard and mouse) through graphical icons and visual indicators (such as assistive symbols), as opposed to a text-based interface, typed command labels, or text navigation. In computing, the GUI was introduced as a reaction to the perceived steep learning curve of command-line interfaces that require commands to be typed on a keyboard. Actions in a GUI are typically performed by directly manipulating graphical elements. In another embodiment, the user interface 312 is a script or an application programming interface (API).

[0073] The application 314 may represent one or more applications (e.g., an application suite) operating on the user device 310. In one embodiment, the application 314 represents one or more applications (e.g., an asset holding application, an asset market application, and an asset authentication application) located on the user device 310. For example, the user accesses asset holding software via the application 314 to purchase digital assets. In another example, the user uploads digital assets online via the application 314. In various example embodiments, the application 314 may be an application for a user of the user device 310 to access an asset market website and post digital assets for sale, trading, offer, or purchase. In one embodiment, the application 314 may be a client-side application associated with a server-side application running on the server 320 (e.g., a client-side application associated with the digital asset ownership verification program 301). In one embodiment, the application 314 may operate to perform the processing steps of the digital asset ownership verification program 301 (i.e., the application 314 may represent the digital asset ownership verification program 301 operating on the user device 310).

[0074] The wallet 316 is a digital or cryptocurrency wallet. In one embodiment, the wallet 316 includes information associated with one or more public and private keys corresponding to digital assets. In one embodiment, the wallet 316 includes information about one or more digital assets. In one embodiment, the digital assets include NFTs, cryptocurrencies, funds, or other digital assets. In one embodiment, the 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) within a network such as WAN 102. In one embodiment, server 320 is a stand-alone device capable of running programs and accessing a network or querying a database, such as Figure 1 the computer 101 depicted in

[0076] In one embodiment, object repository 322 stores information about digital assets. In one embodiment, object repository 322 is an object storage service running 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 registered, stored, and / or replicated using a blockchain. A transaction is the execution of smart contract code, which can be executed in response to conditions associated with the smart contract being met, such as transferring an NFT from one cryptocurrency wallet to another. In one embodiment, digital asset owner verifier 301 accesses a smart contract associated with a digital asset, such as smart contract 330, to verify that a first liveness hash matches the hash of the digital asset and a first one-time number.

[0078] In one embodiment, smart contract 330 includes digital asset ownership verifier 301. In one embodiment, digital asset ownership verifier 301 is a registry and is a subset of smart contract 330. Digital asset ownership verifier 301 can be at least partially from a reference Figure 1The digital asset ownership verification code 150 depicted and described is formed. In one embodiment, the digital asset ownership verification program 301 is separate from the smart contract 330. For example, in some embodiments, the digital asset ownership verification program 301 is included in the server 320. In one embodiment, the smart contract 330 and the 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 digital wallet, which may include personal data, content, context data, or information that the user does not want to be processed. Personal data includes personally identifiable information or sensitive personal information, as well as user information such as location tracking or geographical location information. Processing refers to any operation (automatic or non-automatic) or set of operations, such as collecting, recording, organizing, structuring, storing, adapting, altering, retrieving, consulting, using personal data, making personal data available by transmission, publication, dissemination, or otherwise, 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 and notifies of the collection of personal data, thus allowing the user to choose to process personal data or choose not to process personal data. Consent can take several forms. Opt-in consent may force the user to take an affirmative action before personal data is processed. Alternatively, opt-out consent may force the user to take an affirmative action to prevent the processing of personal data before it is processed. In one embodiment, the digital asset owner verification program 301 provides information about the nature of the personal data and the processing (e.g., type, scope, purpose, duration, etc.). 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 incorrect 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, the smart contract 330 is written to the blockchain in the form of key-value pairs. Additionally, the smart contract code can be structured to read values stored in the blockchain and use these values in application operations. The smart contract code can be structured to write the output of various logical operations to the blockchain. The code can be used to create temporary data structures in a virtual machine or other computing platform. The data written to the blockchain can be public and / or can be encrypted and kept private. The temporary data used / generated by the smart contract is saved in memory by the supplied execution environment and then deleted once the data required by the blockchain is identified.

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

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

[0083] In one embodiment, the digital asset ownership verification program 301 is a smart contract, such as the smart contract 330. In these embodiments, the digital asset ownership verification program 301 runs within a blockchain peer. In one embodiment, the server 320 is a smart contract, such as the smart contract 330. In these embodiments, a key - value store or an object store is configured to run within each smart contract 330. In one embodiment, the key - value store or the object store is an object stored within a blockchain peer or a decentralized object storage system accessible by the blockchain peer as an oracle. A blockchain oracle is an entity that connects the blockchain to an external system so that the smart contract can execute based on inputs and outputs.

[0084] The distributed ledger 350 includes one or more independent computers or nodes (such as ledgers 360A and 360B and blockchain nodes 380A - 380N) for sharing and synchronizing transactions in their respective electronic ledgers. In one embodiment, the distributed ledger 350 is stored in a local blockchain (such as blockchain 370A or 370B).

[0085] Ledgers 360A and 360B include one or more ledgers capable of executing blockchains (such as blockchains 370A and 370B).

[0086] The blockchain 370A and 370B can be configured to use one or more smart contracts that manage transactions of multiple participating nodes, such as the smart contract 330. In some embodiments, a neural network and / or any form of machine learning can be used by a cloud service provider to analyze smart contracts and / or transaction requests to determine transaction terms or authentication information. In one embodiment, the blockchain 370A and 370B can store data to be shared among nodes such as the blockchain node 380. In one embodiment, the blockchain 370A and 370B can be represented by a blockchain architecture configuration 200 as described in reference Figure 2A described.

[0087] The blockchain nodes 380A - 380N include one or more nodes. In one embodiment, the blockchain nodes 380A - 380N can be represented by a blockchain node 202 as previously referenced Figure 2A described.

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

[0089] In one embodiment, the digital asset ownership verification program 301 receives a digital asset and generates a one - time number for the digital asset. In one embodiment, the digital asset is an image or other multimedia, and the digital asset ownership verification program 301 receives the one - time number in a request to verify the digital asset. In one embodiment, the one - time number is a randomly generated number that is used only once. In one embodiment, the digital asset ownership verification program 301 adds the one - time number to the hash of the encrypted image or digital asset. In one embodiment, image encryption is the process of encoding an image with an encryption algorithm so that unauthorized users cannot access the image. In one embodiment, the digital asset ownership verification program 301 generates an activity hash based on the image and the one - time number, such as activity hash = sha256(sha256(image) || one - time number). In one embodiment, the activity hash includes the one - time number value as a challenge sent by the user, and the returned hash of the image and the one - time number is a response token to the challenge.

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

[0091] In one embodiment, the digital asset ownership verification program 301 decrypts the encrypted image and the private key, such as image = decrypt(enc image, PrivKey) (image = decrypt(encrypted image, PrivKey)). In one embodiment, the digital asset ownership verification program 301 accesses a smart contract to verify that the liveness hash matches the hash of the image and the one-time number, such as verifying: liveness hash == sha256(sha256(image) || one-time number) (livenesshash == sha256(sha256(image) || nonce)). In one embodiment, the digital asset ownership verification program 301 stores an encrypted image record including the initial liveness hash and the encrypted image on the blockchain, such as storing the image record: <initial liveness hash, image>.

[0092] In one embodiment, the digital asset ownership verification program 301 receives a request to authenticate the ownership of a digital asset. In one embodiment, the digital asset ownership verification program 301 decrypts the received image id with the private key, such as image = decrypt(get(image id), PrivKey). In one embodiment, the digital asset ownership verification program 301 verifies that a second liveness hash matches the hash of the image and the one-time number, such as verifying: liveness hash 2 == sha256(sha256(image) || one-time number 2) (liveness hash 2 == sha256(sha256(image) || nonce2)). In one embodiment, if the second liveness hash matches the liveness hash of the image and the one-time number, the digital asset ownership verification program 301 verifies the ownership.

[0093] In one embodiment, the digital asset ownership verification program 301 receives a request from a user to verify the digital assets currently owned by another user. In one embodiment, the digital asset verification program 301 receives from the digital asset owner the hash of the original asset and the liveness hash of the one-time number. In one embodiment, the digital asset verification program 301 receives from the digital asset owner the liveness hash, the one-time number, and a reference to the encrypted image (image ID). In one embodiment, the digital asset ownership verification program 301 generates an encrypted instance of the original asset and the liveness hash. In one embodiment, the digital asset ownership verification program 301 publishes the encrypted instance of the original asset on the blockchain ledger and references the liveness hash of the original asset. In one embodiment, the digital asset ownership verification program 301 uses a smart contract in the blockchain ledger (e.g., the smart contract 330 executed in a trusted execution environment such as the TEE 390A - 390N) to determine the consensus of the liveness hash.

[0094] In one embodiment, a direct request for proof of ownership is made from a user to the owner, or the request is forwarded to the owner and the digital asset verification program 301. In another embodiment, the digital asset ownership verification program 301 receives a verification request for a digital asset from a user and sends the request to the registry (NFT, liveness hash (H), one-time number (N)). In one embodiment, the digital asset ownership verification program 301 determines or receives a smart contract for the digital asset. In one embodiment, the digital asset ownership verification program 301 receives or determines the encrypted digital asset (Ae). In one embodiment, the digital asset ownership verification program 301 verifies the hash (Ae, H, N). In one embodiment, the digital asset ownership verification program 301 determines or receives the registry private key (RPk). In one embodiment, the digital asset ownership verification program 301 verifies the hash (Ae, H, N, RPk). In one embodiment, the digital asset ownership verification program 301 decrypts the digital asset. In one embodiment, the digital asset ownership verification program 301 calculates the liveness hash (H') of the digital asset. In one embodiment, the digital asset ownership verification program 301 performs verification at least in part based on the first liveness hash H matching the second liveness hash H' (H == H'). In one embodiment, the digital asset ownership verification program 301 sends a verification of ownership to the user. In one embodiment, the digital asset ownership verification program 301 sends real ownership information from the smart contract TEE to the smart contract. In one embodiment, the digital asset ownership verification program 301 sends the information of real ownership from the smart contract to the registry.

[0095] In one example, the digital asset ownership verification program 301 uses public key and private key authentication to authenticate digital assets using a ledger. The digital asset ownership verification program 301 requests registration of the public key (Rpk). The digital asset ownership verification program 301 generates a public key and private key PAR and registers the key pair. The digital asset ownership verification program 301 generates a one-time number (Nr). The digital asset ownership verification program 301 generates a hash (Ah) of the digital asset, such as sha256(asset). The digital asset ownership verification program 301 generates a liveness hash (LHr) by determining the one-time number (Nr) and the liveness hash (Ah), such as SHA256(Ah|Nr). The digital asset ownership verification program 301 encrypts the asset using the registry public key (Aenc) = encrypt(Rpk)(asset). The digital asset ownership verification program 301 sends the encrypted asset along with the unique key (LHr:Nr) including the liveness hash and the one-time number to a registry repository, such as Figure 3 the object repository 322 depicted in. For example, the registry can use an object repository or other key / value repository where the address is LHr:Nr and the value is the encrypted asset. The digital asset ownership verification program 301 receives a request to mint an NFT digital asset into the registry, where the input includes the public owner, the owner's public key, the storage key (Sk) = LH:Nr, the repository URL, the liveness hash (LHr), and the one-time number (Nr).

[0096] In another example, the digital asset ownership verification program 301 determines a verification one-time number (Nv) for the digital asset. The digital asset ownership verification program 301 sends a verification request to the owner of the digital asset with the verification one-time number (Nv) and the digital asset address. The owner processes the request, and the digital asset ownership verification program 301 receives a response. The digital asset ownership verification program 301 retrieves digital access at least in part based on the asset hash (Ah) = sha256(image) and the liveness hash (H) = sha256(Ah|Nv) and calculates the liveness hash using the verification one-time number (Nv). The digital asset ownership verification program 301 sends a reply with the new liveness hash (H) to the user. The user sends the received liveness hash (H) with the verification one-time number (Nv) and the digital asset reference to the registry for verification. The registry receives an ownership verification request, where the input request includes the digital asset reference H and the one-time number flag (Nv) from the user. The registry retrieves the encrypted asset from the address (URL) and the smart contract reference from the digital asset. The registry calls the smart contract with the input having the owner's liveness hash (H), the encrypted asset, and the one-time number (Nv). The digital asset ownership verification program 301 sends the consensus result from the smart contract to the user.

[0097] In one example, the owner requests the public key for the encrypted image from the smart contract 330. Here, the public key is returned by the smart contract (the public / private key pair stored in the blockchain environment). The owner creates a one-time number, calculates the liveness hash of the original image and the one-time number, encrypts the original image with the public key, and sends the encrypted image, the one-time number, and the liveness hash of the registration smart contract. Here, the digital asset ownership verifier 301 receives the encrypted image, the one-time number, and the liveness hash of the registration smart contract from the owner. The digital asset ownership verifier 301 performs the verification of the liveness hash. The digital asset ownership verifier 301 stores the encrypted image in a storage service or repository using the initial liveness hash as the key. The digital asset ownership verifier 301 creates an NFT that includes the storage service address and the key (initial liveness hash) of the encrypted image. The digital asset ownership verifier 301 stores the encrypted image in a storage service (such as cloud object storage (COS)) outside the blockchain environment.

[0098] In another example, the digital asset ownership verifier 301 receives an image or NFT, the generated one-time number, and the calculated liveness hash from the user. In one embodiment, the liveness hash is used to create an NFT in place of the standard 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 verifier 301 performs a registration process. In one embodiment, in response to receiving a request for the public key from a first user, the digital asset ownership verifier 301 sends the public key to the first user. In one embodiment, the digital asset ownership verifier 301 generates a public / private key pair and sends the public key to the first user. In one embodiment, the digital asset ownership verifier 301 receives an encrypted image, a one-time number, and a liveness hash from user A. In one embodiment, the digital asset ownership verifier 301 decrypts the image and calculates the liveness hash of the image using the one-time number received from user A. In one embodiment, if the digital asset ownership verifier 301 determines that the validity hash received by user A matches the calculated validity hash, the digital asset ownership verifier 301 stores the image. In one embodiment, the original liveness hash is used as the key for the encrypted image in the storage system.

[0100] In one embodiment, the digital asset ownership verification program 301 performs an ownership verification process. In one example, a second user sends a proof of ownership request with a one-time number to a first user. In one example, the first user uses the one-time number received from the second user to determine an activity hash. In one embodiment, the digital asset ownership verification program 301 sends the determined activity hash with the one-time number received from the second user to the second user. In one embodiment, the digital asset ownership verification program 301 receives a verification request from the second user that includes the one-time number, an image id, and the returned activity hash. In one embodiment, the digital asset ownership verification program 301 decrypts the image and uses the received one-time number to determine an activity hash. In one embodiment, if the two activity hashes match, the digital asset ownership verification program 301 determines that the ownership is valid. In one embodiment, if the activity hashes do not match, the digital asset ownership verification program 301 determines that the ownership is valid.

[0101] Figure 4 is a flowchart (generally designated as 400) depicting the operational steps of the digital asset ownership verification program 301 in accordance with at least one embodiment of the present invention. Figure 4 Only an illustration of one implementation is provided and does not imply any limitation on the environments in which different embodiments may be implemented. Those skilled in the art may make many modifications to the depicted environments without departing from the scope of the present invention as set forth in the claims.

[0102] In step S402, user A obtains 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 one-time number. In one embodiment, the one-time number is a randomly generated number.

[0104] In step S406, user A generates a first activity hash. In one embodiment, user A generates an activity hash based on the image and the one-time number, such as activity hash = sha256(sha256(image) || one-time number).

[0105] In step S408, the digital asset ownership verification program 301 receives an encryption public key (PubKey). In one embodiment, the digital asset ownership verification program 301 generates an encryption public key in response to a request from user A for a public key to encrypt the 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 verification 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 verification program 301 sends an encrypted public key for the image. In one embodiment, the digital asset ownership verification program 301 sends the public key from the registry smart contract to User A.

[0107] In step S412, the digital asset ownership verification program 301 encrypts the digital asset image and the public key using a one-time number and a first activity hash. In one embodiment, the digital asset ownership verification program 301 encrypts the digital asset using the public key. In one embodiment, the digital asset ownership verification program 301 determines the activity hash using the image hash and the one-time number. In one embodiment, the digital asset ownership verification program 301 receives a registration request with the encrypted image, the one-time number, and the activity hash.

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

[0109] In step S416, the digital asset ownership verification program 301 verifies that the first activity hash = sha256(sha256(image) || one-time number).

[0110] In step S418, the digital asset ownership verification program 301 stores the image record: <initial activity hash, image>.

[0111] In step S420, the digital asset ownership verification program 301 receives a request for proof of ownership, one-time number 2. In one embodiment, the digital asset ownership verification program 301 receives a request for proof of ownership from User B.

[0112] In step S422, the digital asset ownership verification program 301 determines the activity hash 2 = sha256(sha256(image) || one-time number 2), image id. In one embodiment, the digital asset ownership verification program 301 sends the determined activity hash 2 = sha256(sha256(image) || one-time number 2), image id from User A to User B.

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

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

[0115] In step S428, the digital asset ownership verification program 301 verifies that the activity hash 2 == sha256(sha256(image) || one-time number 2). In one embodiment, the digital asset ownership verification program 301 determines that the first activity hash matches the second activity hash.

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

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

[0118] In step S434, the digital asset ownership verification program 301 sends the information associated with the non-genuine ownership to user A or user B.

[0119] Figure 5 is a flowchart (generally designated as 500) depicting the operating steps of the digital asset ownership verification program 301 according to at least one embodiment of the present invention. Figure 5 Only an illustration of one implementation is provided and does not imply any limitation on the environments in which different embodiments can be implemented. Those skilled in the art can make many modifications to the depicted environments without departing from the scope of the present invention as set forth in the claims.

[0120] In step S502, the digital asset ownership verification program 301 receives a verification request for the digital asset (NFT, activity hash (H), one-time number (N)). In one embodiment, the digital asset ownership verification program 301 receives a verification request for the digital asset from user A.

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

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

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

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

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

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

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

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

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

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

[0131] Figure 6 is a flowchart (generally designated 600) depicting the operational steps for the process of registering an image according to at least one embodiment of the present invention. Figure 6 Only an illustration of one implementation is provided and does not imply any limitation to the environments in which different embodiments can be implemented. Those skilled in the art can make many modifications to the depicted environments without departing from the scope of the present invention as set forth in the claims.

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

[0133] In step S604, the digital asset ownership verification program 301 receives the encrypted digital asset, the first activity hash, and the first one-time number from the owner of the digital asset. In one embodiment, the digital asset is encrypted using the public key. In one embodiment, the first activity hash is generated at least in part based on the digital asset in unencrypted form and the first one-time number.

[0134] In decision step S606, the digital asset ownership verification program 301 determines whether the first activity hash is valid. In one embodiment, the digital asset ownership verification program 301 transforms the encrypted digital asset back to the unencrypted digital asset using the private key associated with the digital asset. In one embodiment, the digital asset ownership verification program 301 generates a second activity hash based on the unencrypted digital asset and the first one-time number. In one embodiment, the digital asset ownership verification program 301 matches the first activity hash with the second activity hash. If the digital asset ownership verification program 301 determines that the first activity hash is valid (the "yes" branch of decision step S606), then the digital asset ownership verification program 301 proceeds to step S608. If the digital asset ownership verification program 301 determines that the first activity hash is invalid (the "no" branch of decision step S606), then the digital asset ownership verification program 301 ends.

[0135] In step S608, the digital asset ownership verification program 301 generates a digital asset record. In one embodiment, the digital asset record includes the encrypted digital asset and the first activity hash. In one embodiment, the digital asset ownership verification 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] Figure 7 is a flowchart (generally designated 700) depicting the operational steps of a process for registering an image according to at least one embodiment of the present invention. Figure 7 Only an illustration of one implementation is provided and does not imply any limitation on the environments in which different embodiments may be implemented. Those skilled in the art may make many modifications to the depicted environments without departing from the scope of the present invention as set forth in the claims.

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

[0138] In step S704, in response to receiving the request for the owner of the digital asset to provide proof of ownership of the digital asset, the digital asset ownership verification program 301 sends the second one-time number to the owner of the digital asset.

[0139] In step S706, the digital asset ownership verification program 301 receives from the owner of the digital asset an image id associated with the digital image and a third liveness hash. In one embodiment, the second liveness hash is generated at least in part based on the digital asset in unencrypted form and the second one-time number.

[0140] In step S708, the digital asset ownership verification program 301 verifies the proof of ownership of the digital asset. In one embodiment, verifying the proof of ownership of the digital asset is at least in part based on obtaining the encrypted digital asset from the digital asset record using the image id. In one embodiment, verifying the proof of ownership of the digital asset is at least in part based on transforming the encrypted digital asset back to the unencrypted digital asset using the private key associated with the digital asset. In one embodiment, verifying the proof of ownership of the digital asset is at least in part based on generating a fourth liveness hash based on the unencrypted digital asset and the second one-time number. In one embodiment, verifying the proof of ownership of the digital asset is at least in part based on matching the first liveness hash with the second liveness hash.

[0141] In step S710, in response to verifying the proof of ownership of the digital asset, the digital asset ownership verification program 301 sends an authentication that the owner of the digital asset is valid to the requesting entity.

[0142] Figure 8A An example system 800 is shown that includes a physical infrastructure 810 configured to perform various operations in accordance with an embodiment of the present disclosure. Refer to Figure 8A, the physical infrastructure 810 includes module 812 and module 814. Module 814 includes blockchain 820 and smart contract 830 (which may reside on blockchain 820), which can perform any operation steps 808 (in module 812) included in any exemplary embodiment. Step / operation 808 may include one or more of the described or depicted embodiments and may represent output or write information written or read from one or more smart contracts 830 and / or blockchain 820. Physical infrastructure 810, module 812, and module 814 may include one or more computers, servers, processors, memories, and / or wireless communication devices. Additionally, module 812 and module 814 may be the same module.

[0143] Figure 8B Another example system 840 configured to perform various operations in accordance with an embodiment of the present disclosure is shown. Referring to Figure 8B , system 840 includes module 812 and module 814. Module 814 includes blockchain 820 and smart contract 830 (which may reside on blockchain 820), which can perform any operation steps 808 (in module 812) included in any exemplary embodiment. Step / operation 808 may include one or more of the described or depicted embodiments and may represent output or write information written or read from one or more smart contracts 830 and / or blockchain 820. Physical modules 812 and module 814 may include one or more computers, servers, processors, memories, and / or wireless communication devices. Additionally, module 812 and module 814 may be the same module.

[0144] Figure 8C An example system configured to utilize a smart contract configuration between contracting parties and a mediation server configured to enforce smart contract terms on a blockchain in accordance with an embodiment of the present disclosure is shown. Referring to Figure 8C , configuration 850 may represent a communication session, asset transfer session, or process or procedure driven by smart contract 830 that explicitly identifies one or more user devices 852 and / or 856. The execution, operation, and results of smart contract execution may be managed by server 854. The content of smart contract 830 may require digital signatures of one or more of entities 852 and 856 that are parties to the smart contract transaction. The results of smart contract execution may be written to blockchain 820 as a blockchain transaction. Smart contract 830 resides on blockchain 820, which may reside on one or more computers, servers, processors, memories, and / or wireless communication devices.

[0145] Figure 8D A system 860 including a blockchain in accordance with an embodiment of the present disclosure is shown. Referring to Figure 8DIn an example, 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., distributed ledger, etc.). In this example, the API gateway 862 is a common interface for performing transactions (e.g., calls, queries, etc.) on a blockchain by connecting one or more entities 852 and 856 to a blockchain peer (e.g., server 854). Here, the server 554 is a blockchain network peer component that stores a copy of the world state and the distributed ledger, thereby allowing clients 552 and 556 to query data regarding the world state and submit transactions into the blockchain network, where, depending on the smart contract 830 and the permission terms, authorized transactions will run the smart contract 830.

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

[0147] The illustrative storage medium can be coupled to the processor such that the processor can read information from and write information to the storage medium. In an alternative, the storage medium can be integral with the processor. The processor and the storage medium can reside in an application specific integrated circuit (“ASIC”). In an alternative, the processor and the storage medium can reside as separate components.

[0148] Figure 9A illustrates a process 900 by which a new block is added to a distributed ledger 920 (e.g., when a new smart contract is generated) in accordance with an embodiment of the present disclosure, and Figure 9B illustrates the content of a new data block structure 930 for a blockchain in accordance with an embodiment of the present disclosure. The new data block 930 can include document link data.

[0149] Reference Figure 9A, a client (not shown) may submit transactions to blockchain nodes 911, 912, and / or 913. The client can receive instructions from any source to formulate activities on blockchain 922. As an example, the client can be an application that acts on behalf of a requester (such as a device, person, or entity) to propose a transaction to the blockchain. Multiple blockchain peers (e.g., blockchain nodes 911, 912, and / or 913) can maintain the state of the blockchain network and a copy of the distributed ledger 920. Different types of blockchain nodes / peers can exist in the blockchain network, including: nodes that simulate and authorize transactions proposed by the client; recommendation nodes that utilize natural language processing techniques and recommend entities to be automatically contracted with the user; and committing peers that verify transactions and submit the transactions to the distributed ledger 920. In this example, blockchain nodes 911, 912, and / or 913 can perform the role of endorser nodes, submitter nodes, recommender nodes, or all three of these nodes.

[0150] The distributed ledger 920 includes a blockchain 922 that stores immutable sequenced records in blocks and a state database 924 (current world state) that maintains the current state of the blockchain 922. There can be one distributed ledger 920 per channel, and each peer maintains its own copy of the distributed ledger 920 for each channel of which they are a member. The blockchain 922 is a transaction log that is structured as a hash-linked list of blocks, where each block contains a sequence of N transactions. A block can include various components such as Figure 9B shown in. The link of the blocks (shown by the arrows in Figure 9A ) can be generated by adding the hash of the previous block's header within the block header of the current block. In this way, all transactions on the blockchain 922 are sorted and cryptographically linked together, thus preventing the tampering of blockchain data without breaking the hash link. Additionally, due to the link, the latest block in the blockchain 922 represents every transaction that occurred 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 the distributed ledger 920 can be stored in the state database 924. Here, the current state data represents the latest values of all keys that were ever included in the chain transaction log of the blockchain 922. Chaincode invocations execute transactions against the current state in the state database 924. To make these chaincode interactions extremely efficient, the latest values of all keys are stored in the state database 924. The state database 924 can include an indexed view into the transaction log of the blockchain 922, and thus the indexed view can be regenerated from the chain at any time. Before a transaction is accepted, after the peer starts up, the state database 924 can be automatically restored (or generated if needed).

[0152] The node receives transactions from the client and authorizes the transactions based on the simulation results. The node holds the smart contract for the simulated transaction proposal. When the node verifies the digital asset ownership, the node creates a transaction endorsement, which is a signed response indicating the verification of the digital asset ownership from the node to the client application. The method for verifying the digital asset ownership depends on one or more of the liveness hash, one-time number, private key, and public key pair that can be specified within the chain code. Different channels can have different permission terms. The authorized transactions are forwarded by the client application to the ordering service 910.

[0153] The ordering service 910 accepts the authorized transactions, sorts them into blocks, and delivers the blocks to the committing peers. For example, when a transaction threshold, timer timeout, or another condition has been reached, the ordering service 910 can initiate a new block. In Figure 9A the example, the blockchain node 912 is a committing peer that has received the new data block 930 for storage on the blockchain 920. The first block in the blockchain can be referred to as the genesis block, which includes information about the blockchain, its members, the data stored therein, etc.

[0154] The ordering service 910 can include an orderer cluster. The ordering service 910 does not process transactions, smart contracts, or maintain a shared ledger. Instead, the ordering service 910 can accept the authorized transactions and specify the order in which these transactions are submitted to the distributed ledger 920. The architecture of the blockchain network can be designed such that the specific implementation of 'ordering' becomes a pluggable component.

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

[0156] When the ordering service 910 initializes a new data block 930, the new data block 930 can be broadcast to the committing peers (e.g., blockchain nodes 911, 912, and 913). When a transaction is authorized, the transaction 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 a transaction fails, i.e., if the committing peer discovers that the read-write set does not match the current world state in the state database 924, the transaction sorted into the block will still be included in the block, but the transaction will be marked as invalid, and the state database 924 will not be updated.

[0157] Refer to Figure 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 Figure 9B the various depicted blocks and their contents shown in Figure 9B (such as the new data block 930 and its contents) are merely examples and are not meant to limit the scope of the example embodiments. The new data block 930 may store transaction information for N transactions (e.g., 1, 10, 100, 500, 1000, 2000, 3000, etc.) within the block data 950. The new data block 930 may also include a link to the previous block (e.g., on the blockchain 922 in Figure 9A ) within the block header 940. Specifically, the block header 940 may include the hash of the header of the previous block. The block header 940 may also include a unique block number, the hash of the block data 950 of the new data block 930, etc. The block number of the new data block 930 may be unique and assigned in a different order, such as incrementally / sequentially sorted starting from zero.

[0158] The block data 950 may store transaction information for each transaction recorded within the new data block 930. For example, the transaction data may include transaction type, version, timestamp, channel ID of the distributed ledger 920, transaction ID, epoch, payload visibility, chaincode path (deploy tx), chaincode name, chaincode version, input (chaincode and function), client (creator) identification such as public key and certificate, signature of the client, signature of the endorser, identification of the endorser, proposal hash, chaincode event, response status, namespace, read set (list of keys and versions read by the transaction, etc.), write set (list of keys and values, etc.), start key, end key, key list, Merkel tree query summary, etc. Transaction data may be stored for each of the N transactions.

[0159] In some embodiments, the block data 950 may also store new data 962 that adds additional information to the hash-linked blockchain in the blockchain 922. The additional information includes one or more of the steps, features, processes, and / or actions described or depicted herein. Thus, the new data 962 may be stored in the immutable log of the blocks on the distributed ledger 920. Some of the benefits of storing this new data 962 are reflected in the various embodiments disclosed and depicted herein. Although in Figure 9B , the new data 962 is depicted in the data block 950, it may also be located in the block header 940 or the block metadata 690. The new data 962 may include a document composite key used to link documents within an organization.

[0160] The block metadata 960 can store multiple fields of metadata (e.g., as a byte array, etc.). The metadata fields can include a signature regarding block creation, a reference to the last configuration block, a transaction filter that identifies valid and invalid transactions within the block, the last offset retained by the ordering service that sorts the block, etc. The signature, the last configuration block, and the sorted metadata can be added by the ordering service 910. Meanwhile, the submitter of the block (such as the blockchain node 912) can add validity / invalidity information based on endorsement policies, verification of read / write sets, etc. The transaction filter can include a byte array whose size is equal to the number of transactions in the data block 950 and a verification code that identifies whether a transaction is valid / invalid.

[0161] Figure 9C An embodiment of a blockchain 970 for digital content according to embodiments described herein is shown. The digital content can include one or more files and associated information. The files can contain media, images, videos, audio, text, links, graphics, animations, web pages, documents, or other forms of digital content. The immutable, append - only aspect of the blockchain serves as a safeguard to protect the integrity, validity, and authenticity of the digital content, thereby making the digital content suitable for use in legal proceedings (where admissibility rules apply) or other settings where the presentation and use of evidence or digital information are otherwise of interest. In such cases, the digital content can be referred to as digital evidence.

[0162] The blockchain can be formed in various ways. In one embodiment, the digital content can be included within the blockchain itself and can be accessed from the blockchain itself. For example, each block of the blockchain can store the hash value of reference information (e.g., header, value, etc.) along with the associated digital content. Then, the hash value and the associated digital content can 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 for referring to the previous block. This can be illustrated as follows:

[0163]

[0164]

[0165] In one embodiment, 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 digital content. The digital content may be stored in another storage area or memory address associated 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. By obtaining or querying the hash value of the block of interest and then looking up the value stored correspondingly to the actual digital content in the storage area, the digital content of each block can be referenced or accessed. This operation may be performed, for example, by a database gatekeeper. This can be illustrated as follows:

[0166]

[0167] In Figure 9C an example embodiment of, the blockchain 970 includes a plurality of blocks 9781, 9782, …, 978 N , where N≥1. The encryption used to link the blocks 9781, 9782, …, 978 N can be any of a plurality of keyed or unkeyed hash functions. In one embodiment, the blocks 9781, 9782, …, 978 N are subjected to a hash function that produces an n-bit alphanumeric output from an input based on the information in the block (where n is 256 or another number). Examples of such hash functions include, but are not limited to, SHA-type (SHA stands for Secure Hash Algorithm) algorithms, Merkle-Damgard algorithms, HAIFA algorithms, Merkle-tree algorithms, algorithms based on one-time numbers, and collision-resistant PRF algorithms. In another embodiment, the blocks 9781, 9782, …, 978 N may be encryptedly linked by a function different from the hash function. For purposes of illustration, the following description refers to a hash function (e.g., SHA-2).

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

[0169] The first block 9781 in the 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 in fact for all subsequent blocks can vary. For example, all the information in the first block 9781 can be hashed together and hashed once, or each or a portion of the information in the first block 9781 can be hashed separately, and then the hashes of the separately hashed portions can be executed.

[0170] The header 9721 can include one or more initial parameters, which can include, for example, a version number, a timestamp, a nonce, root information, a difficulty level, a consensus protocol, a duration, a media format, a source, descriptive keywords, and / or other information associated with the original file 9741 and / or the blockchain. The header 9721 can be generated automatically (e.g., by blockchain network management software) or manually by a blockchain participant. Different from the headers in other blocks 9782 to 978 in the blockchain, the header 9721 in the genesis block does not reference a previous block, simply because there is no previous block. N In the blockchain, the header 9721 in the genesis block does not reference a previous block, simply because there is no previous block.

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

[0172] The value 9761 in the genesis block is an initial value generated based on one or more unique attributes of the original file 9741. In one embodiment, the one or more unique attributes can include the hash value of the original file 9741, the metadata of the original file 9741, and other information associated with the file. In one embodiment, the initial value 9761 can be based on the following unique attributes: 1) the hash value of the original file calculated by SHA-2; 2) the originating device ID; 3) the start timestamp of the original file; 4) the initial storage location of the original file; and 5) the blockchain network member ID used for the software to currently control the original file and the associated metadata.

[0173] Other blocks 9782 to 978 in the blockchain N also have a header, a file, and a value. However, different from the first block 9721, the headers 9722 to 972 in other blocks NEach of them includes the hash value of the immediately preceding block. The hash value of the immediately preceding block can be only the hash of the header of the previous block or can be the hash value of the entire previous block. By including the hash value of the previous block in each of the remaining blocks, a traceback from the Nth block back to the origin block (and the associated original file) can be performed on a block-by-block basis, as indicated by arrow 980, to establish an auditable and immutable chain of custody.

[0174] The headers 9722 to 972 in the other blocks N Each of them may also include other information, such as, for example, version number, timestamp, nonce, root information, difficulty level, consensus protocol, and / or other parameters or information generally associated with the corresponding file and / or blockchain.

[0175] The files 9742 to 974 in the other blocks N May be equal to the original file or may be a modified version of the original file in the origin block, depending on, for example, the type of processing performed. The type of processing performed may vary from block to block. The processing may involve, for example, any modification of the files in the previous block, such as editing information or otherwise changing the content of the files, removing information from these files, or adding or appending information to these files.

[0176] Additionally or alternatively, the processing may involve just copying the files from the previous block, changing the storage location of the files, analyzing the files from one or more previous blocks, moving the files from one storage or memory location to another, or performing actions with respect to the files of the blockchain and / or its associated metadata. Processing involving analyzing the files may include, for example, appending, including various analyses, statistics, or other information associated with the file, or otherwise associating various analyses, statistics, or other information associated with the file.

[0177] The other blocks 9762 to 976 in the other blocks N The values in each of them are unique values and are all different as a result of the processing performed. For example, the value in any one block corresponds to an updated version of the value in the previous block. This update is reflected in the hash of the block being assigned. The value of the block thus provides an indication of what processing has been performed in the block and also allows for a traceback through the blockchain to the original file. This traceback confirms the chain of custody of the file throughout the blockchain.

[0178] For example, consider a case where multiple portions of a file in a previous block are edited, blocked, or pixelated to protect the identity of a person shown in the file. In such a case, the block including the edited file will include metadata associated with the edited file, such as how the edit was performed, who performed the edit, a timestamp when the edit occurred, etc. The metadata can be hashed to form a value. Since the metadata of the block is different from the information that was hashed to form the value in the previous block, these values are different from each other and can be recovered upon decryption.

[0179] In one embodiment, when any one or more of the following occur, the value of the previous block (e.g., a new hash value is calculated) can be updated to form the value of the current block. In this example embodiment, the new hash value can be calculated by hashing all or a portion of the information pointed out below.

[0180] a) If the file has been processed in any way (e.g., if the file was edited, copied, changed, accessed, or some other action was taken), the newly SHA-2 calculated hash value

[0181] b) The new storage location of the file

[0182] c) The newly identified metadata associated with the file

[0183] d) Transfer of access or control of the file from one blockchain participant to another

[0184] Figure 9D Illustrates an embodiment of a block that can represent the block structure in blockchain 990 according to one embodiment. The block (i.e., block i ) includes a header 972 i , a file 974 i and a value 976 i .

[0185] The header 972 i includes the hash value of the previous block, i.e., block i-1 , and additional reference information, which can be, for example, any type of information discussed herein (e.g., header information including references, characteristics, parameters, etc.). All blocks reference the hash of the previous block, except for the origin block. The hash value of the previous block can be the hash of just the header in the previous block or the hash of all or a portion of the information in the previous block (including the file and metadata).

[0186] The file 974 iIncludes multiple data, such as data 1, data 2, …, data N in sequence. The data is tagged with metadata 1, metadata 2, …, metadata N that describes the content and / or characteristics associated with the data. For example, the metadata for each data can include information such as a timestamp for indicating the data, processing data, keywords for indicating the person or other content depicted in the data, and / or other features that can help establish the validity and content of the document as a whole (especially its use as digital evidence), as described, for example, in the embodiments discussed below. In addition to the metadata, each data can be tagged with references 1, references 2, …, references to the previous data N To prevent tampering, gaps in the document, and sequential references through the document.

[0187] Once the metadata is assigned to the data (e.g., via a smart contract), the metadata cannot be changed without a hash change (which can be easily identified for invalidation). Thus, the metadata creates a data log of information that can be accessed for use by participants in the blockchain.

[0188] Value 976 i Is a hash value or other value calculated based on any type of information discussed previously. For example, for any given block i , the value of the block can be updated to reflect the processing performed on the block, e.g., a new hash value, a new storage location, new metadata for the associated file, transfer of control or access, an identifier, or other actions or information to be added. Although the value in each block is shown as separate from the metadata and header of the file's data, in another embodiment, the value can be partially or wholly based on this metadata.

[0189] Once the blockchain 990 is formed, at any point in time, an immutable chain of custody for the document can be obtained by querying the blockchain to obtain the transaction history of the values across the blocks. The query or tracing process can start by decrypting the value of the most recently included block (e.g., the last (Nth) block), and then continue decrypting the values of other blocks until the origin block is reached and the original document is restored. Decryption can also include decrypting the header and file and associated metadata at each block.

[0190] Decryption is performed based on the type of encryption that occurs in each block. This can involve using a private key, a public key, or a public-private key pair. For example, when using asymmetric encryption, a blockchain participant or processor in the network can generate a public-private key pair using a predetermined algorithm. The public key and the private key are related to each other by a certain mathematical relationship. The public key can be publicly distributed to be used as an address for receiving messages from other users, such as an IP address or a 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 use the sender's public key to verify. In this way, the recipient can be confident that only the sender could have sent the message.

[0191] Generating a key pair can be similar to creating an account on a blockchain, but does not have to be actually registered anywhere. Additionally, each transaction executed on the blockchain is digitally signed by the sender using their private key. This signature ensures that only the owner of the account can track and process (if within the scope of permission determined by a smart contract) the files on the blockchain.

Claims

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

2. The computer-implemented method according to claim 1, wherein, Sending the public key for encrypting the digital asset further includes: generating a public key / private key pair, wherein the public key in the public key / private key pair is used to encrypt the digital asset, and the private key in the public key / private key pair is used to decrypt the encrypted digital asset.

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

4. The computer-implemented method according to claim 1, wherein, Determining whether the first liveness hash is valid includes: Transforming, by the one or more processors, the encrypted digital asset back to an unencrypted digital asset using a private key associated with the digital asset; Generating, by the one or more processors, a second liveness hash based on the unencrypted digital asset and the first one-time number; and Matching, by the one or more processors, the first liveness hash with the second liveness hash.

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

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

7. The computer-implemented method according to claim 6, further comprising: Verifying, by the one or more processors, the proof of ownership of the digital asset based at least in part on the following operations: The encrypted digital asset is obtained from the digital asset record by the one or more processors using the image id; The encrypted digital asset is transformed back to an unencrypted digital asset by the one or more processors using the private key associated with the digital asset; A fourth liveness hash is generated by the one or more processors based on the unencrypted digital asset and the second one-time number; and The first liveness hash is matched with the second liveness hash by the one or more processors.

8. The computer-implemented method according to claim 4, further comprising: The one or more processors send authentication valid for the owner of the digital asset to the requesting entity in response to verifying the proof of ownership of the digital asset.

9. The computer-implemented method according to claim 1, further comprising: The one or more processors use a smart contract executed in a trusted execution environment in a blockchain ledger to determine consensus on the first liveness hash.

10. The computer-implemented method according to claim 1, further comprising: The one or more processors access a smart contract associated with the digital asset to verify that the first liveness hash matches the hash of the digital asset and the first one-time number.

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

12. The computer-implemented method according to claim 5, further comprising: Sending information on true ownership from the smart contract TEE to the smart contract.

13. The computer-implemented method according to claim 9, further comprising: Sending information on true ownership from the smart contract to the registry.

14. A computer program product for verifying ownership of a digital asset, the computer program product comprising one or more computer-readable storage media and program instructions stored on the one or more computer-readable storage media, the program instructions comprising instructions for: 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, wherein the digital asset is encrypted using the public key and the first liveness hash is generated at least in part based on the digital asset in unencrypted form and a first one-time number; Determining whether the first liveness hash is valid in response to receiving the first one-time number and the first liveness hash from the encrypted digital asset from the owner of the digital asset; and Generating a digital asset record in response to determining that the first liveness hash is valid, wherein the digital asset record comprises the encrypted digital asset and the first liveness hash.

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

16. The computer program product according to claim 14, further comprising instructions for the following operations: Storing the digital asset record in at least one of a storage service external to a distributed ledger or blockchain environment.

17. The computer program product according to claim 14, wherein, The instructions for determining whether the first activity hash is valid include instructions for the following operations: Using a private key associated with the digital asset to transform the encrypted digital asset back to an unencrypted digital asset; Generating a second activity hash based on the unencrypted digital asset and the first one-time digital; And Matching the first activity hash with the second activity hash.

18. The computer program product according to claim 14, further comprising instructions for the following operations: Receive, from the requesting entity, a request for the owner of the digital asset to provide proof of ownership of the digital asset, wherein, The request includes a second one-time digital; and In response to receiving the request for the owner of the digital asset to provide proof of ownership of the digital asset: Sending the second one-time digital to the owner of the digital asset.

19. The computer program product according to claim 14, further comprising instructions for the following operations: Receive, from the owner of the digital asset, an image id and a third activity hash associated with a digital image, wherein, The second activity hash is generated at least in part based on the digital asset in unencrypted form and the second one-time digital.

20. A computer system for verifying 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 media for execution by the one or more computer processors; and The computer program instructions include instructions for the following operations: 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 from the owner of the digital asset an encrypted digital asset and a first activity hash, wherein the digital asset is encrypted using the public key, and the first activity hash is generated at least in part based on the digital asset in unencrypted form and a first one-time digital; In response to receiving the first one-time digital and the first activity hash from the encrypted digital asset from the owner of the digital asset, determining whether the first activity hash is valid; and In response to determining that the first activity hash is valid, generating a digital asset record, wherein the digital asset record includes the encrypted digital asset and the first activity hash.

21. A computer-implemented method for verifying ownership of a digital asset, the computer-implemented method comprising: Receiving, by one or more processors, from a requesting entity a request for the owner of a digital asset to provide proof of ownership of the digital asset, wherein the request includes a first one-time digital; and In response to receiving the request for the owner of the digital asset to provide proof of ownership of the digital asset: Sending, by the one or more processors, the first one-time digital to the owner of the digital asset; Receiving, by the one or more processors, from the owner of the digital asset, an image id associated with a digital image and a first activity hash; and Verifying, by the one or more processors, a proof of ownership of the digital asset.

22. The computer-implemented method according to claim 21, wherein, The first activity hash is generated at least in part based on the digital asset in unencrypted form and the first one-time number.

23. The computer-implemented method according to claim 21, wherein, Verifying, by the one or more processors, the proof of ownership of the digital asset is at least in part based on: Obtaining, by the one or more processors, the encrypted digital asset from the digital asset record using the image id; Transforming, by the one or more processors, the encrypted digital asset back to an unencrypted digital asset using the private key associated with the digital asset; Generating, by the one or more processors, a second activity hash based on the unencrypted digital asset and a second one-time number; And Matching, by the one or more processors, the first activity hash with the second activity hash.

24. The computer-implemented method according to claim 21, further comprising: Sending, by the one or more processors, in response to verifying the proof of ownership of the digital asset, authentication valid for the owner of the digital asset to the requesting entity.

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

Images