Method of providing one of plurality of files having different file formats and each representing same digital asset

Abstract

A method of providing, from a transmitting entity (2) to a receiving entity (51), a file (41) of a plurality of files (4) of different file formats representing the same digital asset (3) comprises: transmitting the file (41) and a proof of ownership (91) from the transmitting entity (2) to the receiving entity (51); and the transmitting entity (2) using the proof of ownership (91-93) and an irreplaceable token (8) to identify to the receiving entity (51) that itself is the owner of the digital asset (3), the irreplaceable token (8) being bound to: a cryptographic root hash (81) of a Merkel tree (9) formed based on cryptographic hashes of the plurality of files (4); and a perceptual hash (82) calculated using at least one of the files (4). The proof of ownership (91) comprises at least a portion of the Merkel tree (9) sufficient for calculating a cryptographic root hash (81) based on a cryptographic hash of the transferred file (41).

Description

[0001] A method is provided that provides multiple files with different file formats, each representing one of the same digital asset.

[0002] This invention relates to the field of Industry 4.0, in which different entities with limited mutual trust cooperate in industrial control and communication systems, and more particularly, to a computer-implemented method for providing one of a plurality of files with different file formats, each representing the same digital asset, from a transmitting entity to a receiving entity, and to a corresponding computer program product, manufacturing equipment, and communication system.

[0003] A non-fungible token is a cryptographically unique, indivisible, non-fungible, and verifiable token representing a digital asset in a distributed transaction database (such as the Ethereum blockchain). Non-fungible tokens can be used as proof of rights to the digital asset they represent. These rights can include ownership, licensee status, etc. The conditions for transferring non-fungible tokens and the rights thereby authenticated between entities are managed by automated smart contracts stored as transactions in the distributed transaction database and tracking ownership of the non-fungible tokens. Furthermore, non-fungible tokens represent digital assets (bound to digital assets) through a cryptographic hash of the digital file representing the digital asset. Therefore, non-fungible tokens can also be used to verify the integrity of the digital file representing the digital asset, as well as to detect forgeries of digital files purported to represent digital assets.

[0004] In industrial contexts, non-fungible tokens can be used as digital twins, representing physical or digital entities such as IoT devices, technical designs or models, and manufacturing specifications. These are exchanged, delivered, and transported in an automated and trusted manner among different parties in the industrial ecosystem, where limited trust exists between them. In this paper, non-fungible tokens can also be used for integrity verification, forgery detection, and proof of ownership.

[0005] However, in an industrial context, one can imagine a scenario where digital assets, such as CAD designs, exist in multiple different file formats, including several different vector-based formats (such as DWG and DXF) and several different pixel-based formats (such as PNG and JPG), each potentially rendered at several different pixel resolutions, and each of these formats represents the same digital asset. Different entities in the ecosystem may require correspondingly different file format representations of the same digital asset for their operations.

[0006] If a corresponding non-fungible token is created for each of the various file format representations, there will no longer be a single proof of ownership of the digital asset, but rather multiple competing proofs of ownership.

[0007] Imagine bundling multiple files with various file formats into a folder such as a ZIP folder, and creating a single, non-fungible token for the entire folder. However, in this scenario, a party wishing to perform any kind of verification using the non-fungible token would need access to the entire folder's contents—that is, access to all files across the multiple folders—in order to calculate their cryptographic hashes. Verification at the level of individual files with different file formats but representing the same digital asset is impossible.

[0008] One object of the present invention is to improve the security and trust provision of digital assets by using non-fungible tokens when digital assets are represented by multiple files with different file formats.

[0009] According to a first aspect, a computer-implemented method for providing one of a plurality of files, each having a different file format and representing the same digital asset, from a transmitting entity to a receiving entity includes: a) transmitting the one file from the transmitting entity to the receiving entity; b) transmitting a proof of ownership of the transmitted file from the transmitting entity to the receiving entity; and c) the transmitting entity identifying itself as the owner of the digital asset represented by the transmitted file to the receiving entity using the transmitted proof of ownership and a non-fungible token stored in a distributed transaction database and representing the digital asset. In this document, the non-fungible token is bound to: a root hash of a Merkle tree formed based on the cryptographic hashes of each of the plurality of files; and a perceptual hash calculated using at least one of the plurality of files. In this document, the proof of ownership includes at least a portion of the Merkle tree sufficient to calculate the root hash based on the cryptographic hashes of the transmitted files.

[0010] The proposed method proposes a specific structure for a non-fungible token that, together with the proposed proof of ownership, advantageously enables ownership verification, integrity verification, and forgery detection of digital assets represented by the multiple files when only one of a plurality of files with different file formats is transmitted from the transmitting entity to the receiving entity.

[0011] In this paper, the amount of data that needs to be stored in the distributed transaction database can be kept to a minimum. That is, the amount of data can consist only of the cryptographic root hash and the perceptual hash. Furthermore, due to the cryptographic root hash based on a Merkle tree formed by the cryptographic hashes of multiple files, the non-fungible token can be used to verify the integrity of any one of the multiple files individually, without requiring access to all of the multiple files, but only based on a sparse proof of ownership that requires only certain parts of the Merkle tree. Furthermore, even if the cryptographic hashes of individual files are not bound to the non-fungible token, forgery detection (i.e., detecting duplicate non-fungible tokens referring to the same digital asset) is possible at every stage due to the perceptual hash. Moreover, the perceptual hash can advantageously provide superior forgery detection performance.

[0012] In particular, distributed transactional databases can maintain a cryptographically secure ledger of transactional data. For example, a cryptographically secure ledger can be a series of blocks, where each block includes multiple transactions, cryptographic proofs (such as proof-of-work or proof-of-stake), and the cryptographic hash value of the previous block. Thus, subsequent modifications to the ledger may become impossible or extremely expensive in terms of the required computational power.

[0013] Furthermore, a distributed transactional database can be represented by multiple node devices interconnected via a network. Different node devices can be operated by different industry parties with limited trust in each other. Each node device can store a complete copy of the ledger. A consensus scheme can be used to manage the addition of new transactions to the ledger while ensuring the integrity of the ledger, thereby keeping the different copies of the ledger stored on different node devices consistent with each other. The consensus scheme can be designed so that consistent behavior by each node device is rewarded, while inconsistent behavior by individual node devices is penalized and / or makes such inconsistent behavior impossible. Proof-of-Work and Proof-of-Stake are two well-known consensus schemes that ensure no individual party can manipulate the cryptographically secure ledger without colluding with at least 50% of the computing power and / or the staked value invested in the distributed transactional database.

[0014] Therefore, distributed transaction databases can also be called blockchains.

[0015] The term "entity" can refer to any entity capable of performing transactions using a distributed transactional database. Examples of transactions include minting non-fungible tokens; transferring ownership of non-fungible tokens to different entities; and so on.

[0016] The corresponding entity may own, include, or have access to wallets used in conjunction with the distributed transaction database. In this document, a wallet may include a unique identifier (wallet address) and a public-private key pair, which can be used to prove ownership of the wallet and to unlock it for transaction execution.

[0017] The corresponding entity may include a node device of the distributed transaction database (which may be a "full node"). Alternatively, the corresponding entity may only include a public-private key pair of a wallet (which may be a "lightweight node"). Still alternatively, an external device may be provided, which is a full or lightweight node device of the distributed transaction database. In this document, the corresponding entity may use authenticated API calls or similar to the external device to access and execute transactions in the distributed transaction database.

[0018] In particular, the transmitting entity and the receiving entity can be entities of an industrial control system.

[0019] More specifically, the corresponding "entity" can be a unit, such as the structural or functional unit of the corresponding industrial control device in an industrial control system.

[0020] The corresponding entity can operate autonomously in a fully automated manner according to a predetermined procedure, or it can operate in an automated manner in response to operations performed on the corresponding entity by a human operator.

[0021] The entity can be implemented in hardware and / or software. If the entity is implemented in hardware, it can be embodied as a device, such as part of a computer or processor or system (e.g., a computer system). If the entity is implemented in software, it can be embodied as a computer program product, function, routine, program code, or executable object.

[0022] Digital assets can be any asset used for technical purposes within an industrial control system. Examples of digital assets include manufacturing specifications, automation schemes, CAD drawings, product images, acoustic sampling results, and more. On a computer, digital assets can be represented by one or more digital files.

[0023] In this document, the term "digital asset" can refer to the licensed and ownable meaningful content of a digital asset. That is, a "digital asset" can be described as a set of identifiable characteristics, such as technical, visual, or auditory features that distinguish the content of a digital asset. In this document, this set of distinguishing features is reproduced when a file representing a digital asset is presented (e.g., displayed, played back, or fed to a manufacturing facility or similar for automated manufacturing). More precisely, the same or highly similar distinguishing features will be reproduced regardless of which of several files with different file formats representing the same digital asset is presented.

[0024] In this article, specifically, the “hash” (hash value) of a file is a fixed-length value calculated by applying a hashing algorithm to the file, where the file contains data of arbitrary length.

[0025] More specifically, a "cryptographic hash" is a hash value calculated by applying a cryptographic hashing algorithm that relies on the avalanche effect, thus ensuring that even small changes in the input data will result in very different hash values. Examples of cryptographic hashing algorithms include MD-5 and SHA.

[0026] Conversely, a "perceptual hash" is a hash value that is robust to changes in the input data, provided that the characteristics produced by the input data (file) remain essentially the same. pHash is an example of a perceptual hash algorithm that can be applied to multimedia files.

[0027] Specifically, "non-fungible tokens" can be tokens managed, contained in, or stored in smart contracts, which are specially programmed smart transactions stored in a distributed transaction database.

[0028] More specifically, for example, a non-fungible token could be a token based on one of the Ethereum standards ERC-721 and ERC-1155, however, with modifications as described in this paper (i.e., bound to a Merkle tree cryptographic root hash and a perceptual hash, rather than a file cryptographic hash).

[0029] Non-fungible tokens can be used for integrity verification and / or forgery detection and / or proof of rights to any document that represents or is alleged to represent, or conversely does not represent or is alleged to represent, a digital asset represented by non-fungible tokens.

[0030] Specifically, non-fungible tokens represent digital assets by being bound to a cryptographic root hash and a perceptual hash. In this document, "bound to" can mean one of the following: a non-fungible token may include both a cryptographic root hash and a perceptual hash. That is, the cryptographic root hash and the perceptual hash can be the payload data of the non-fungible token. Alternatively, a non-fungible token may include a link to a metadata file that includes both the cryptographic root hash and the perceptual hash. The metadata file can be stored on any device outside of a distributed transactional database. In this case, the link alone may be the payload data of the non-fungible token, or the payload data of the non-fungible token may include the link and the cryptographic hash of the metadata file.

[0031] The term "the owner of the digital asset" means that the transfer entity has the right to use the digital asset for at least a certain purpose; and may also mean that the transfer entity has access to each of the multiple files representing the digital asset.

[0032] It is important to note that a detailed description of the rights of the transfer entity may be specified in the non-fungible token and / or may be implemented by a smart contract providing the non-fungible token. Furthermore, the non-fungible token may include the transfer entity's wallet address, thereby designating the transfer entity as its owner. The transfer entity may possess a private key capable of unlocking the wallet to prove its ownership and / or to facilitate transactions using the non-fungible token.

[0033] Step a) of transferring a file from a transmitting entity to a receiving entity can be broadly defined as any action that results in the receiving entity gaining at least access to the file. For example, the transmitting entity may transfer the file to the receiving entity via a wired or wireless network. Alternatively, the transmitting entity may transmit a link to an address from which the file can be obtained to the receiving entity via a wired or wireless network. Optionally, in this case, the transmitting entity may also transmit authentication information required to access the file to the receiving entity via the link. As yet another alternative, the link and optional authentication information may be included in a non-fungible token. In this case, the transmitting entity may simply transmit the identifier of the non-fungible token to the receiving entity, and the receiving entity may then obtain the link and optional authentication information from the non-fungible token, and may optionally use the link and optional authentication information to retrieve the file.

[0034] Similarly, step b) of transferring the proof of ownership from the transmitting entity to the receiving entity can be broadly referred to as any action that results in the receiving entity gaining at least access to the proof of ownership, such as transmission via wired or wireless networks.

[0035] Specifically, step c) whereby the transmitting entity identifies itself as the owner of the digital asset to the receiving entity can provide one or more of the following: authentication of the transmitting entity based on ownership of the non-fungible token; integrity verification of the transmitted file based on the cryptographic root hash; and forgery detection of the copied non-fungible token based on the perceptual hash.

[0036] Specifically, a Merkle tree can be a hash tree where each "leaf" or "bottom" node (each node at the lowest level) includes a cryptographic hash of one of the files, and each node that is not a leaf node (each node at a higher level) includes a cryptographic hash of the cryptographic hashes of its children. In this paper, when leaf nodes are assumed to be bottom nodes—that is, when child nodes are assumed to be positioned below their parent nodes—the single topmost node is called the root node, and this node includes the cryptographic hashes of its children, which is the root cryptographic hash.

[0037] As an example only, "the portion of the Merkle tree sufficient to compute the root hash based on the cryptographic hash of the transmitted file" may include the root hashes of all other files that have not yet been transmitted from the plurality of files. However, other options for the portion of the Merkle tree are also conceivable, as will be discussed with regard to specific embodiments.

[0038] In this way, the receiving entity can advantageously perform integrity verification on the transmitted file by calculating the cryptographic hash value of the transmitted file; recalculate the cryptographic root hash value using the cryptographic hash value of the transmitted file and a portion of the Merkle root tree included in the proof of ownership; and compare the recalculated cryptographic root hash with the cryptographic root hash of the token that is bound to the non-fungible token.

[0039] In other words, since a sufficient portion of the Merkle tree is included in the transmitted proof of ownership, the receiving entity can perform integrity verification on the received file, even if the non-fungible token does not specify the individual cryptographic hash of the received file, but only the cryptographic root hash of the Merkle tree.

[0040] It is important to note in this article that it may be computationally very difficult or impossible for a malicious third party that does not have access to multiple files to forge a proof of ownership (i.e., guess the hash of the Merkle tree to produce the correct cryptographic root hash).

[0041] Unlike cryptographic hashes, perceptual hashes are hashes that are expected to be identical or similar, regardless of which of multiple files they are calculated from. Therefore, perceptual hashes can be calculated using any one or more of the multiple files.

[0042] Perceptual hashes can be advantageously used for forgery detection, specifically for detecting non-fungible tokens that represent copies of the same digital asset. Whether forgery detection is performed as part of the method (such as step c) is not important. Even if forgery detection is only performed at a later time, such as periodically during the maintenance of a distributed transaction database or similar, the presence of a perceptual hash in the non-fungible token increases the level of trust in the non-fungible token.

[0043] It should be noted that steps a) to c) do not necessarily need to be performed in this order, and may also be performed in the reverse or any other order and / or simultaneously, depending on other details of the implementation.

[0044] According to a variation of the first aspect, proof of ownership also includes at least the identifier of the non-fungible token.

[0045] The identifier of a non-fungible token may include: the cryptographic address of the smart contract, which identifies the smart contract in the ledger of the distributed transaction database; and the token ID of the specific non-fungible token within the smart contract.

[0046] In this way, the receiving entity knows the non-fungible token to be used to perform step c).

[0047] However, this variant is optional; alternatively, for example, the receiving entity may search a distributed transaction database, for example, based on a perceptual hash of the transmitted file, and retrieve non-fungible tokens from the distributed transaction database for use in performing step c).

[0048] According to an embodiment, if the identification in step c) fails, the receiving entity rejects the received file.

[0049] When the identifier in step c) fails, the received file is untrusted. It may be compromised and / or the transmitting entity may not be authorized to provide the received file. Therefore, by rejecting the received file in the event of a failure identifier using a non-fungible token, the trust and security of the industrial control system, including both the transmitting and receiving entities, can be increased.

[0050] Rejecting a received file may include deleting the received file, forgetting or discarding links and / or authentication information that could be used to access the file, not using the received file for further processing, making the human operator aware of the received file and leaving the decision on how to handle it to the human operator, returning a message indicating rejection to the transmission entity, etc.

[0051] According to another embodiment, the perceptual hash is the average of the perceptual hashes of each of the multiple files.

[0052] Even if multiple files with different file formats represent the same digital asset, the differences in file formats can lead to differences in accuracy or similarities. The perceived hashes of different files may not be identical, but may only be similar. In this case, setting the perceived hash of the non-fungible token as an average can advantageously produce more accurate results during subsequent comparisons between the perceived hash of the non-fungible token and the perceived hash calculated based on the actual file during forgery detection and similarity testing.

[0053] According to another embodiment, step c) includes: the receiving entity confirming that the transmitting entity is the owner of the non-fungible token; the receiving entity confirming that the integrity of the transmitted file is one of a plurality of files representing digital assets represented by the non-fungible token; and if at least one of the confirmation steps fails, the identification in step c) fails.

[0054] The receiving entity can use the non-fungible token and the transmitted proof of ownership to verify the integrity of the transmitted file as one of several files represented by digital assets in the form of the non-fungible token by following these steps: calculating the cryptographic root hash of the received file; calculating the cryptographic root hash of the Merkle tree based on the cryptographic hash of the received file and the portion of the Merkle tree included in the transmitted proof of ownership; and comparing the calculated cryptographic root hash of the Merkle tree with the cryptographic root hash of the Merkle tree bound to the non-fungible token.

[0055] The receiving entity can verify that the transmitting entity is the owner of the non-fungible token by, for example, by verifying whether the transmitting entity can access the corresponding wallet, based on the wallet address specified by the non-fungible token.

[0056] According to another embodiment, step c) includes the receiving entity confirming the identity of the transmitting entity as the owner of the nonfungible token based on one of the following: the transmitting entity uses a transaction in a distributed transaction database to transfer ownership of the nonfungible token to the receiving entity; and the transmitting entity uses challenge-response authentication to prove its ownership of the nonfungible token to the receiving entity.

[0057] In the first scenario, the transmitting entity transfers its ownership or right to use the digital asset to the receiving entity, and the receiving entity becomes the new owner of the non-fungible token. In this case, the consensus mechanism of the distributed transaction database ensures that the transmitting entity originally owned the non-fungible token; otherwise, the transaction is not committed to the ledger of the distributed transaction database.

[0058] In the latter case, challenge-response authentication may include, for example, verifying that a private key held or accessible by the transport entity can unlock a wallet address, which is designated by a non-fungible token as the wallet address of the entity that owns it.

[0059] In either case, the cryptographic mechanisms built into the distributed transaction database and their non-fungible token functionality advantageously ensure that the identity of the transmitting entity can be verified by the receiving entity.

[0060] In other words, the advantage is that, using a single, non-fungible token, ownership rights and other rights can be enforced when transferring individual digital files among multiple digital files representing the same digital asset in an industrial control system or similar system.

[0061] According to another embodiment, as a sufficient part of the Merkle tree, the proof of ownership includes: for each level of the Merkle tree, a cryptographic hash of each sibling node corresponding to the node of the transmitted file on the corresponding level.

[0062] In this paper, the node in a Merkle tree that "corresponds to the transmitted file" is a node that has direct child nodes, grandchild nodes, or other descendant nodes that include the cryptographic hash of the transmitted file, and the sibling node of the node is a node that shares a common parent node with the node.

[0063] Therefore, it is possible not only to minimize the amount of data required to be stored so that it is bound to a non-fungible token, but also to minimize the amount of data required to be transferred as a sufficient part of the Merkle tree within the proof of ownership.

[0064] Given an exemplary Merkle tree comprising n levels, where the count of “n” includes levels containing leaves but excludes levels containing a single root hash, and where each parent node has two child nodes. This exemplary Merkle tree is capable of holding the hashes of 2**n files at its leaves, where “**” represents “power of 1”. If hashes of other files not transmitted are selected as a sufficient part of the Merkle tree, the proof of ownership will include (2*n)-1 hashes. However, if the hashes to be included in the proof of ownership are selected according to this embodiment, the proof of ownership only needs to include n hashes. This benefit becomes even more pronounced if the number of multiple files is large.

[0065] Furthermore, advantageously, according to this embodiment, most of the hashes of other files not transmitted in the multiple files (hashes at the leaf nodes of the Merkle tree) do not need to be disclosed to the recipient, thereby increasing data privacy and trust.

[0066] According to another embodiment, step c) further includes: the receiving entity calculating the perceptual hash of the file received in step a), and if the distributed transaction database contains more than one nonfungible token that is bound to a perceptual hash similar to the calculated perceptual hash of the received file, the receiving entity causes the identification in step c) to fail.

[0067] In other words, the perceptual hash bound to a non-fungible token advantageously enables forgery detection. The receiving entity can search a distributed transaction database for non-fungible tokens bound to similar perceptual hashes, and if two or more exist, one of them is highly likely to be forged; that is, an illegally minted non-fungible token represents an illegitimate digital asset, an illegitimate copy of a legitimate digital asset, and so on. The forgery detection functionality advantageously detects forgery even if the underlying file representing the corresponding digital asset exists in a different format and / or includes minor modifications that significantly alter the cryptographic hash but not the perceptual hash.

[0068] According to another embodiment, the method further includes: the receiving entity calculating a perceptual hash of the file received in step a), and if the distributed transaction database contains exactly one nonfungible token bound to the perceptual hash, which is similar to the calculated perceptual hash of the received file, the receiving entity using the exactly one nonfungible token for identification in step c).

[0069] In this way, it is advantageous that the owner transferring the token does not need to provide the receiving entity with an identifier of the non-fungible token for use in step c) as part of proof of ownership or the like. Instead, the receiving entity can determine the correct non-fungible token itself based on a comparison of two perceived hashes.

[0070] According to another embodiment, the method further includes a transport entity minting non-fungible tokens in a distributed transaction database, wherein the consensus scheme of the distributed transaction database accepts the minting of non-fungible tokens, provided that the distributed transaction database does not contain another non-fungible token bound to a perceptual hash similar to the perceptual hash of the non-fungible token to be minted.

[0071] In this document, "minting" non-fungible tokens may include performing transactions using a distributed transaction database, which enables the creation of non-fungible tokens and their association with a transfer entity as their initial owner. For example, during the "minting" process, a token ID conforming to an ERC-1155 smart contract may be assigned to the wallet address of the transfer entity's wallet. "Minting" may also include binding a cryptographic root hash and a perceptual hash to the most recently created token. Specifically, the "minting" step is performed when the transfer entity is the entity that has already created digital assets and / or multiple files representing digital assets, and the non-fungible tokens representing the digital assets have not yet been stored in the distributed transaction database.

[0072] Advantageously, in this paper, since non-fungible tokens and any other previously minted non-fungible tokens include corresponding perceptual hashes, forgery detection can be performed by comparing the perceptual hash of the non-fungible token to be minted with the perceptual hash of non-fungible tokens already minted in the distributed transaction database. Also, as discussed above, forgery can be detected even if the underlying file exists in a different format and / or includes minor modifications. Furthermore, since forgery detection is performed as part of the consensus scheme, it is advantageous not only to detect forged non-fungible tokens but also to prevent them from being included in the distributed transaction database from the outset. Therefore, the level of trust in the distributed transaction database is advantageously increased.

[0073] According to another embodiment, in order to determine one or more non-fungible tokens stored in a distributed transaction database and bound to similar perceptual hashes, a trusted perceptual hash database is queried, wherein the identifiers of the non-fungible tokens included in the distributed transaction database are stored in association with the corresponding perceptual hashes of the respective non-fungible tokens.

[0074] This embodiment is compatible with embodiments in which the consensus scheme performs forgery detection and prevention during minting, in which a trusted perceptual hash database is queried to obtain a perceptual hash similar to the perceptual hash of the non-fungible token to be minted; and is also compatible with embodiments in which the receiving entity performs forgery detection during step c), in which a trusted perceptual hash database is queried to obtain a perceptual hash similar to the calculated perceptual hash of the received file.

[0075] A trusted perceptual hash database can be an indexed database that uses perceptual hashes as its index. A trusted perceptual hash database can support similarity searches using wildcards, similarity metric thresholds, and other similarity methods.

[0076] By performing indexed queries on a trusted-aware hash database, identifiers of relevant non-fungible tokens can be retrieved quickly, without the time-consuming iteration through the ledger of a distributed transaction database. Therefore, operational performance can be improved.

[0077] A trusted-aware hash database can be a pre-defined database trusted by all entities. Alternatively, the trusted-aware hash database can be dynamically accessed via an API endpoint provided by a smart contract that manages the non-fungible token. As another alternative, each entity (such as the sending entity and the receiving entity) can include a node device of a distributed transaction database, and each entity can maintain its own trusted hash database.

[0078] According to another embodiment, when accepting the minting of non-fungible tokens, the distributed transaction database stores the identifier of the non-fungible token in association with the perceptual hash bound to the non-fungible token in a trusted perceptual hash database.

[0079] In other words, once a non-fungible token is minted, the corresponding record is stored in a Trusted Aware Hash Database. This ensures the Trusted Aware Hash Database is automatically kept up-to-date.

[0080] For example, the storage of records can be triggered by a consensus scheme of a distributed transactional database.

[0081] According to another embodiment, when the statistical similarity metric is below a predetermined threshold, a decision is made as to whether the perceptual hashes are similar.

[0082] In particular, statistical similarity measures are calculated between the perceptual hashes to be compared.

[0083] For example, statistical similarity measures can include Hamming distance, Levenshtein distance, etc.

[0084] Any embodiment of the first aspect may be combined with any embodiment of the first aspect to obtain another embodiment of the first aspect.

[0085] According to another aspect, the present invention relates to a computer program product comprising program code for performing the above-described method, for providing, when run on at least one computer, one of a plurality of files having different file formats and each representing the same digital asset from a transmitting entity to a receiving entity.

[0086] Computer program products, such as computer program components, can take the form of memory cards, USB sticks, CD-ROMs, DVDs, or files that can be downloaded from a server on a network. For example, such files can be provided by transmitting files containing computer program products from a wireless communication network.

[0087] In this paper, the corresponding parts of the program code can run on corresponding entities such as the transport entity, the receiving entity, and the computing node of a distributed transaction database.

[0088] According to another aspect, a manufacturing apparatus is provided, which is configured to receive a document representing a manufacturing specification of an article to be manufactured according to the method described above in accordance with any embodiment of the first aspect or any of its embodiments, wherein the manufacturing apparatus is configured to act as a receiving entity and is also configured to manufacture the article to be manufactured only if the transmitting entity is successfully identified as the owner of the digital asset represented by the received document in step c).

[0089] In other words, manufacturing specifications are an example of digital assets.

[0090] Just as an example, the manufacturing equipment could be a 3D printer. Different file formats such as STL and VRML are common in 3D printing.

[0091] However, in the case of configuring non-fungible tokens as described in the first aspect, even in a heterogeneous environment with several manufacturing devices operating in different file formats, a single non-fungible token can be used to represent the manufacturing specification.

[0092] Using the proposed manufacturing equipment, manufacturing can be advantageously prevented when illegal manufacturing specifications are received from a transmission entity whose legitimate owner cannot be identified. This allows for the automated avoidance of copyright infringement, license infringement, and / or damage to the manufacturing equipment due to the execution of malicious or defective manufacturing specifications.

[0093] As in the embodiments of the first aspect, comparisons between perceptual hashes can be performed based on statistical similarity measures such as Hamming distance or Levenshtein distance.

[0094] According to another aspect, a communication system includes a transmitting entity, a receiving entity, and a distributed transaction database, wherein the transmitting entity and the receiving entity are configured to: a) transmit one of a plurality of files having different file formats, each representing the same digital asset, from the transmitting entity to the receiving entity; and b) perform identification, wherein the transmitting entity is identified to the receiving entity as the owner of the digital asset represented by the transmitted file using a non-fungible token stored in the distributed transaction database and representing the digital asset, wherein the non-fungible token is bound to: a cryptographic root hash of a Merkle tree formed by cryptographic hashes of each of the plurality of files; and a perceptual hash calculated using at least one of the plurality of files.

[0095] The embodiments and features described with reference to the method of the first aspect are also applicable to the communication system of this aspect with appropriate modifications.

[0096] Other possible embodiments or alternative solutions of the present invention also include combinations of features described above or below with respect to the embodiments (not expressly mentioned herein). Those skilled in the art can also add individual or isolated aspects and features to the most basic form of the invention.

[0097] Further embodiments, features, and advantages of the invention will become apparent from the accompanying drawings, the following description, and the dependent claims, wherein: Figure 1 An industrial control and communication system according to a first exemplary embodiment is shown; Figure 2 The illustration shows a digital asset, multiple files representing the digital asset, a Merkle tree, and a non-fungible token, according to a first exemplary embodiment. Figure 3 The illustration depicts method steps of a method for providing one of a plurality of files representing the same digital asset, according to a first exemplary embodiment. Figure 4 The illustration shows a proof of ownership 91 according to a first exemplary embodiment; Figure 5 The illustration shows a proof of ownership 93 according to a second exemplary embodiment; Figure 6 The illustration shows the method steps of a method for minting non-fungible tokens according to a third exemplary embodiment; and Figure 7 The illustration shows a further development of a perceptual hash database based on preferred methods.

[0098] In the figures, unless otherwise indicated, similar reference numerals refer to similar or functionally equivalent elements.

[0099] Figure 1 An industrial control and communication system 1 (an example of a communication system, hereinafter also referred to as "System 1") according to an exemplary embodiment is shown.

[0100] System 1 implements an Industry 4.0 scenario in which the various entities to be described below are provided by different parties (such as different OEMs) with limited trust in each other.

[0101] It will be understood that the entities described below are connected communicatively using wired or wireless networks, such as in order to be able to transmit data, commands, remote procedure calls, etc., between each other.

[0102] In this example, System 1 is an industrial manufacturing line that uses 3D printing for manufacturing.

[0103] Therefore, the first entity of System 1 is Industrial PC 2 (an example of a transport entity). Industrial PC 2 possesses a three-dimensional model 3 (an example of a digital asset) of the product to be manufactured (not shown). Digital asset 3 was originally prepared in a CAD program; however, the CAD program can output multiple files 4 in different formats such as STL, OBJ, VRML, FBX, COLLADA, etc., which can be used as manufacturing specifications for 3D printers (such as 3D printers 51 and 52).

[0104] The industrial control and communication system 1 also includes 3D printers 51 and 52 (examples of manufacturing equipment). Each 3D printer 51, 52 is configured to manufacture products by 3D printing based on an input file containing manufacturing specifications. Since the 3D printers 51 and 52 may be provided by different parties, it is possible that 3D printer 51 requires an input file in a first format (such as VRML), while 3D printer 52 requires an input file in a second format (such as STL) different from the first format.

[0105] Furthermore, System 1 includes Blockchain 6 (an example of a distributed transaction database). Blockchain 6 is formed by multiple node devices 61, 62, and 63. Each node device 61-63 is an industrial computing device that stores a copy of the cryptographically secure transaction ledger 60 and participates in the consensus scheme of Blockchain 6. Ledger 60 (each of its copies) includes multiple blocks 601, 602, and 603. Each block 603, 602, and 601 is cryptographically linked to the corresponding previous block 602, 601, ... Each block 601-603 includes multiple transactions (not shown) that have been published to and confirmed by Blockchain 6. The consensus scheme ensures the consistency of the multiple copies of ledger 60 and ensures that the transactions confirmed by node devices 61-63 in ledger 60 are legitimate and comply with the rules governing the operation of Blockchain 6.

[0106] Industrial PC 2 and 3D printers 51 and 52 each include corresponding wallets 71, 72, and 73. Each wallet 71-73 includes a corresponding key pair, and each key pair includes a public key and a private key. Wallets 71-73 enable entities 2, 51, and 52 of the industrial control and communication system 1 to authenticate using the ledger 60 of blockchain 6 and to publish and receive transactions on the ledger 60 of blockchain 6.

[0107] In an industrial control and communication system 1 in which different entities 2, 51, 52, 61-63 are provided by different parties with limited trust in each other, blockchain 6 achieves mutual trust and transparency regarding the content of transactions submitted to and stored in the ledger 60 of blockchain 6.

[0108] More specifically, the transactions stored in the ledger 60 of the blockchain include smart contracts 611, which provide multiple non-fungible tokens. Figure 1 The document illustrates a specific non-fungible token 8. This non-fungible token 8 is owned by Industrial PC 2. That is, Industrial PC 2 can use the public-private key pair of its wallet 71 to acquire, transfer, and / or prove ownership of the non-fungible token 8. In this document, acquiring (receiving) and transferring (distributing) ownership of the non-fungible token 8 is implemented by submitting a corresponding transaction to Ledger 60, while proving ownership can be implemented by submitting a transaction to Ledger 60, or by performing a challenge-response process using the public-private key pair of wallet 71 without submitting any transaction to Ledger 60. Furthermore, see the following references. Figure 2 The non-fungible token 8 discussed is cryptographically linked to multiple files 4 representing the 3D model 3. Therefore, the non-fungible token 8 represents the 3D model 3 in a cryptographically verifiable manner. Thus, by proving that industrial PC 2 possesses the non-fungible token 8, industrial PC 2 can also prove that it possesses the 3D model 3 and any of the multiple files 4 with different file formats representing the 3D model 3.

[0109] Figure 2 Digital assets 3 (such as...) according to a first exemplary embodiment are shown. Figure 1 The three-dimensional model 3), multiple files representing digital assets 3 4, 41-44, Merkel tree 9, and non-fungible token 8.

[0110] Merkle tree 9 includes, at its lowest level or “leaf” level 910, the cryptographic hashes 911 of the first file 41, 912 of the second file 42, 913 of the third file 43, and 914 of the fourth file 44.

[0111] Files 41-44 are files representing digital asset 3, respectively. However, files 41-44 differ in file format, resolution, level of detail, and other aspects. Therefore, due to the avalanche effect of the cryptographic hash algorithm, their cryptographic hashes 911-914 are quite different.

[0112] The next higher layer 920 of Merkle tree 9 includes cryptographic hash 921, which is a combination of cryptographic hashes 911 and 912. Furthermore, layer 920 also includes cryptographic hash 922, which is a combination of cryptographic hashes 913 and 914. The corresponding combinations can be, for example, juxtapositions. See [link / reference] Figure 2 In the Merkle tree 90, we can say that hash 921 is formed by the parent node of the child nodes of hashes 911 and 912, and hash 922 is formed by the parent node of the child nodes of hashes 913 and 914. Child nodes that share the same parent node are called sibling nodes. Therefore, the node containing hashes 913 and 914 is a sibling node. Similarly, the node containing hashes 911 and 912 is a sibling node.

[0113] At its topmost point, 930, Merkle tree 9 includes the root hash 81, which is a combination of hashes 921 and 922. That is, the node containing hashes 921 and 921 is a sibling node, because both are children of the node containing root hash 81.

[0114] Therefore, any entity that owns (has access to) all the files in the multiple files 41-44 can compute all the cryptographic hashes 911-914, 921-922, 81 in the Merkle tree 9 by computing the cryptographic hash based on the files 41-44 at the leaf layer 910, and then computing the cryptographic hashes of the other layers based on this.

[0115] The non-fungible token 8 is bound to the root hash 81 of the Merkle tree 9. Furthermore, the non-fungible token 8 is also bound to the perceptual hash 82. In this exemplary embodiment, the non-fungible token 8 includes the root hash 81 and the perceptual hash 82 as payload data.

[0116] A perceptual hash algorithm is used to compute a perceptual hash 82 for at least one of the files 41-44. Since files 41-44 all represent the same digital asset 3, it is expected that the perceptual hashes of files 41-44 are identical or similar, i.e., the deviation between the perceptual hashes of files 41-44 is expected to be below a predetermined threshold. So far, it is not decisive which of the files 41-44 is used to compute the perceptual hash 82. However, advantageously, for example, the file with the highest level of detail can be selected to compute the perceptual hash 82. Alternatively, a perceptual hash can be computed for each of the files 41-44, and the perceptual hash 82 pegged to the non-fungible token 8 can be computed as the average of the perceptual hashes computed for each of the individual files 41-44.

[0117] Figure 3 The illustration depicts the method steps of a method for providing one of a plurality of files 4 from a transmitting entity 2 to receiving entities 51, 52 according to a first exemplary embodiment. (Refer to...) Figures 1 to 3 .

[0118] In step S1, when the first 3D printer 51 is to manufacture a product, the industrial PC 2 transmits a file 41 representing the three-dimensional model 3 and having the required first file format to the first 3D printer 51 so that the first 3D printer 51 can manufacture the product to be manufactured.

[0119] In step S2, the industrial PC 2 transmits the ownership certificate 91 of document 41 to the 3D printer 51.

[0120] exist Figure 4 The illustration shows a particular example of a proof of ownership 91 according to a first exemplary embodiment, which is created and transmitted by industry P2 in step S2. (Reference) Figures 1 to 4 .

[0121] The proof of ownership 91 includes an identifier 801 representing a non-fungible token 8 of digital asset 3. Identifier 801 includes a contract address 804 of the smart contract 611 that provides multiple non-fungible tokens and a token ID 805 for a specific non-fungible token 8 within the smart contract 611. Contract address 804 is the address that enables entities such as receiving entity 82 to locate smart contract 611 within blockchain 6. Token ID 805 is an identifier that explicitly identifies a specific non-fungible token 8 representing digital asset 3 within smart contract 611.

[0122] The proof of ownership 2 also includes a list of cryptographic hashes 912, 913, and 914. More specifically, in step S2, the industrial PC 2 determines the cryptographic hashes 912, 913, and 914 of other files 42, 43, and 44 of the plurality of files 4 that were not transmitted in step S1, and includes these cryptographic hashes 912, 913, and 914 in the hash list of the proof of ownership 93.

[0123] Then, the industrial PC 2 transmits the ownership certificate 91 to the 3D printer 51. The 3D printer 51 receives the ownership certificate 91 and uses the identifier 801 included in the ownership certificate 91 to identify the non-fungible token 8 to be used in the next step S3.

[0124] In step S3, using the non-fungible token 8 and proof of ownership 91, the industrial PC 2 is identified by the 3D printer 51 as the authorized owner of the 3D model 3 represented by the transmitted file 41.

[0125] In this document, 3D printer 51 (receiving entity) verifies that industrial PC 2 (transmitting entity) possesses or already possesses the nonfungible tokens 8 at the time of initiating the transmission of file 41. In this example, a challenge-response authentication is performed, where 3D printer 51 encrypts a random challenge using the public key of industrial PC 2, and industrial PC 2 is expected to return a response including a decrypted response, the public key being associated with a wallet address designated as the owner of the nonfungible tokens 8. If industrial PC 2 possesses the private key of its wallet 71, and if said wallet 71 is the wallet designated as the owner of the nonfungible tokens 8, then industrial PC 2 will only be able to return the requested response.

[0126] In this way, 3D printer 51 performs ownership verification and confirms that industrial PC 2 has the right to 3D print the physical product corresponding to the three-dimensional model 3 represented by the non-fungible token 8.

[0127] Furthermore, 3D printer 51 calculates the cryptographic hash of the received file 41 (which, if all goes well, should be the same value as the cryptographic hash 911 of the Merkle tree 9), obtains the remaining parts of the Merkle tree 9 from the received proof of ownership 91 (in this specific example, the cryptographic hashes 912, 913, and 914 of the leaf layer 910), and recalculates the cryptographic root hash 81 of the Merkle tree 9. 3D printer 51 then verifies that the cryptographic root hash 81 calculated in this way matches the cryptographic root hash 81 bound to the non-fungible token 8. Thus, 3D printer 51 performs an integrity verification and confirms that the received file 41 indeed represents the 3D model 3 represented by the non-fungible token 8.

[0128] If the identification in step S3 is successful—that is, if both the identity of the transmitting entity 2 and the integrity of the received file 41 are confirmed—then the right to print on the industrial PC 2 is trusted, and the integrity of the file 41 is trusted. Therefore, the 3D printer 51 can continue printing the product to be manufactured based on the 3D model 3 (i.e., according to the specifications included in the received file 41). However, if the identification in step S2 fails, the 3D printer 51 rejects the received file 41 and does not continue printing.

[0129] The operation and communication between the industrial PC 2 and the first 3D printer 51 have been described. Similarly, when the second 3D printer 52 wants to manufacture a product, the industrial PC 2 transmits a file 42 representing the 3D model 3 and having the required second file format and a corresponding proof of ownership 92 to the second 3D printer 52, so that the second 3D printer 52 can manufacture the product to be manufactured, and uses a non-fungible token 8 and proof of ownership 92 to identify itself as the authorized owner of the 3D model 3 represented by the transmitted file 42. In this document, proof of ownership 92 differs from proof of ownership 91 in that proof of ownership 91 includes cryptographic hashes 912, 913, and 914, while proof of ownership 92 will include cryptographic hashes 911, 913, and 914. In all other respects, the operation and communication between the industrial PC 2 and the second 3D printer 52 are the same as those between the industrial PC 2 and the first 3D printer 51, and their description will be omitted.

[0130] It is noteworthy that in both cases, even though different files 41 and 42, representing the same 3D model 3, have different file formats, they are sent to different 3D printers 51 and 52, the same non-fungible token 8 has been used to identify the non-fungible token 8 as the authorized owner of the 3D model 3.

[0131] It is important to note that malicious entities may attempt to mint another counterfeit, non-fungible token representing the same 3D model 3. A malicious entity could generate a fraudulent file with a different file format than files 41-44 and / or include minor modifications to files 41-44, and bind a counterfeit non-fungible token to the cryptographic hash of the fraudulent file. However, as long as the fraudulent file represents the same 3D model 3, such a fraudulent file will have the same or similar perceptual hash as the one bound to the legitimate non-fungible token 8. Therefore, such an attempt at forgery is easily detected. For example, forgery detection can be performed by searching ledger 60 to obtain a non-fungible token 8 with the same or similar perceptual hash 82.

[0132] In other words, it has been shown how the proposed structure of a single nonfungible token 8 advantageously enables ownership verification, integrity verification, and forgery detection of a digital asset 3 represented by multiple files 4 with different file formats when only any one of the multiple files 4, 41, 42, is transmitted from the transmitting entity 2 to the receiving entity 51, 52. The single nonfungible token 8 is bound to the root hash 81 of a Merkle tree 9 formed based on the cryptographic hashes 911-922 of each of the multiple files 4 and the perceptual hash 82 of at least one of the multiple files 4.

[0133] Figure 5 The illustration shows a proof of ownership 93 according to a second exemplary embodiment. (Reference) Figure 1-3 And 5.

[0134] The second exemplary embodiment is based on the first exemplary embodiment, and redundant descriptions are omitted.

[0135] The second exemplary embodiment differs from the first exemplary embodiment only in the structure of the ownership certificate. In step S2, the industrial PC 2 will have Figure 5 The ownership certificate of the structure shown in the figure is 93 (not the one shown in the figure). Figure 4 The ownership certificate 91 shown in the figure is transmitted to the first or second 3D printer 51, 52.

[0136] The description describes a scenario where ownership certificate 93 is transmitted together with the first file 41, i.e., ownership certificate 93 replaces ownership certificate 91.

[0137] Similar to Proof of Ownership 91, Proof of Ownership 93 includes an identifier 801 for the non-fungible token 8, which includes a contract address 804 and a token ID 805. However, Proof of Ownership 93 includes a different list of hashes. Specifically, Proof of Ownership 93 does not include all the cryptographic hashes 912-914 for all untransmitted files 42-44.

[0138] Conversely, in step S3, industrial PC 2 selects cryptographic hashes 911-922 for each sibling node of the node on the corresponding layer of the transmitted file for each layer 910, 920, 930 of Merkle tree 9.

[0139] In other words, on the lowest leaf layer 910 of the Merkle tree 9, the cryptographic hash 911 is stored in the node corresponding to the transmitted file 41. Therefore, the cryptographic hash 912 stored in the sibling node of the node storing the cryptographic hash 911 is included in the proof of ownership 93.

[0140] On the intermediate layer 920 of the Merkle tree, hash 921 is stored in the node corresponding to the transmitted file 41. Hash 921 can be calculated based on hashes 911 and 912, where hash 911 is calculated by the receiving entity 51 based on the received file 41, and hash 912 is included in the proof of ownership 93. Therefore, hash 921 is not included in the proof of ownership 93. However, hash 922 is stored in the sibling node of the node storing hash 921 on the intermediate layer 920. Therefore, hash 922 is included in the proof of ownership 93.

[0141] At the top level 930 of the Merkle tree, the root hash 81 can be calculated based on the calculated hashes 921 and 922, with hash 922 included in the proof of ownership 93. Since there are no sibling nodes at the top level 930, nothing further needs to be included in the proof of ownership 93.

[0142] Therefore, as by Figure 4 and Figure 5 A comparison shows that, for Figure 2 The three-level Merkle tree 9 shown, according to the second exemplary embodiment, has a proof of ownership 93 that is one element shorter than the proof of ownership 91 according to the first exemplary embodiment, but is still sufficient to compute the cryptographic root hash 81.

[0143] When there are a larger number of files 4 and the Merkle tree includes more than three levels, the benefits of constituting the proof of ownership 93 according to the teachings of the second exemplary embodiment are more clearly expressed. The required size of the proof of ownership 91 (the length of the hash list) grows exponentially with the number of levels or linearly with the number of files 4, while the required size of the proof of ownership 93 grows only linearly with the number of levels or logarithmically with the number of files 4.

[0144] Furthermore, by not disclosing most of the perceptual hashes 911-914 of multiple documents 41-44, the proof of ownership 93 advantageously increases data security and makes forgery more difficult. That is, perceptual hashes 911, 913, and 914 are not disclosed in the proof of ownership 93.

[0145] Figure 6 The steps of a method for minting non-fungible tokens according to a third exemplary embodiment are shown. (Reference) Figure 6 , Figure 1 and Figure 2 .

[0146] The third exemplary embodiment relates to a situation where an entity has created a digital asset 3 that has not yet been claimed in blockchain 6.

[0147] The method steps of the third exemplary embodiment can be combined with the method steps of the first or second exemplary embodiment. For example, the industrial PC 2 can first mint non-fungible tokens 8 for its digital asset 3 according to the method steps of the third exemplary embodiment, and then use the minted non-fungible tokens 8 to continue providing one of the documents 4 to the 3D printers 51, 52 according to the method steps of the first or second exemplary embodiment.

[0148] In step S11, entity 2, such as industrial PC 2, exports digital asset 3 into multiple different file formats. Thus, multiple files 4 representing the same digital asset 3 in different file formats are obtained.

[0149] In step S12, entity 2 uses a cryptographic hash function such as SHA-256 to calculate the cryptographic hashes 911-914 of multiple files 4, and calculates the additional cryptographic hashes 921 and 922 of the other layers 920 and 930 of the Merkle tree 9 until the cryptographic root hash 81 is obtained.

[0150] In step S13, entity 2 calculates the perceptual hash of multiple files 4 and calculates the perceptual hash 82 as the average of the calculated perceptual hashes.

[0151] In step S14, entity 2 uses its wallet 71 to execute a transaction with smart contract 611, causing the minting of non-fungible token 8. During minting, the token ID of non-fungible token 8 ( Figure 4 805 in the middle becomes associated with wallet 71 of entity 2. Entity 2 then binds the root hash 81 and the perceptual hash 82 to the non-fungible token 8.

[0152] According to a variant, in order to perform the binding, entity 2 stores the cryptographic root hash 81 and the perceptual hash 82 as payload data in the non-fungible token 8.

[0153] According to another variant of the binding, entity 2 creates a JSON file for metadata, stores the cryptographic root hash 81 as a key-value pair in the JSON file, stores the perceptual hash 82 as a key-value pair in the JSON file, optionally adds additional information to the JSON file such as download addresses of multiple files 4, additional parts of the Merkle tree 9, etc., uploads the JSON file to a file server or cloud such as the InterPlanetary File System (IPFS), and stores the URI, from which the JSON file is obtained as payload data within the non-fungible token 8.

[0154] According to the third exemplary embodiment, starting from a single, identical digital asset 3, a single non-fungible token 8 has been created, representing multiple files 4 with different formats that represent the digital asset 3. The single non-fungible token 8 includes a cryptographic root hash 81 and a perceptual hash 82. Therefore, the non-fungible token 8 enables ownership verification, integrity verification, and forgery detection for any of the multiple files 4 representing the digital asset 3.

[0155] Figure 7 The illustration shows a further developed perceptual hash database 800 based on preferred methods. Combined with... Figures 1 to 3 refer to Figure 7 .

[0156] The perceptual hash database 800 is a non-transactional indexed database. Multiple data records 851, 852 are stored in the perceptual hash database 800. Each record 851, 852 specifies one of multiple non-fungible tokens 8 stored in the ledger 60 of blockchain 6. Each record 851, 852 includes perceptual hashes 821, 822, ... and identifiers 801, 802, where identifiers 801, 802 identify the corresponding non-fungible token 8 bound to the corresponding perceptual hash 821, 822, ... . That is, the perceptual hash database 800 stores identifiers 801, 802 associated with their corresponding perceptual hashes 821, 822. This can be compared with reference to... Figure 4 and Figure 5 Identifiers 801 and 802 are constructed in the same way as identifier 801 discussed. That is, identifiers 801 and 802 locate the corresponding non-fungible token 8 in the ledger 60 of blockchain 6.

[0157] The perceptual hash database 800 is indexed by perceptual hashes. That is, the perceptual hash database 800 can be queried by perceptual hashes. When a given perceptual hash is queried, the perceptual hash database 800 will quickly return zero, one, or more records 851, 852 that are the same as or similar to the perceptual hashes 821, 822 on which the query is based.

[0158] Therefore, the perceptual hash database 800 can be used to quickly locate non-fungible tokens 8 based on their perceptual hashes 821, 822 for counterfeit detection purposes or the like, and provides a considerable speed improvement compared to having to search for such non-fungible tokens 8 by traversing the ledger 60 of the blockchain 6.

[0159] Figure 7 The perceptual hash database 800 is for Figure 1 Further developments of System 1, as described in the first to third exemplary embodiments, provide applications in counterfeit detection.

[0160] In an additional development of the first or second exemplary embodiment, in step S3, the corresponding receiving entity, such as 3D printer 51 or 3D printer 52, after identifying the nonfungible token 8 according to the identifier 801 included in the transmitted proof of ownership 91, queries the perceptual hash database 800 to determine whether records 851, 852 identify other nonfungible tokens with perceptual hashes 821, 822 similar to those bound to the identified nonfungible token 8. If so, the receiving entities 51, 52 determine that more than one of their owning entities possesses corresponding nonfungible tokens claiming ownership of digital asset 3 or highly similar digital assets, and therefore, at least one of the plurality of nonfungible tokens with similar perceptual hashes 821, 822 may be counterfeit. In this case, the receiving entities 51, 52 fail the identification in step S3 and reject the received documents 41, 42.

[0161] In this paper, and in other developments discussed below, the similarity between any two perceptual hashes 82, 821, 822 can be determined using a statistical similarity measure such as Hamming distance or Levenshtein distance. If the statistical similarity measure is at or below a predetermined threshold, the compared perceptual hashes 82, 821, 822 can be determined to be similar.

[0162] It is important to note that, in this case, when minting the non-fungible token 8, the perceptual hash 82 is preferably determined as the average of the perceptual hashes of the various files 4, 41-44. Setting the perceptual hash 82 to be bound to the non-fungible token 8 as the average perceptual hash increases the likelihood that small deviations in perceptual hashes that naturally occur between different file formats will be below a threshold, while larger deviations due to the dissimilarity of the underlying digital assets will be above the threshold.

[0163] In another development of the first or second exemplary embodiment, the identifier 801 of the nonfungible token 8 may be omitted from the ownership certificates 91-93 being transmitted from the transmitting entity 2 to the receiving entities 51, 52, and the ownership certificates 91-93 may only include the corresponding hash list. In this case, when the transmitted files 41, 42 are received in step S1, the corresponding receiving entities 51, 52 can calculate a perceptual hash based on the received files 41, 42, and can use the calculated perceptual hash to query the perceptual hash database 800 to obtain any matching records 851, 852 with perceptual hashes 821, 822 similar to the calculated perceptual hash. If exactly one matching record exists, such as record 852, the receiving entities 451, 52 identify the nonfungible token 8 based on the identifier 802 associated with the matching perceptual hash 822 in record 852. That is, the nonfungible token 8 for the additional identification step in step S3 can be determined solely based on the perceptual hash of the received file 71. Furthermore, if there are more than one matching record, such as if both records 851 and 852 match, the receiving entities 51 and 52 may determine that at least one of the non-fungible tokens 8 identified by the corresponding identifiers 801 and 802 of the matching records 851 and 852 may be counterfeit, and may cause the identification in step S3 to fail, and reject the received files 41 and 42.

[0164] In another development of the third exemplary embodiment, forgery detection can be performed by blockchain 6 when new non-fungible tokens are minted.

[0165] In other words, the smart contract 611, which is invoked in step S14 to enable the minting of the nonfungible token 8, can be configured to query the perceptual hash database 800 for the perceptual hash 82 of the nonfungible token 8 to be minted, and to accept the minting of the nonfungible token 8 only if the response received from the perceptual hash database 800 indicates that the blockchain 6 (smart contract 611 and / or another smart contract that also provides the nonfungible token) does not contain any other nonfungible tokens bound to a perceptual hash similar to the perceptual hash 82 of the nonfungible token 8 to be minted.

[0166] In this way, counterfeit, non-fungible tokens are prevented from being minted from the outset, thereby advantageously increasing trust.

[0167] There are various ways to ensure that the perceptual hash database 800 is synchronized with the ledger 60 of the blockchain 6, that is, its records 851, 852 accurately describe which non-fungible tokens 8 are part of the ledger 60.

[0168] According to another development, an assistant script executed at periodic intervals on a device (such as on one of node devices 61, 62, 63) or on an external device (not shown) capable of accessing blockchain 6 can scan the ledger for non-fungible tokens and add corresponding records 851, 852 to the perceptual hash database 800 for any non-fungible token 8 that follows the structure disclosed herein.

[0169] According to another development, whenever a new nonfungible token 8 is minted, the blockchain 6 can cause the perceptual hash database 800 to be automatically updated. For example, in a third exemplary embodiment, if the token is successfully minted, the smart contract 611 invoked to cause the minting of the nonfungible token 8 can cause the creation of new records 851, 852 in the perceptual hash database 800, wherein in the new records 851, 852, the perceptual hashes 821, 822 of the most recently minted nonfungible token 8 are associated with the identifier 801 of the most recently minted nonfungible token 8.

[0170] The perceptual hash database 800 can be provided as a trusted perceptual hash database for System 1 in various ways.

[0171] According to another development, the Trusted Aware Hash Database 800 is pre-agreed and provided by a (not shown) computing device or cloud that is part of System 1 and trusted by the parties of Operating System 1.

[0172] According to another development, each smart contract 611 can specify a perceptual hash database 800 that it trusts, and this perceptual hash database 800 is to be used, for example, by receiving entities 51, 52 to perform forgery detection. For example, smart contract 611 can provide an API endpoint for invoking the perceptual hash database 800.

[0173] According to yet another development, each entity wishing to perform forgery detection (such as receiving entities 51, 52) may include corresponding node devices 61-63 of blockchain 6, on which it may store its own copy of ledger 60, and may also include a corresponding private perceptual hash database 800 that it trusts and uses for fast lookups in the copy of ledger 60. In this way, trust in any externally provided perceptual hash database is not required, and the corresponding entity can completely trust the perceptual hash database 800 because it operates under its own complete control.

[0174] Although the invention has been described with reference to preferred embodiments, it will be apparent to those skilled in the art that modifications are possible in all embodiments.

[0175] Provided there is no contradiction, the variations and further developments described above can be freely combined with any exemplary embodiment of the first to third exemplary embodiments and / or with each other.

[0176] In the first and second exemplary embodiments, for step S3, the challenge-response based authentication between the 3D printer 51 and the industrial PC 2 is described as a means by which the 3D printer 51 (receiving entity) confirms the identity of the industrial PC 2 (transmitting entity) as the owner of the non-fungible token 8.

[0177] However, in another exemplary embodiment, it is conceivable that, as part of steps S1 and / or S2, industrial PC 2 uses its wallet 71 to execute a transaction on blockchain 6, wherein ownership of the non-fungible token 8 is transferred from industrial PC 2 (its wallet 71) to 3D printer 51 (its wallet 72). In this case, when step S3 is executed, receiving entity 51 has already acquired ownership of the non-fungible token 8. Then, confirming the identity of transmitting entity 2 as the (former) owner of the non-fungible token 8 in step S3 can be considered a no-operation, because if transmitting entity 2 were not originally the owner, it would not have been able to transfer ownership of the non-fungible token 8 to receiving entity 51 via blockchain 6. Also in this case, the identifier 801 of the non-fungible token 8 can be omitted from the ownership proofs 91, 93 transferred in step S2, since receiving entity 51 already knows the identity of the non-fungible token 8.

[0178] For the third exemplary embodiment, two alternative methods for binding the cryptographic root hash 81 and the perceptual hash 82 to the non-fungible token 8 are discussed. Those skilled in the art will appreciate that other variations of the binding can also be used with the first and second exemplary embodiments, wherein the non-fungible token 8 comprises a URI pointing to a JSOIN file or similar from which the hash can be obtained.

[0179] For the first and second exemplary embodiments, it is described that in step S1, file 41 is transferred from transmitting entity 2 to receiving entity 51. However, it is conceivable that, as payload data, the non-fungible token 8 contains a URI pointing to a JSON file, which includes one or more additional URIs as key-value pairs indicating where multiple files 4 can be downloaded. In this case, step S1 of transferring file 4 from transmitting entity 2 to receiving entity 51 can also be embodied by receiving entity 51 retrieving the requested file 41 from the URI it retrieves from the non-fungible token 8, and it is not required that file 41 be directly transferred from transmitting entity 2 to receiving entity 51.

[0180] Throughout this manual, references to the Ethereum blockchain and specific Ethereum standards are made for ease of understanding. However, it will be appreciated that the teachings of this manual apply to any distributed transaction database technology that supports smart contracts and non-fungible tokens. Other examples of suitable distributed transaction database technologies include Flow, Cardano, Solana, EOS, WAX, Tron, Binance Smart Chain, and Bitcoin, or any sidechain of the above. Furthermore, the distributed transaction database does not need to be a public ledger of one of the well-known blockchains mentioned above. Instead, in Industry 4.0 scenarios, it is advantageous to build a private blockchain using one of the technologies mentioned above, but whose overall structure consists of compute nodes operated by various industrial operators (such as various OEMs or the like) participating in the Industry 4.0 scenario but with limited trust in each other.

[0181] Throughout the description of the figures, 3D printers 51 and 52 are disclosed as examples of receiving entities, industrial PC 2 is disclosed as an example of a transmitting entity, and 3D model 3 is disclosed as an example of a digital asset that can be represented by multiple files with different file formats. However, these are merely non-limiting examples. The principles taught in this specification can be applied to most diverse industrial scenarios with any kind of digital assets, provided that a method exists to derive a perceptual hash from the selected type of digital asset, and that the digital asset can be represented by files with different file formats. For example, digital assets can also be two-dimensional product images, audio recordings, video recordings, etc.

[0182] The perceptual hash 82 included in the non-fungible token 8 is not only suitable for counterfeit detection. The perceptual hash 82 can also be used for quality control of manufacturing equipment (such as 3D printers 51, 52). For example, when manufacturing an article to be manufactured according to the manufacturing specifications included in the received document 41, the corresponding 3D printers 51, 52 can acquire an image of the article to be manufactured; calculate a perceptual hash of the acquired image; and determine whether the article to be manufactured correctly based on a comparison between the calculated perceptual hash and the perceptual hash 82 bound to the non-fungible token 8.

[0183] In any term (such as operator or similar) that designates an individual, individuals with male, female or other gender identities are included in the term, independent of grammatical usage.

Claims

1. A computer-implemented method for providing one of a plurality of files (4) (41, 42) from a transmitting entity (2) to a receiving entity (51, 52), said plurality of files (4) having different file formats and each file representing the same digital asset (3), said method comprising: a) Transfer (S1) the file (41, 42) from the transmission entity (2) to the receiving entity (51, 52). b) Transmitting (S2) the ownership certificates (91-93) of the transmitted files (41, 42) from the transmitting entity (2) to the receiving entity (51, 52); and c) The transmitting entity (2) uses the transmitted ownership certificate (91-93) and the non-fungible token (8) stored in the distributed transaction database (6) and representing the digital asset (3) to identify itself to the receiving entity (51, 52) as the owner of the digital asset (3) represented by the transmitted files (41, 42). The non-fungible token (8) is bound to: - The root hash (81) of the Merkle tree (9) formed based on the cipher hashes (911-914) of each of the plurality of files (4); and - A perceptual hash (82) calculated using at least one of the multiple files (4), and The ownership proof (91-93) includes at least a portion of the Merkle tree (9) sufficient to calculate the root hash (81) based on the cryptographic hash of the transmitted files (41, 42).

2. The method according to claim 1, in, If the identification in step c) fails, the receiving entity (51, 52) rejects the received file (41, 42).

3. The method according to claim 1 or 2, in, The perceptual hash (82) is the average of the perceptual hashes of each of the plurality of files (4).

4. The method according to any one of claims 1 to 3, in, Step c) includes: - The receiving entity (51, 52) confirms that the identity of the transmitting entity (2) is the owner of the non-fungible token (8); - The receiving entities (51, 52) confirm the integrity of the transmitted files (41, 42) as one of the plurality of files (4) representing the digital asset (3) represented by the non-fungible token (8); and - If at least one of the confirmation steps fails, then the identification in step c) fails.

5. The method according to claim 4, in, The receiving entity (51, 52) confirms the identity of the transmitting entity (2) as the owner of the non-fungible token (8) based on one of the following: - The transmitting entity (2) uses transactions in the distributed transaction database (6) to transfer ownership of the non-fungible token (8) to the receiving entities (51, 52); and The transmitting entity (2) uses challenge-response authentication to prove to the receiving entity (51, 52) its ownership of the non-fungible token (8).

6. The method according to any one of claims 1 to 5, in, As a sufficient part of the Merkle tree (9), the proof of ownership (93) includes: for each layer (910, 920, 930) of the Merkle tree (9), a cryptographic hash of each sibling node of the node corresponding to the transmitted file (41, 42) on the corresponding layer (910, 920, 930).

7. The method according to any one of claims 1 to 6, in, Step c) also includes: - The receiving entities (51, 52) calculate the perceptual hash of the files (41, 42) received in step a), and - If the distributed transaction database (6) contains more than one nonfungible token bound to a perceptual hash (81), the receiving entity (51, 52) causes the identifier in step c) to fail, the perceptual hash (81) being similar to the calculated perceptual hash of the received file (41, 42).

8. The method according to any one of claims 1 to 7, Also includes: - The receiving entities (51, 52) calculate the perceptual hash of the files (41, 42) received in step a), and -If the distributed transaction database (6) contains exactly one nonfungible token (8) bound to a perceptual hash (82), then the receiving entity (51, 52) uses the exactly one nonfungible token (8) for the identifier in step c), the perceptual hash (82) being similar to the calculated perceptual hash of the received file (41, 42).

9. The method according to any one of claims 1 to 8, It also includes minting (S14) the non-fungible token (8) in the distributed transaction database (6). in, The distributed transaction database (5) accepts the minting of the non-fungible token (8) on the condition that the distributed transaction database (6) does not contain another non-fungible token bound to a perceptual hash (82) similar to the perceptual hash of the non-fungible token (8) to be minted.

10. The method according to any one of claims 7 to 9, in, To determine one or more nonfungible tokens (8) stored in the distributed transaction database (6) and bound to similar perceptual hashes, a trusted perceptual hash database (800) is queried, wherein the identifiers (801, 802) of the nonfungible tokens included in the distributed transaction database (6) are stored in association with the corresponding perceptual hashes (821, 822) of the corresponding nonfungible tokens (8).

11. The method according to claim 10, in, When accepting the minting of nonfungible tokens (8), the distributed transaction database (6) stores the identifier (801, 802) of the nonfungible tokens (8) in the trusted perceptual hash database (800) in association with the perceptual hash (82) bound to the nonfungible tokens (8).

12. The method according to any one of claims 7 to 11, in, When the statistical similarity metric is below a predetermined threshold, a decision is made as to whether the perceptual hashes are similar.

13. A computer program product comprising program code for performing the method of any one of claims 1 to 12 when run on at least one computer.

14. A manufacturing apparatus (51, 52) configured to receive documents (41, 42), said documents (41, 42) comprising manufacturing specifications for an article to be manufactured according to the method of any one of claims 1 to 12, wherein, The manufacturing equipment (51, 52) is configured to act as the receiving entity (51, 52) and is also configured to manufacture the article to be manufactured only if, in step c), the transmitting entity (2) is successfully identified as the owner of the digital asset (3) represented by the received file (41, 42).

15. A communication system (1), comprising a transmission entity (2), a receiving entity (51, 52), and a distributed transaction database (6), wherein, The transmitting entity (2) and the receiving entities (51, 52) are configured as follows: a) Transfer (S1) a file (41, 42) from the transmission entity (2) to the receiving entity (51, 52). b) Proof of ownership (91-93) of the files (41, 42) transmitted from the transmitting entity (2) to the receiving entity (51, 52) via transmission (S2); and c) Execute (S3) identification, wherein, using the transmitted ownership certificate (91-93) and the non-fungible token (8) stored in the distributed transaction database (6) and representing the digital asset (3), the transmitting entity (2) is identified to the receiving entity (51, 52) as the owner of the digital asset (3) represented by the transmitted files (41, 42). The non-fungible token (8) is bound to: - The root hash (81) of the Merkle tree (9) formed based on the cipher hashes (911-914) of each of the plurality of files (4); and - A perceptual hash (82) calculated using at least one of the multiple files (4), and The ownership proof (91-93) includes at least a portion of the Merkle tree (9) sufficient to calculate the root hash (81) based on the cryptographic hash of the transmitted files (41, 42).

Images