Method and system for universal source solutions for blockchain supply chain applications

Abstract

The invention relates to a method and system for a universal source solution for blockchain supply chain applications. A method for communicating audible information about a source of a product, the information being cryptographically accurate while maintaining complete anonymity of the product and participants on a blockchain, the method comprising: receiving a product identifier; generating a digital token by applying a hash algorithm to the product identifier; generating an entry value by applying a hash algorithm to a combination of the event identifier and the digital token; digitally signing a data packet using a private key of the encrypted key pair to generate a digital signature, the data packet including at least a blockchain address, an event identifier, and a digital token; and transmitting the block chain address, the digital signature and the entry value to a node in the block chain network.

Description

[0001] This divisional application is a divisional application of Chinese patent application No. 202080032360.3, entitled “Methods and Systems for Universal Provenance Solutions for Blockchain Supply Chain Applications”, filed on May 15, 2020.

[0002] CROSS-REFERENCE TO RELATED APPLICATIONS

[0003] This application is based upon and claims the benefit of and priority to U.S. Provisional Application No. 62 / 851,998, filed on May 23, 2019, and U.S. Provisional Application No. 62 / 874,720, filed on July 16, 2019, which are incorporated herein by reference in their entireties and for all purposes. Technical Field

[0004] The present disclosure relates to the use of blockchain to provide solutions to supply chain problems regarding product provenance, and in particular the use of blockchain and cryptographic techniques to convey auditable information about product provenance that is cryptographically accurate while maintaining the anonymity of the products and participants (even on the blockchain). Background Art

[0005] In recent years, consumers have become more concerned than ever about where the products they purchase and interact with come from. There are many reasons why someone might be interested in the provenance of a product: a consumer might want to ensure that a manufacturer uses ethical practices, a reseller might want to confirm the ownership history of a used item, a manufacturer might need to track product distribution in connection with a necessary recall, a distributor might be concerned about leaks during the distribution of a particular product, etc. Traditionally, the solutions to these problems can be as varied as the problems themselves. For example, a distributor might use a scanning system and place their own labels on the packaging, but this might be of little use to the manufacturer or end user. In another example, a consumer might find out about the manufacturer's ethical practices, but have no way to verify that the product they purchased is genuine from the manufacturer. In yet another example, a manufacturer might need to recall and know which products must be recalled, but have little ability to contact the end merchant or consumer who received the product.

[0006] Therefore, existing solutions (such as supply chain programs, certificates of authenticity, logistics software, etc.) usually only provide specific solutions for one aspect of the supply chain. At the same time, many manufacturers and merchants may be cautious about inclusive solutions because they want to keep their networks and practices and other information (such as sales or manufacturing indicators) confidential. Thus, there is a need for a technical system that can provide provenance solutions throughout the life cycle of products in the supply chain without compromising the privacy or confidentiality of manufacturers (or even the identity of the products involved). Summary of the invention

[0007] The present disclosure provides a description of systems and methods for conveying auditable information about the origin of products through blockchain. Whenever an action is taken on the manufacturer and distribution of a product, an entry is created for the product on the blockchain. Such actions may include the manufacturer of the product, the aggregation of the product with other products, the sending and receiving between various entities, the de-aggregation of the product, the sale of the product, and the resale of the product. Each time an entry is created on the blockchain, the entry captures a digital signature generated by the entity involved in the event (e.g., the manufacturer when releasing the product, the distributor when receiving the product from the manufacturer, etc.). The entry also captures and provides a signature on a combination of an identifier associated with the event (e.g., the release of the product, the receipt of the product, the sending of the product, etc.) and a token unique to the product. The token is generated by hashing an identifier unique to the product, which can only be obtained through the possession of the product. The result is that only individuals or entities that can physically obtain the product can identify any entry related to the product, but anyone who does can see a picture of the entire source of the product (such as to confirm that the purchased item is authentic). At the same time, the use of hashing and signatures means that each entity involved remains anonymous while allowing auditability and verification between the entities themselves. Thus, the methods and systems discussed herein provide a complete and auditable record of product provenance that is anonymous even on the blockchain, providing a complete end-to-end solution regarding product provenance that serves every entity involved without sacrificing privacy.

[0008] A method for conveying auditable information about the provenance of a product that is cryptographically accurate while maintaining the anonymity of the product and participants on a blockchain, the method comprising: receiving a product identifier by an input device interfaced with a computing device; generating a digital token by a processor of the computing device by applying a hash algorithm to the product identifier; generating an entry value by the processor of the computing device by applying a hash algorithm to a combination of an event identifier and the digital token; generating a digital signature by the processor of the computing device by digitally signing a data packet using a private key of a cryptographic key pair, wherein the data packet includes at least a blockchain address, an event identifier, and the digital token; transmitting the blockchain address, the digital signature, and the entry value to a node in a blockchain network by a transmitter of the computing device.

[0009] A system for communicating auditable information about the provenance of a product that is cryptographically accurate while maintaining the anonymity of the product and participants on a blockchain, the system comprising: a blockchain network including a plurality of nodes; an input device interfaced with a computing device that receives a product identifier; the computing device comprising a processor and a transmitter, wherein the processor generates a digital token by applying a hash algorithm to the product identifier, generates an entry value by applying a hash algorithm to a combination of an event identifier and the digital token, and generates a digital signature by digitally signing a data packet using a private key of a cryptographic key pair, the data packet including at least a blockchain address, an event identifier, and the digital token, and the transmitter transmits the blockchain address, the digital signature, and the entry value to one of the plurality of nodes in the blockchain network. BRIEF DESCRIPTION OF THE DRAWINGS

[0010] The scope of the present disclosure may be best understood from the following detailed description of exemplary embodiments when read in conjunction with the accompanying drawings, which include the following figures:

[0011] Figure 1 is a block diagram illustrating a high-level system architecture for communicating product provenance via blockchain, according to an exemplary embodiment.

[0012] Figure 2 is a diagram illustrating a method of performing a Figure 1 Block diagram of the computing system used in the system.

[0013] Figure 3 is a diagram illustrating a method of performing a Figure 1 Flowchart of the product delivery process in a supply chain in a system where auditability can be obtained via blockchain.

[0014] Figure 4 is a flow chart illustrating an exemplary method for communicating auditable information about the origin of a product in accordance with an exemplary embodiment.

[0015] Figure 5 is a block diagram illustrating a computer system architecture according to an exemplary embodiment.

[0016] Further areas of applicability of the present disclosure will become apparent from the detailed description provided hereinafter.It should be understood that the detailed description of the exemplary embodiments is intended for illustration purposes only and is not intended to necessarily limit the scope of the present disclosure. DETAILED DESCRIPTION

[0017] Professional terminology

[0018] Blockchain - A ledger of all transactions of blockchain-based assets, whether public or private, permissioned or permissionless. One or more computing devices may include a blockchain network, which may be configured to process and record transactions as part of a block in a blockchain. Once a block is completed, the block is added to the blockchain, thereby updating the transaction record. In many cases, the blockchain may be a chronological ledger of transactions, or may be presented in any other order suitable for use by the blockchain network. In some configurations, transactions recorded in the blockchain may include a destination address and a monetary amount, so that the blockchain records how much currency is attributed to a specified address. In some cases, transactions are financial, while other transactions are not financial, or may include additional or different information (such as source addresses, timestamps, etc.). In some embodiments, the blockchain may also or alternatively include virtually any type of data in the form of transactions that have been or need to be placed in a distributed database that maintains a growing list of data records that is hardened against tampering and modification even by its operators, and the blockchain may be confirmed and verified by the blockchain network through proof of work and / or any other suitable verification technology associated therewith. In some cases, data about a given transaction may also include additional data that is appended to the transaction data and is not directly part of the transaction. In some cases, the inclusion of such data in the blockchain may constitute a transaction. In such cases, the blockchain may not be directly associated with a particular digital, virtual, legal or other type of currency.

[0019] Product provenance system via blockchain

[0020] Figure 1 A system 100 is described for communicating the provenance of a product, with information that is auditable, cryptographically accurate, and provable while preserving the anonymity of the products and entities involved on a blockchain that is capable of being independent of any authentication or authorization mechanism, thereby having potential utility for any blockchain platform, whether public or private, permissioned or permissionless.

[0021] System 100 may include a blockchain network 102. Blockchain network 102 may be composed of a plurality of blockchain nodes 104 (for clarity of illustration, only some of the potentially many blockchain nodes are shown). Each blockchain node 104 may be a computing system (such as Figure 2 and Figure 5, which will be discussed in more detail below, is configured to perform functions related to the processing and management of blockchains, including the generation of blockchain data values, the verification of proposed blockchain transactions, the verification of digital signatures, the generation of new blocks, the verification of new blocks, and the maintenance of copies of blockchains. A blockchain may be a distributed ledger consisting of at least a plurality of blocks. Each block may include at least a block header and one or more data values. Each block header may include at least a timestamp, a block reference value, and a data reference value. The timestamp may be the time when the block header was generated, and may be represented using any suitable method (e.g., UNIX timestamp, DateTime, etc.). The block reference value may be a value that references an earlier block in the blockchain (e.g., based on a timestamp). In some embodiments, the block reference value in the block header may be a reference to a block header of a block that was most recently added before the corresponding block. In an exemplary embodiment, the block reference value may be a hash value generated via a hash of a block header of a most recently added block. The data reference value may similarly be a reference to one or more data values ​​stored in a block that includes a block header. In an exemplary embodiment, the data reference value may be a hash value generated via a hash of one or more data values. For example, the block reference value may be the root of a Merkle tree generated using one or more data values.

[0022] The use of block reference values ​​and data reference values ​​in each block header may result in a blockchain that is immutable. Any attempted modification of a data value would require the generation of a new data reference value for that block, which would require the generation of a new block reference value for subsequent blocks, which would further require the generation of a new block reference value in each subsequent block. This must be performed and updated in every node in the blockchain network before a new block is generated and added to the blockchain in order for the change to become permanent. Computational and communication constraints may make such modifications extremely difficult (if not impossible), rendering the blockchain immutable.

[0023] As discussed herein, blockchain data values ​​may be configured to store data about the origin of a product. In system 100, manufacturers 106 may manufacture products for sale and may be interested in using a blockchain associated with blockchain network 102 to keep records of the origin of the products they manufacture. As discussed herein, a product may refer to any object, item, commodity, substance, etc., whose origin an entity involved in its supply chain may be interested in tracking. For example, a product may be a shoe, jewelry, a vehicle, a prescription drug, a laboratory sample, a sports memorabilia, an Olympic medal, sports competition equipment, a food product, etc., or virtually anything else.

[0024] In the system 100, a manufacturer 106 may manufacture a product that is subsequently distributed and ultimately sold. The system 100 illustrates an example supply chain for a manufactured product involving the manufacturer 106, a single distributor 108, a merchant 110, and a user 114. However, as described herein, the methods and systems discussed herein are applicable to any supply chain involving any number of entities performing any functions related to the origin of a product that may be captured on a blockchain. For example, a supply chain may involve multiple distributors 108 (such as national distributors, international shippers, and local carriers), as well as multiple merchants 110 (such as wholesalers, retailers, and resellers), wherein the methods and systems discussed herein will apply accordingly to the entities involved.

[0025] In the example system 100, a manufacturer 106 may manufacture a plurality of products that may be packaged together and provided to a distributor 108 for distribution. The distributor 108 may transport the product packages to a merchant 110, which may then separate the packages into individual products and make them available for sale to consumers. Consumers, who are users 114, may then purchase the products from the merchant 110. As discussed in more detail below, the user 114 may possess a user device 112 that may be used to identify the source of the product before or after purchase, and, where applicable, participate in the supply chain as a recipient and / or sender of the product.

[0026] Each interaction with a product during its lifecycle in a supply chain can be captured in a blockchain. As discussed herein, these interactions may be referred to as “events.” Events may include, for example, the release of a product (e.g., manufacturing), the sending of a product (in any form, such as shipping, delivery, transportation, or pick-up / transfer access rights), the receipt of a product, the aggregation of multiple products together, the disassembly of multiple products, and the sale or consumption of a product. Each time an event occurs, the relevant entity may perform multiple actions resulting in the submission of information to a blockchain node 104 in the blockchain network 102. The blockchain node 104 may include the information in a new blockchain data value, which is included in a new block generated and added to the blockchain by other blockchain nodes 104 using traditional methods and systems after confirmation. In some cases, the actions performed by entities associated with the submission to the blockchain may vary depending on the event and the involvement of other entities. For example, as discussed herein, there may be more involvement in sending or receiving events than in publishing or aggregating events, as described below.

[0027] As part of the event, the entity may first identify a product identifier for the product. The product identifier may be a unique identifier uniquely associated with the product and may be unique across all instances of the product (e.g., an identifier may be unique across each shoe in a particular product line, but may not be unique across all shoes). In some cases, the product identifier may be universally unique across all products (such as having a fairly long or complex identification number, or as a combination of values). For example, each shoe in a product line may have a serial number, where the product identifier may be a combination of the serial number and the product line (e.g., 12345678-CloudShoe6). The entity may identify the product identifier using any suitable means. For example, the product identifier may be printed directly on the product, or encoded in a machine-readable code (e.g., a barcode, a quick response code, etc.), attached to the product (e.g., a removable tag), embedded in the product and read via a suitable device, etc. The entity may enter the product identifier into the computing device using any suitable means (such as manually entered by a user, transmitted via an input device interfaced with the computing device, etc.).

[0028] The entity's computing system can then generate a digital token for the product by applying a hash algorithm to the product identifier. The hash algorithm can be any suitable type of algorithm (such as a SHA-256 algorithm). In an exemplary embodiment, the hash algorithm can be a one-way algorithm so that the resulting digital token cannot be reversed to identify the underlying product identifier. In some cases, the resulting digital token value may have a considerable length and complexity to prevent conflicts. Once the digital token is obtained, the entity can use their computing system to generate a data packet. The data packet may include at least a blockchain address, a digital token, and an event identifier. The blockchain address can be generated using any suitable method and can be generated, for example, via a public key associated with the entity (e.g., in an encryption key pair associated therewith) or using a predetermined algorithm. The event identifier can be a value indicating the event to which the resulting blockchain entry corresponds. For example, the event identifier can be "published", "sent", "received", "aggregated", "decomposed", or "consumed".

[0029] Once the data packet is generated, the entity may digitally sign the data packet using the private key of the cryptographic key pair associated with the entity. The digital signature may be generated using any suitable algorithm using the private key, wherein the resulting signature may be verified using the corresponding public key of the cryptographic key pair. The entity may also generate an entry value for the event, wherein the entry value is generated by hashing a combination of an event identifier and a digital token of the product. The entry value, digital signature, and address may then each be transmitted to a blockchain node 104 in the blockchain network 102 as a submission of the event for the product. The data may then be included in a new blockchain data value, which is included in a new block, which is confirmed by a plurality of blockchain nodes 104, and then distributed to all blockchain nodes 104 in the blockchain network 1024 and added to the blockchain.

[0030] Each event for a product added to the blockchain can be verified by other entities involved in the system 100. For example, the manufacturer 106 can use the blockchain to submit a publishing event for the manufacture of a product to the blockchain. The user 114 may be interested in determining whether the product they find for sale at the merchant 110 is the manufacturer's genuine product and not a fake. The user 114 can use their user device 112 to read the product identifier from the product. The user device 112 can be any computing device (such as a computer) that is specifically programmed to perform the functions discussed herein. Figure 2 and Figure 5 The user 114 may then generate a digital token for the product via the user device 112 by hashing the product identifier and then using the combination of the “publish” event identifier and the digital token to generate an entry value. The user device 112 may check the blockchain available from the blockchain network 1024 to identify a blockchain data value including the entry value it generated. If no such entry value exists, the product may not be authentic because the manufacturer 106 has not or has not submitted a publication event for the product with the read product identifier, which may indicate that the product is fake. The user 114 may then refrain from purchasing the product.

[0031] If a blockchain data value including an entry value is found, the user 114 may attempt to verify the digital signature included in the blockchain data value using the manufacturer's public key from their cryptographic key pair. For example, the manufacturer 106 may make their public key available (e.g., on their website, through an application, etc.) to help the user 114 verify their products. The user 114 may use the public key to attempt to verify the digital signature. If the verification is successful, it may be discovered that the release event for the product was submitted by the manufacturer, so that the user 114 may discover that the product is genuine. If the verification is unsuccessful, the release event may have been submitted by a different entity other than the manufacturer 106, and thus may be considered untrustworthy to the user 114. The user 114 may then avoid purchasing the product.

[0032] In the case where multiple entities may be involved in an event, a confirmation value may be used in place of an entry value and a digital token in a data packet. This may include, for example, sending a product from a manufacturer 106 to a distributor 108 for distribution, or sending a product from a distributor 108 to a merchant 110 for sale, or receiving a product. In these cases, a combination of a digital token, a public key associated with other entities involved (e.g., the recipient of a "send" event), and a confirmation key may be used to generate a confirmation value. A suitable key derivation algorithm (such as a hash-based message authentication code (HMAC) key derivation function (KDF) called "HDKF") may be used to generate the confirmation key. The confirmation key may be derived from a combination of a digital token and a shared secret shared between two entities. In an exemplary embodiment, a private key of the submitting entity (e.g., the sender in a "send" event) and a public key of the entity involved (e.g., the recipient in a "send" event) may be used to generate a shared secret using a suitable algorithm (e.g., Elliptic-curve Diffie-Hellman (ECDH) key agreement protocol). The resulting confirmation value can then be used to replace the digital token in the data packet for which the digital signature was generated, and to replace the digital token in the entry value included in the blockchain data value.

[0033] The digital signature in the blockchain data value using a confirmation value instead of a digital token can still be verified by any interested entity using the public key of the entity that submitted the event entry. However, due to the use of shared secrets, the confirmation value used in the entry can only be verified by the entity involved or any party explicitly authorized thereby. For example, in the above example, the dealer 108 as the sender can use their private key and the public key of the merchant 110 as the recipient to generate a shared secret for generating a confirmation key as part of the confirmation value. Only the dealer 108, the merchant 110, or an authorized third party (such as an auditor) can generate a shared secret combined with a digital token to be able to generate its own version of the entry value in the blockchain data value for its verification.

[0034] An aggregation event for a product may involve aggregating multiple products together into a single unit for use in distribution (such as to simplify the logistical process of transferring product possession). For example, it may be time consuming and difficult for a distributor 108 to manually scan thousands of products (e.g., due to packaging and volume). Instead, products may be aggregated into a single pallet that is secured and assigned a single value for sending and receiving in the form of a product identifier. However, it may be desirable to track the aggregation of products in a package, such as to ensure complete capture of the origin of each product, and auditability in the event that a product in a package is lost during the process. For aggregation, an entity may generate a list of each digital token for all products in the package, where a single value generated from the list may be used as a product identifier for the package. For example, in an exemplary embodiment, a Merkle tree may be generated using the digital tokens, where the root of the Merkle tree may be used as a product identifier for the aggregated package. For an "aggregation" event, a blockchain data value may be added to the blockchain, where the entry value and data package utilize the Merkle root as its product identifier. For decomposition, the same product identifier may be used with the "decomposition" event, with any subsequent transfer of each product identified using its individual digital token.

[0035] For aggregate or decompose events, an entity may be able to audit to ensure the transfer of all products by using a Merkle root. For example, a manufacturer 106 may publish a dozen products on the blockchain and aggregate these dozen products into a single package. The package may be given to a distributor 108, where the manufacturer 106 submits a "send" event with the token of the package and the distributor 108 may submit a "receive" event with the same token of the package. The distributor 108 may then ship the package to the merchant 110 for delivery. The distributor 108 may submit its own "send" event to the merchant 110. The merchant 110 may scan each product in the received package to generate its Merkle root for its own submission of the "receive" event for the package. The merchant 110 may find that the Merkle root it generated is different from the identifier used in the "send" event submitted by the distributor 108. The merchant 110 may thereby realize that one of the products in the package is missing. Due to the events submitted during the logistics process, the entity may be able to identify that the package was lost at some point in the delivery process due to the use of the correct Merkle root during the publication, aggregation, and previous send and receive events. Therefore, as a result of the provenance of each product and package being captured, the entity may be able to accurately identify which product was lost and when.

[0036] In some embodiments, additional events about product manufacturing can be used to provide additional information about the creation and manufacture of products. For example, for shoes, the source of each ingredient used in the shoes can also be tracked in the blockchain, such as enabling users 114 to ensure that the leather purchased for the shoes is provided by ethical leather producers, wherein the transfer of leather from suppliers to manufacturers 106 and its use can be verified in the blockchain using the methods discussed herein. Similarly, the life cycle of consumable food can also be tracked (such as providing assistance in the case where the food may be contaminated or other problems are found). For example, if beef is found to be contaminated, it can be traced back to the original farm through the blockchain, where other contaminated beef can be found, and the merchant 110 that received the contaminated beef can be quickly and easily identified to ensure that the contaminated product is removed from the shelf and the user 114 who purchased the contaminated beef is notified more quickly and easily. The result is faster, more accurate, and more efficient tracking of the source of all types of products.

[0037] Thus, the methods and systems discussed herein enable each entity involved in the system 100, as well as any other interested party, to view and verify the origin of a product. Due to the use of digital tokens, digital signatures, and hashes, no information about the product itself or the entities involved is made publicly available, including any product tokens, let alone product identifiers. Thus, the anonymity of each entity is protected and the ability for bad actors to submit false information is minimized. The result is a system in which information about the origin of products in a supply chain is cryptographically accurate and publicly available without compromising the anonymity of the products and entities involved.

[0038] Computing System

[0039] Figure 2 An embodiment of a computing system 200 is described. It will be apparent to those skilled in the relevant art that Figure 2 The embodiments of the computing system 200 described in the present disclosure are provided for illustration only and may not be exhaustive of all possible configurations of the computing system 200 suitable for performing the functions discussed herein. For example, Figure 5 The computer system 500 illustrated and discussed in more detail below may be a suitable configuration for the computing system 200. In some cases, each blockchain node 104, manufacturer 106, distributor 108, merchant 110, or user device 112 in the system 100 may be configured similarly to Figure 2 The computing system 200 or Figure 5 A computer system 500 in (such as including the components described therein).

[0040] The computing system 200 may include a receiving device 202. The receiving device 202 may be configured to receive data on one or more networks via one or more network protocols. In some cases, the receiving device 202 may be configured to receive data from the blockchain node 104, the manufacturer 106, the distributor 108, the merchant 110, the user device 112, and other systems and entities via one or more communication methods (such as radio frequency, local area network, wide area network, cellular communication network, Bluetooth, Internet, etc.). In some embodiments, the receiving device 202 may include multiple devices (such as different receiving devices for receiving data via different networks (such as a first receiving device for receiving data via a local area network and a second receiving device for receiving data via the Internet)). The receiving device 202 may receive an electronically transmitted data signal, wherein the data may be superimposed or otherwise encoded on the data signal, and the reception of the data signal may be decoded, parsed, read, or otherwise obtained via the receiving device 202. In some instances, the receiving device 202 may include a parsing module for parsing the received data signal to obtain the data superimposed thereon. For example, receiving device 202 may include a parser program configured to receive received data signals and convert them into usable input for functions performed by the processing device to perform the methods and systems described herein.

[0041] The receiving device 202 may be configured to receive data signals electronically transmitted by the manufacturer 106, the distributor 108, the merchant 110, the user device 112, and other computing systems, which data signals may be superimposed or otherwise encoded with data included in the blockchain data value (such as addresses, entry values, and digital signatures). In some cases, the data signals received from such computing systems may be superimposed or otherwise encoded with requests for blockchain data values ​​(such as may generally include requests for blockchain data or requests for specific entry values ​​for which blockchain data values ​​are requested). The receiving device 202 may also be configured to receive data signals electronically transmitted by the blockchain node 104, such as these data signals may be superimposed or otherwise encoded with blockchain data values, new blocks for confirmation, confirmations of blocks, confirmed blocks, and other data as discussed herein.

[0042] The computing system 200 may also include a communication module 204. The communication module 204 may be configured to transmit data between modules, engines, databases, memories, and other components of the computing system 200 for performing the functions discussed herein. The communication module 204 may include one or more communication types and utilize various communication methods for communication within the computing device. For example, the communication module 204 may include a bus, a pin connector, wires, etc. In some embodiments, the communication module 204 may also be configured to communicate between internal components of the computing system 200 and external components of the computing system 200 (such as externally connected databases, display devices, input devices 206, etc.). The computing system 200 may also include a processing device. The processing device may be specifically configured to perform the functions of the computing system 200 discussed herein, which is obvious to those skilled in the relevant art based on this specification. In some embodiments, the processing device may include and / or be composed of multiple engines and / or modules, which are specifically configured to perform one or more functions of the processing device (such as a query module 214, a generation module 216, a verification module 218, etc.). As used herein, the term "module" can be software compiled on hardware, or otherwise specifically programmed hardware to receive input, perform one or more processes using the input, and provide output. Based on this disclosure, the input, output, and processing performed by the various modules will be apparent to those skilled in the art.

[0043] The computing system 200 may also include or otherwise interface with one or more input devices 206. The input device 206 may be internal to the computing system 200 or external to the computing system 200 and connected thereto via one or more connections (e.g., wired or wireless) for transmitting data to and / or from it. The input device 206 may be configured to receive input from a user of the computing system 200, which may be provided to another module or engine of the computing system 200 (e.g., via the communication module 204) for processing accordingly. The input device 206 may include any type of input device (such as a keyboard, mouse, click wheel, scroll wheel, microphone, touch screen, track pad, camera, optical imager, etc.) suitable for receiving input to perform the functions discussed herein. The input device 206 may be configured to, for example, receive a product identifier associated with a product (such as may be read by an optical imager, manually entered by a user, received via near field communication, etc.).

[0044] The computing system 200 may also include a memory 208. The memory 208 may be configured to store data (such as public and private keys, symmetric keys, etc.) used by the computing system 200 when performing the functions discussed herein. The memory 208 may be configured to store data using a suitable data formatting method and mode and may be any suitable type of memory (such as read-only memory, random access memory, etc.). The memory 208 may include, for example, encryption keys and algorithms, communication protocols and standards, data formatting standards and protocols, program code for modules and applications of processing devices, and other data that may be suitable for the computing system 200 to use when performing the functions disclosed herein. In some embodiments, the memory 208 may include or may otherwise include a relational database that utilizes a structured query language for storage, identification, modification, updating, access, etc. of structured data sets stored therein. The memory 208 may be configured to store, for example, encryption keys, salts, random numbers, communication information, etc. for backend systems.

[0045] The memory 208 may be configured to store algorithms for generating derived keys, shared secrets, digital signatures, hash values, blocks, and verification of these data. If applicable, the memory 208 may also be configured to store keys of cryptographic key pairs including private keys and public keys. The memory 208 may also be configured to store blockchains or data associated therewith.

[0046] The computing system 200 may include a query module 214. The query module 214 may be configured to perform queries on a database to identify information. The query module 214 may receive one or more data values ​​or query strings and based thereon execute the query string on an indicated database (such as the memory 208 of the computing system 200) to identify information stored therein. The query module 214 may then output the identified information to an appropriate engine or module of the computing system 200 as needed. The query module 214 may, for example, perform queries on the memory 208 to identify a hash algorithm used to generate a digital token, identify a private key used to digitally sign a data packet, identify a public key used to verify a digital signature, and the like.

[0047] The computing system 200 may also include a generation module 216. The generation module 216 may be configured to generate data for use by the computing system 200 in performing the functions discussed herein. The generation module 216 may receive instructions as input, may generate data based on the instructions, and may output the generated data to one or more modules of the computing system 200. For example, as discussed herein, the generation module 216 may be configured to generate a digital token, a data packet, a confirmation value, a derived key, a shared secret, a digital signature, a blockchain data value, a block header, a block, a Merkle tree, a block reference value, a data reference value, or any other data as also discussed herein by using data, appropriate keys, algorithms, etc.

[0048] The computing system 200 may also include a verification module 218. The verification module 218 may be configured to perform verification of the computing system 200 to verify the data discussed herein. The verification module 218 may receive as input an instruction, which may also be accompanied by data to be used in the verification or for verification, may perform the verification in accordance with the instruction, and may output the result of the verification to another module or engine of the computing system 200. The verification module 218 may be configured, for example, to verify a digital signature, verify an entry value, verify a digital token or confirmation value, verify a Merkle root, or perform other checks or verifications as discussed herein.

[0049] The computing system 200 may also include a transmission device 224. The transmission device 224 may be configured to transmit data on one or more networks via one or more network protocols. In some cases, the transmission device 224 may be configured to transmit data to the blockchain node 104, the manufacturer 106, the dealer 108, the merchant 100, the user device 112, and other entities via one or more communication methods, local area network, wireless local area network, cellular communication, Bluetooth, radio frequency, the Internet, etc. In some embodiments, the transmission device 224 may include multiple devices, such as different transmission devices for transmitting data on different networks (such as a first transmission device for transmitting data on a local area network and a second transmission device for transmitting data via the Internet). The transmission device 224 may electronically transmit a data signal with data superimposed that can be parsed by a receiving computing device. In some cases, the transmission device 224 may include one or more modules for superimposing, encoding, or otherwise formatting data into a data signal suitable for transmission.

[0050] The transmission device 224 may be configured to electronically transmit a data signal to the blockchain node 104, which may be superimposed or otherwise encoded with data to be included in the blockchain data value (e.g., an address, an entry value, and a digital signature). In some cases, the data signal electronically transmitted to the blockchain node 104 may be superimposed or otherwise encoded with a request for a blockchain data value (such as may generally include a request for blockchain data or a request for a specific entry value for which the blockchain data value is requested). The transmission device 224 may also be configured to electronically transmit the data signal to the manufacturer 106, the distributor 108, the merchant 100, the user device 112, etc., such as the data signal may be superimposed or otherwise encoded with a blockchain data value, a new block for confirmation, a confirmation for a block, a confirmed block, and other data discussed herein.

[0051] The process of capturing product provenance via blockchain

[0052] Figure 3 An example process 300 performed in the system 100 is illustrated for capturing the provenance of a manufactured and distributed product for sale via blockchain using the digital tokens and events discussed above.

[0053] In step 302, the manufacturer 106 may manufacture a product that will be available for sale, and as part of the manufacturing, may assign a product identifier to the product and submit a "publish" event for the product. The submission of the "publish" event may include the generation of a digital token, a new address, a data packet, a digital signature, an entry value, and the submission of data of the blockchain data value to the blockchain node 104 in the blockchain network 102. The code utilized by the manufacturer 106 for the "publish" event may include the following:

[0054] create(VALUE);

[0055] TOKEN = HASH(VALUE);

[0056] EVENT = "ISSUE";

[0057] ADDRESS == new Address();

[0058] SIGNATURE=SIGN({“ISSUE”+ADDRESS+TOKEN},ISSUER_PRIVATE);

[0059] CHAIN_ENTRY={ADDRESS,HASH(“ISSUE+TOKEN),SIGNATURE};

[0060] Where the "ISSUE" event and the hash of the digital token may be the entry value, and ISSUER_PRIVATE may indicate the use of the manufacturer's private key for the digital signature. The manufacturer 106 may repeat step 302 for the manufacture and release of multiple products, each product having its own unique product identifier and subsequent digital token. In step 304, the manufacturer 106 (or the distributor 108 depending on the product type) may aggregate the manufactured products into a single package (such as by packaging the products together into a single packaging pallet for shipping). As part of the aggregation, the manufacturer 106 may submit an "aggregate" event to the blockchain node 104 in the blockchain network 1024, using the root of the Merkle tree of all product identifiers of the products included in the package. The code utilized by the manufacturer 106 for the "aggregate" event may include the following:

[0061] PACKAGE_TOKEN=MERKLE_ROOT(list(TOKEN));

[0062] SIGNATURE=SIGN({“AGGREGATE”+ADDRESS+PACKAGE_TOKEN},AGGREGATOR_PRIVATE);

[0063] CHAIN_ENTRY={ADDRESS,HASH(“AGGREGATE”+PACKAG E_TOKEN),SIGNATURE};

[0064] Where AGGREGATOR_PRIVATE can indicate the use of the manufacturer's private key for generating a digital signature. Once aggregation is performed, in step 306, the merchant 1104 can submit a "Send" entry for the package to indicate that the package is sent to the distributor 108 for transportation and distribution to the merchant 110. In some embodiments, a single "Send" entry can be submitted for the package. In other embodiments, the manufacturer 106 can submit a separate "Send" entry for each product, where the package can be mentioned only in the "Aggregation" and "Decomposition" events. The code used by the manufacturer 106 for the "Send" event may include the following:

[0065] SENDER_CONFIRMATION={TOKEN+RECEIVER_PUBLIC+H KDF(TOKEN+ECDH(RECEIVER_PUBLIC,SENDER_PRIVATE))};

[0066] SIGNATURE=SIGN({"SEND"+ADDRESS+SENDER_CONFIRM ATION},SENDER_PRIVATE);

[0067] CHAIN_ENTRY={ADDRESS,HASH(“SEND”+SENDER_CONFI RMATION),SIGNATURE};

[0068] Where RECEIVER_PUBLIC can be the public key of the distributor 108, SENDER_PRIVATE can be the private key of the manufacturer 106, TOKEN can be a digital token if a product is being sent, or a package token if the "send" event is for an entire package, HKDF can indicate the derivation of the confirmation key, and ECDH can be used for the generation of a shared secret. In step 308, the distributor 108 can obtain the product package from the manufacturer 106 for transportation to the merchant 110 for final sale.

[0069] Once the distributor 108 receives the package, they may submit their own "receive" step regarding receipt of the product package from the manufacturer 106 at step 310. As with the "send" event, a "receive" event may be a single receipt of a package of multiple products, or receipt of a package may require the submission of a "receive" event for each product included therein. The code that the distributor 108 may utilize for the "receive" event may include the following:

[0070] RECEIVER_CONFIRMATION={TOKEN+SENDER_PUBLIC+H KDF(TOKEN+ECDH(SENDER_PUBLIC,RECEIVER_PRIVATE))};

[0071] SIGNATURE=SIGN({“RECEIVE”+ADDRESS+RECEIVER_CONFIRMATION},RECEIVER_PRIVATE);

[0072] CHAIN_ENTRY={ADDRESS,HASH(“RECEIVE”+RECIVER_C ONFIRMATION),SIGNATURE};

[0073] Where SENDER_PUBLIC may be the public key of the manufacturer 106, RECEIVER_PRIVATE may be the private key of the distributor 108, TOKEN may be a digital token for a product or a package token for a package, HKDF may be used to confirm the derivation of the key, and ECHD may indicate the generation of a shared secret. The distributor 108 may then use its logistics system to transport the product package to the merchant 110. In some cases, the distributor 108 may add new "send" and "receive" events at each step of its logistics system (e.g., handover from one employee, vehicle, etc. to another employee, vehicle, etc.) (such as for more complete information about where the product and / or package is located, such as for greater auditability and detection if the product is lost). Once the distributor 108 completes its shipping process and is ready to deliver the package to the merchant 110, the distributor 108 may submit a final "send" event for sending the package to the merchant 110 in step 312. The distributor 108 may use the same code as the "send" event indicated above for step 306, where the distributor 108 may be the sender and the merchant 110 may be the receiver.

[0074] In step 314, the merchant 110 may take possession of the package. To indicate receipt of the package, the merchant 110 may submit its own "receive" event to the blockchain node 104 in the blockchain network 1024 in step 316. The merchant 110 may utilize the code indicated above for the "receive" event in step 310, where the distributor 108 may be the sender and the merchant 110 may be the receiver. Once the package is received and an indication of it is recorded in the blockchain, the merchant 110 (or distributor 108, depending on the product type) may decompose the package into its component products in step 318. As part of the decomposition, the merchant 110 may submit a "decomposition" event to the blockchain, where the code utilized by the merchant 110 may include the following:

[0075] PACKAGE_TOKEN=MERKLE_ROOT(list(TOKEN));

[0076] SIGNATURE=SIGN({“DISAGGREGATE+ADDRESS+PACKAG E_TOKEN},VENDOR_PRIVATE);

[0077] CHAIN_ENTRY={ADDRESS,HASH(“DISAGGREGATE”+PAC KAGE_TOKEN),SIGNATURE};

[0078] Wherein VENDOR_PRIVATE can indicate the use of the merchant's private key. The merchant 110 can then break down each individual product and make it available for sale to consumers. In step 320, the user 114 can approach the merchant 110 and purchase one of the products. In some embodiments, the transfer to the user 114 can be represented by the submission of a "send" event by the merchant 110, with the user's user device 112 as the recipient of the event. In some such embodiments, the user device 112 can submit its own "receive" event. In other embodiments, a "consumption" event may be submitted to the blockchain by the merchant 110 to indicate that the product has been "consumed" or purchased by the end user for its use, where tracking may no longer be available. In this case, the code utilized by the merchant 110 for the "consumption" event may include the following:

[0079] SIGNATURE=SIGN({“CONSUME”+ADDRESS+TOKEN),VEND OR_PRIVATE};

[0080] CHAIN_ENTRY={ADDRESS,HASH(“CONSUME”+TOKEN),SI GNATURE};

[0081] Where VENDOR_PRIVATE may refer to the use of the merchant's private key when digitally signing the data packet. The result of process 300 is a complete source of the product from manufacturing to the final purchase by user 114, where each involved entity may be able to check the source during each step of the process. For example, an auditor may be able to ensure that the product has never been in the hands of an unauthorized party and is therefore authentic when it is available for purchase at merchant 110. Likewise, user 114 may be able to check that the product they purchased is authentic from manufacturer 106.

[0082] Example Methods for Communicating Auditable Provenance Information

[0083] Figure 4 A method 400 is described for conveying auditable information about the provenance of a product that is cryptographically accurate while maintaining complete anonymity of the product and participants on a blockchain in certain embodiments.

[0084] In step 402, a product identifier may be received by an input device (e.g., input device 206) interfaced with a computing device (e.g., computing system 200). In step 404, a processor of the computing device (e.g., generation module 216) may generate a digital token by applying a hash algorithm to the product identifier. In step 406, the processor of the computing device may generate an entry value by applying a hash algorithm to a combination of the event identifier and the digital token.

[0085] In step 408, the processor of the computing device may generate a digital signature by digitally signing the data packet using the private key of the cryptographic key pair, wherein the data packet includes at least the blockchain address, the event identifier, and the digital token. In step 410, the blockchain address, the digital signature, and the entry value may be sent by a transmitter of the computing device (e.g., the transmission device 224) to a blockchain network (e.g., the blockchain network 102).

[0086] In some embodiments, method 400 may also include generating, by a processor of the computing device, a confirmation key by applying a key derivation algorithm to a combination of the digital token and the shared secret value, wherein the confirmation package includes the digital token, the secondary public key, and the confirmation key, and the confirmation package is included in the entry value and the data packet instead of the digital token. In further embodiments, the event identifier may indicate the sending of a product associated with the product identifier and the secondary public key may be associated with a recipient entity of the product.

[0087] In one embodiment, method 400 may also include: receiving, by a node in the blockchain network, a blockchain address, a digital signature, and an entry value from a computing device; generating, by a node in the blockchain network, a new block including a block header and one or more blockchain data values, the one or more blockchain data values ​​including a new blockchain data value, the blockchain data value including the blockchain address, the digital signature, and the entry value; transmitting, by a node in the blockchain network, the generated new block to a plurality of additional nodes in the blockchain network. In some embodiments, method 400 may also include verifying, by a node in the blockchain network, the digital signature using a public key of a cryptographic key pair.

[0088] In one embodiment, method 400 may also include: receiving, by the second computing system, the digital signature; and verifying, by the second computing system, the digital signature using a public key of the cryptographic key pair. In some embodiments, method 400 may also include: receiving, by the second computing system, the entry value; receiving, by the second computing system, the product identifier; generating, by the second computing system, a comparison hash value by applying a hash algorithm to the received product identifier; and verifying, by the second computing system, the received entry value by comparing it to the generated comparison hash value.

[0089] In one embodiment, method 400 may also include: receiving multiple additional identifiers by an input device interfaced with a computing device; generating, by a processor of the computing device, an additional token for each of the multiple additional identifiers by applying a hash algorithm to the corresponding additional identifiers; identifying, by the processor of the computing device, a package token by generating a Merkle tree using the product identifier and the multiple additional identifiers, wherein the package token is a root value of the Merkle tree, the package token is included in a data packet and is used for an entry value instead of a digital token.

[0090] Computer system architecture

[0091] Figure 5 A computer system 500 is illustrated in which embodiments of the present disclosure or portions thereof may be implemented as computer readable code. For example, Figure 1 Blockchain nodes 104, manufacturers 106, distributors 108, merchants 110 and user devices 112 and Figure 2 The computing system 200 of the embodiment of the present invention may be implemented in the computer system 500 using hardware, software compiled on the hardware, firmware, a non-transitory computer-readable medium having instructions stored thereon, or a combination thereof, and may be implemented in one or more computer systems or other processing systems. Specially configured hardware, software, firmware, memory, or any suitable combination thereof may be embodied for implementing the present invention. Figure 3 and Figure 4 Modules and components of the method.

[0092] If programmable logic is used, such logic can be executed on a commercial processing platform configured by executable software code to become a special-purpose computer or special-purpose device (e.g., a programmable logic array, an application-specific integrated circuit, etc.). It will be appreciated by those skilled in the art that embodiments of the disclosed subject matter can be used to practice various computer system configurations, including multi-core multi-processor systems, minicomputers, mainframe computers, linked or clustered computers with distributed functions, and microcomputers that are ubiquitous or can be embedded in almost any device. For example, the above embodiments can be implemented using at least one processor device and a memory.

[0093] The processor unit or device as discussed herein may be a single processor, multiple processors, or a combination thereof. A processor device may have one or more processor "cores." The terms "computer program medium," "non-transitory computer-readable medium," and "computer-usable medium" as discussed herein are generally used to refer to tangible media (such as removable storage unit 518, removable storage unit 522, and a hard disk installed in hard disk drive 512).

[0094] Various embodiments of the present disclosure are described based on this example computer system 500. After reading this specification, it will be clear to those skilled in the relevant art how to implement the present disclosure using other computer systems and / or computer architectures. Although operations may be described as sequential processes, some operations may actually be performed in parallel, concurrently, and / or in a distributed environment, and have program code stored locally or remotely for access by a single processor or a multi-processor machine. In addition, in some embodiments, the order of operations may be rearranged without departing from the spirit of the disclosed subject matter.

[0095] Processor device 504 can be a dedicated or general processor device specially configured to perform the functions discussed herein. Processor device 504 can be connected to communication infrastructure 506 (such as bus, message queue, network, multi-core message passing scheme, etc.). Network can be any network suitable for performing functions disclosed herein and can include local area network (LAN), wide area network (WAN), wireless network (such as WiFi), mobile communication network, satellite network, Internet, optical fiber, coaxial cable, infrared, radio frequency (RF), or any combination thereof. Other suitable network types and configurations will be apparent to those skilled in the art. Computer system 500 can also include main memory 508 (for example, random access memory, read-only memory, etc.), and can also include auxiliary memory 510. Auxiliary memory 510 can include hard disk drive 512 and removable storage drive 514 (such as floppy disk drive, tape drive, optical disk drive, flash memory, etc.).

[0096] Removable storage drive 514 can read from and / or write to removable storage unit 518 in a well-known manner. Removable storage unit 518 may include a removable storage medium that can be read and written by removable storage drive 514. For example, if removable storage drive 514 is a floppy disk drive or a universal serial bus port, removable storage unit 518 may be a floppy disk or a portable flash drive, respectively. In one embodiment, removable storage unit 518 may be a non-transitory computer-readable recording medium.

[0097] In some embodiments, secondary memory 510 may include alternative means (such as a removable storage unit 522 and interface 520) for allowing computer programs or other instructions to be loaded into computer system 500. Examples of such means may include a program cartridge and cartridge interface (e.g., as found in a video game system), a removable storage chip (e.g., EEPROM, PROM, etc.) and associated slot, as well as other removable storage units 522 and interfaces 520, as will be apparent to those skilled in the relevant art(s).

[0098] Data stored in computer system 500 (e.g., in primary memory 508 and / or secondary memory 510) may be stored on any type of suitable computer-readable medium, such as optical storage (e.g., compact disk, digital versatile disk, Blu-ray disk, etc.) or magnetic tape storage (e.g., hard drive). The data may be configured in any type of suitable database configuration (such as a relational database, a structured query language (SQL) database, a distributed database, an object database, etc.). Suitable configurations and storage types will be apparent to those skilled in the relevant art.

[0099] The computer system 500 may also include a communication interface 524. The communication interface 524 may be configured to allow software and data to be transferred between the computer system 500 and external devices. Exemplary communication interfaces 524 may include a modem, a network interface (e.g., an Ethernet card), a communication port, a PCMCIA slot and card, etc. The software and data transmitted via the communication interface 524 may be in the form of signals, which may be electronic, electromagnetic, optical, or other signals apparent to those skilled in the relevant art. The signals may be propagated via a communication path 526, which may be configured to carry the signals and may be implemented using wires, cables, optical fibers, telephone lines, cellular phone links, radio frequency links, etc.

[0100] The computer system 500 may also include a display interface 502. The display interface 502 may be configured to allow data to be transferred between the computer system 500 and an external display 530. Exemplary display interfaces 502 may include a high-definition multimedia interface (HDMI), a digital visual interface (DVI), a video graphics array (VGA), etc. The display 530 may be any suitable type of display for displaying data transmitted via the display interface 502 of the computer system 500, including a cathode ray tube (CRT) display, a liquid crystal display (LCD), a light emitting diode (LED) display, a capacitive touch display, a thin film transistor (TFT) display, etc.

[0101] Computer program media and computer usable media may refer to memories (such as main memory 508 and secondary memory 510), which may be memory semiconductors (e.g., DRAM, etc.). These computer program products may be means for providing software to computer system 500. Computer programs (e.g., computer control logic) may be stored in main memory 508 and / or secondary memory 510. Computer programs may also be received via communication interface 524. Such computer programs, when executed, may enable computer system 500 to implement the present methods as discussed herein. In particular, the computer programs, when executed, may enable processor device 504 to implement the methods described herein. Figure 3 and Figure 4 Thus, such a computer program may represent a controller of the computer system 500. Where software is used to implement the present disclosure, the software may be stored in a computer program product and loaded into the computer system 500 using the removable storage drive 514, the interface 520, and the hard disk drive 512, or the communication interface 524.

[0102] The processor device 504 may include one or more modules or engines configured to perform the functions of the computer system 500. Each module or engine may be implemented using hardware, and in some cases, software (such as corresponding to program code and / or programs stored in the main memory 508 or the auxiliary memory 510) may also be used. In this case, the program code may be compiled by the processor device 504 (e.g., by a compiling module or engine) before being executed by the computer system 500 hardware. In this case, the program code may be compiled by the processor device 504 (e.g., by a compiling module or engine) before being executed by the hardware of the computer system 500. For example, the program code may be a source code written in a programming language that is translated into a lower-level language (such as an assembly language or machine code) for execution by the processor device 504 and / or any additional hardware components of the computer system 500. The compilation process may include the use of lexical analysis, preprocessing, parsing, semantic analysis, grammar-oriented translation, code generation, code optimization, and any other technology that may be suitable for translating the program code into a lower-level language suitable for controlling the computer system 500 to perform the functions disclosed herein. As will be apparent to one skilled in the relevant art, such a process results in the computer system 500 becoming a specifically configured computer system 500 that is uniquely programmed to perform the functions described above.

[0103] Among other features, technology consistent with the present disclosure provides systems and methods for conveying auditable information about the origin of a product that is cryptographically accurate while maintaining complete anonymity of the product and participants on the blockchain. Although various exemplary embodiments of the disclosed systems and methods have been described above, it should be understood that they are presented for illustrative purposes only and not by limitation. It is not exhaustive and does not limit the disclosure to the precise form disclosed. Modifications and variations are possible in light of the above teachings or may be obtained from the practice of the present disclosure without departing from the breadth or scope.

Claims

1. A method for communicating auditable information about the origin of a product, comprising: generating, by a processor of the computing device, a digital token by applying a hashing algorithm to the product identifier; generating, by a processor of the computing device, an entry value by applying a hashing algorithm to a combination of the event identifier and the digital token; generating, by a processor of the computing device, a digital signature by digitally signing a data packet using a private key of a cryptographic key pair, wherein the data packet includes at least a blockchain address, an event identifier, and a digital token; The blockchain address, the digital signature, and the entry value are transmitted by a transmitter of the computing device to a node in the blockchain network; and A validation key is generated by a processor of the computing device by applying a key derivation algorithm to a combination of the digital token and the shared secret value, wherein The confirmation package includes the digital token, the secondary public key and the confirmation key, and wherein the confirmation package is included in the entry value and the data packet instead of the digital token.

2. The method of claim 1, wherein: The event identifier indicates a delivery of a product associated with the product identifier, and the secondary public key is associated with a recipient entity of the product.

3. The method of claim 1, further comprising: Receiving, by a node in the blockchain network, a blockchain address, a digital signature, and an entry value from a computing device; generating, by a node in the blockchain network, a new block including a block header and one or more blockchain data values, the one or more blockchain data values ​​including a new blockchain data value, the new blockchain data value including a blockchain address, a digital signature, and an entry value; and The new blocks generated by the nodes in the blockchain network are transmitted to multiple additional nodes in the blockchain network.

4. The method of claim 1, further comprising: The digital signature is verified by nodes in the blockchain network using the public key of a cryptographic key pair.

5. The method of claim 1, further comprising: receiving, by a second computing system, a digital signature; The digital signature is verified by the second computing system using the public key of the encryption key pair.

6. The method of claim 1, further comprising: receiving, by a second computing system, an entry value; receiving, by a second computing system, a product identifier; generating, by the second computing system, a comparison hash value by applying a hash algorithm to the received product identifier; and The received entry value is verified by the second computing system by comparing the received entry value to the generated comparison hash value.

7. The method of claim 1, further comprising: receiving, by an input device interfaced with the computing device, a plurality of additional identifiers; generating, by a processor of the computing device, an additional token for each of the plurality of additional identifiers by applying a hashing algorithm to the corresponding additional identifier; and identifying, by a processor of the computing device, the package token by generating a Merkle tree using the product identifier and the plurality of additional identifiers, wherein the package token is a root value of the Merkle tree, and The packet token is included in the data packet and is used for the entry value instead of the numeric token.

8. A system for communicating auditable information about the origin of a product, comprising: A blockchain network consisting of multiple nodes; and The computing device includes a processor and a transmitter, wherein processor A digital token is generated by applying a hashing algorithm to a product identifier, Generate an entry value by applying a hashing algorithm to the combination of the event identifier and the digital token, and generating a digital signature by digitally signing a data packet using a private key of a cryptographic key pair, wherein the data packet includes at least a blockchain address, an event identifier, and a digital token, and The sender transmits the blockchain address, the digital signature, and the entry value to one of the plurality of nodes in the blockchain network, further wherein The processor of the computing device further generates a confirmation key by applying a key derivation algorithm to the combination of the digital token and the shared secret value, The confirmation package includes a digital token, a secondary public key, and a confirmation key, and The confirmation packet is included in the entry value and data packet instead of the digital token.

9. The system of claim 8, wherein: The event identifier indicates a delivery of a product associated with the product identifier, and the secondary public key is associated with a recipient entity of the product.

10. The system of claim 8, wherein one of the plurality of nodes in the blockchain network: receiving a blockchain address, a digital signature, and an entry value from a computing device; generating a new block including a block header and one or more blockchain data values, the one or more blockchain data values ​​including a new blockchain data value, the new blockchain data value including a blockchain address, a digital signature, and an entry value; and Transmit the generated new blocks to multiple additional blockchain nodes in the blockchain network.

11. The system of claim 8, wherein one of the plurality of nodes in the blockchain network verifies the digital signature using a public key of the cryptographic key pair.

12. The system of claim 8, further comprising: a second computing system, wherein the second computing system Receive a digital signature, and Use the public key of the cryptographic key pair to verify the digital signature.

13. The system of claim 8, further comprising: a second computing system, wherein the second computing system Receives the entry value, Receive a product identifier, generating a comparison hash value by applying a hashing algorithm to the received product identifier, and The received entry value is verified by comparing it to the generated comparison hash value.

14. The system of claim 8, wherein The input device interfaced with the computing device also receives a plurality of additional identifiers, The processor of the computing device further generating an additional token for each of the plurality of additional identifiers by applying a hashing algorithm to the corresponding additional identifier, and identifying a package token by generating a Merkle tree using the product identifier and the plurality of additional identifiers, where the package token is the root value of the Merkle tree, and The packet token is included in the data packet and is used for the entry value instead of the numeric token.

Images