A sustainable token for the supply chain that uses a confidentiality protocol

Abstract

A computer-implemented system and method provides a secure token generation protocol. The method includes initiating an order request, the order request including public order information and personal order information. The method further includes generating an address in a blockchain network, including encrypting the address using a private key, and generating a hash of data incorporating the personal order information and a signature of the hash. The signature of the hash is generated using the private key. The method further includes sending the order request, including the address, hash, and signature, to a transportation facility associated with the order and identifying that the transportation facility has fulfilled the order request. The method further includes validating that the transportation facility has fulfilled the order, calculating a token value associated with the transportation facility, where the token value is associated with the transportation facility's carbon footprint, and assigning the token value to the address.

Description

[Background technology]

[0001] Disclosed herein are systems and related methods for creating and utilizing sustainable tokens in a blockchain network for a supply chain based on the carbon footprint associated with the supply chain. The creation and utilization of sustainable tokens may be performed while protecting personal information that may be associated with the sustainable token. Environmentally conscious corporate goals are becoming increasingly important, and various methods for advancing such goals are currently being considered by many organizations. Summary of the Invention

[0002] According to one aspect disclosed herein, a computer-implemented method for a privacy-preserving token generation protocol is provided. The method includes initiating an order request, the order request including public order information and personal order information. The method further includes generating an address in a blockchain network including encrypting the address using a private key, and generating a hash of data incorporating the personal order information and a signature of the hash. The signature of the hash is generated using the private key. The method further includes sending the order request including the address, hash, and signature to a transportation facility associated with the order, and identifying the transportation facility as having fulfilled the order request.

[0003] According to another aspect disclosed herein, a computer-implemented method for a security token generation protocol is provided. The method includes receiving order information related to an order requiring the use of a transportation vehicle, the order information including an address in a blockchain network. The method further includes validating that the transportation vehicle has fulfilled the order, calculating a token value associated with the transportation vehicle, the token value being associated with a carbon footprint of the transportation vehicle for transporting the order, and assigning the token value to the address.

[0004] According to another aspect disclosed herein, a sustainable token system is provided. The system includes a manufacturer and a blockchain controller. The system is configured to receive, using a processor at the manufacturer, order information related to an order requiring the use of a transportation facility, the order information including an address in a blockchain network. The manufacturer's processor is further configured to validate that the transportation facility has fulfilled the order and calculate a token value associated with the transportation facility. The token value is related to the transportation facility's carbon footprint for transporting the order. The manufacturer's processor is further configured to assign the token value to the address. The system is configured to initiate an order request, the order request including public order information and personal order information; generate an address in the blockchain network including encrypting the address using a private key; and generate a hash of data incorporating the personal order information and a signature of the hash, using the processor at the blockchain controller. The signature of the hash is generated using the private key, and the controller's processor is configured to send the order request including the address, hash, and signature to the transportation facility, identifying that the transportation facility has fulfilled the order request.

[0005] Furthermore, embodiments may take the form of an associated computer program product accessible from a computer-usable or computer-readable medium that provides program code for use by or in connection with a computer or any instruction execution system. For purposes of this description, a computer-usable or computer-readable medium may be any apparatus that can include a mechanism for storing, communicating, propagating, or carrying a program for use by or in connection with an instruction execution system, instruction execution apparatus, or instruction execution device.

[0006] Various embodiments are described herein with reference to different subject matter. In particular, some embodiments may be described with reference to methods, while other embodiments may be described with reference to devices and systems. However, those skilled in the art will infer from the foregoing and following descriptions that, unless otherwise noted, any combination of features belonging to one type of subject matter, as well as any combination between features relating to different subject matters, particularly between method features and device and system features, is considered to be disclosed within this document.

[0007] The above-defined aspects and other aspects disclosed herein will be apparent from and will be explained with reference to one or more example embodiments set forth hereinafter, without the invention being limited thereto.Various embodiments are illustrated, by way of example only, with reference to the following drawings, in which: [Brief explanation of the drawings]

[0008] [Figure 1A] 1 is a block diagram of a data processing system (DPS) in accordance with one or more embodiments disclosed herein. [Figure 1B] FIG. 1 illustrates a cloud computing environment in accordance with embodiments disclosed herein. [Figure 1C]FIG. 1 illustrates an abstract model layer according to embodiments disclosed herein. [Figure 2A] FIG. 1 is a block diagram illustrating an exemplary blockchain architecture configuration, according to an example embodiment. [Figure 2B] FIG. 1 is a flow diagram illustrating a blockchain transaction flow, according to an example embodiment. [Figure 3A] 1 is a block diagram illustrating a permissioned network, according to an example embodiment. [Figure 3B] FIG. 2 is a block diagram illustrating another permissioned network, according to an example embodiment. [Figure 3C] 1 is a block diagram illustrating a permission-less network, according to an example embodiment. [Figure 4] A block diagram showing a basic blockchain sequence. [Figure 5A] 1 is a block diagram illustrating an example system configured to perform one or more operations described herein, according to an example embodiment. [Figure 5B] FIG. 1 is a block diagram illustrating another exemplary system configured to perform one or more operations described herein, according to an example embodiment. [Figure 5C] FIG. 10 is a block diagram illustrating a further exemplary system configured to utilize smart contracts, in accordance with an example embodiment. [Figure 5D] FIG. 1 is a block diagram illustrating yet another exemplary system configured to utilize blockchain, according to an example embodiment. [Figure 6A] FIG. 1 is a block diagram illustrating the process of a new block being added to a distributed ledger according to an example embodiment. [Figure 6B] FIG. 10 is a block diagram illustrating the contents of a new data block, according to an example embodiment. [Figure 6C] FIG. 1 is a block diagram illustrating a blockchain for digital content, according to an example embodiment. [Figure 6D]FIG. 2 is a block diagram illustrating a block that may represent the structure of a block in a blockchain, according to an example embodiment. [Figure 7A] FIG. 1 is a block diagram illustrating an exemplary blockchain for storing machine learning (artificial intelligence) data, according to an example embodiment. [Figure 7B] FIG. 1 is a block diagram illustrating an exemplary quantum-secure blockchain, according to an example embodiment. [Figure 8] FIG. 1 is a block diagram illustrating a high-level block diagram of an exemplary computer system that may be used in implementing one or more of the methods, tools, and modules, and any associated functionality, described herein, in accordance with embodiments of the present disclosure. [Figure 9] FIG. 1 is a block diagram illustrating major components associated with a sustainable token for supply chains, according to some embodiments. [Figure 10] FIG. 1 is a flowchart diagram illustrating major components associated with a sustainable token for supply chains, according to some embodiments. DETAILED DESCRIPTION OF THE INVENTION

[0009] Sustainable Token Overview To encourage reductions in the carbon footprint associated with the transportation of goods within a supply chain network, it may be advantageous to reward entities that directly reduce carbon footprints, or use the services of entities that can help achieve this goal, or both.

[0010] Disclosed herein are systems and related methods that can utilize a blockchain ledger to offer sustainable tokens as rewards for improving carbon emissions beyond a certain threshold. The sustainable tokens may be exchanged for other forms of money, both virtual and real. The transactions allow personal information that may be used in the transactions to remain confidential.

[0011] The following abbreviations may be used below:

[0012] [Table 1]

[0013] General Data Processing System 1A is a block diagram of an exemplary DPS according to one or more embodiments. In this example, DPS 10 may include a communication bus 12 that may provide communication between a processor unit 14, memory 16, persistent storage 18, a communication unit 20, an I / O unit 22, and a display 24.

[0014] Processor unit 14 serves to execute instructions of software that may be loaded into memory 16. Processor unit 14 may be multiple processors, a multi-core processor, or other types of processors, depending on the particular implementation. "Multiple," when used herein with reference to an item, means one or more items. Additionally, processor unit 14 may be implemented using a multiple heterogeneous processor system in which a main processor resides on a single chip along with secondary processors. As another example, processor unit 14 may be a symmetric multiprocessor system containing multiple processors of the same type.

[0015] Memory 16 and persistent storage 18 are examples of storage devices 26. A storage device may be any piece of hardware that can store information, such as, but not limited to, data, program code in a functional form, or other suitable information, or a combination thereof, on a temporary or persistent basis. In these examples, memory 16 may be, for example, random access memory or any other suitable volatile or non-volatile storage device. Persistent storage 18 may take various forms, depending on the particular implementation.

[0016] For example, persistent storage 18 may include one or more components or devices. For example, persistent storage 18 may be a hard drive, a flash memory, a rewritable optical disk, a rewritable magnetic tape, or a combination thereof. The media used by persistent storage 18 may be removable. For example, a removable hard drive may be used for persistent storage 18.

[0017] In these examples, communication unit 20 may provide communication with other DPSs or devices. In these examples, communication unit 20 is a network interface card. Communication unit 20 may provide communication using either a physical communication link or a wireless communication link, or both.

[0018] Input / output unit 22 may allow for the input and output of data with other devices that may be connected to DPS 10. For example, input / output unit 22 may provide a connection for user input via a keyboard, mouse, or other suitable input device, or a combination thereof. Additionally, input / output unit 22 may send output to a printer. Display 24 may provide a mechanism for displaying information to a user.

[0019] Instructions for the operating system, applications, and / or programs may be located in storage device 26, which communicates with processor unit 14 via communication bus 12. In these examples, the instructions reside in functional form on persistent storage 18. These instructions may be loaded into memory 16 for execution by processor unit 14. The processes of the various embodiments may be performed by processor unit 14 using computer-implemented instructions, which may be located in a memory, such as memory 16. These instructions are referred to as program code 38 (described below), computer-usable program code, or computer-readable program code, which may be read and executed by a processor in processor unit 14. The program code in various embodiments may be embodied on different physical or tangible computer-readable media, such as memory 16 or persistent storage 18.

[0020] DPS 10 may further include an interface for network 29. This interface may include hardware, drivers, software, etc. to enable communication over wired and wireless networks 29 and may implement any number of communication protocols, including, for example, communication protocols at various levels of the Open Systems Interconnection (OSI) seven-layer model.

[0021] FIG. 1A further illustrates a computer program product 30 that may include program code 38. The program code 38 may be located in a functional form on a selectively removable computer-readable medium 32 and loaded onto or transferred to the DPS 10 for execution by the processor unit 14. In these examples, the program code 38 and the computer-readable medium 32 may form the computer program product 30. In one example, the computer-readable medium 32 may be a computer-readable storage medium 34 or a computer-readable signal medium 36. The computer-readable storage medium 34 may include, for example, an optical or magnetic disk inserted into or placed into a drive or other device that is part of persistent storage 18 for transfer to a storage device, such as a hard drive that is part of persistent storage 18. The computer-readable storage medium 34 may take the form of persistent storage, such as a hard drive, thumb drive, or flash memory connected to the DPS 10. In some cases, the computer-readable storage medium 34 may not be removable from the DPS 10.

[0022] Alternatively, program code 38 may be transmitted to DPS 10 using computer-readable signal medium 36. Computer-readable signal medium 36 may be, for example, a propagated data signal containing program code 38. For example, computer-readable signal medium 36 may be an electromagnetic signal, an optical signal, or any other suitable type of signal. These signals may be transmitted over a communications link, such as a wireless communications link, fiber optic cable, coaxial cable, a wire, or any other suitable type of communications link, or a combination thereof. In other words, in these examples, the communications link and / or connection may be physical or wireless.

[0023] In some example embodiments, program code 38 may be downloaded to persistent storage 18 from another device or DPS via computer-readable signal medium 36 over a network for use within DPS 10. For example, program code stored on a computer-readable storage medium in a server DPS may be downloaded from the server over a network to DPS 10. The DPS providing program code 38 may be a server computer, a client computer, or other device capable of storing and transmitting program code 38.

[0024] The different components illustrated in DPS 10 are not meant to provide architectural limitations to the manner in which different embodiments may be implemented. Different example embodiments may be implemented in a DPS with components in addition to or in place of the components illustrated in DPS 10.

[0025] General Cloud Computing Although this disclosure includes detailed descriptions of cloud computing, it should be understood that implementation of the subject matter presented herein is not limited to cloud computing environments. Embodiments of the invention may be implemented in conjunction with any other type of computing environment now known or later developed.

[0026] Cloud computing is a service delivery model for enabling convenient, on-demand network access to a shared pool of configurable computational resources (e.g., networks, network bandwidth, servers, processing, memory, storage, applications, virtual machines, and services) and for rapidly provisioning and releasing these resources with minimal administrative effort or interaction with a service provider. This cloud model may include at least five characteristics, at least three service models, and at least four deployment models.

[0027] The features are as follows: On-demand self-service: Cloud customers can automatically provision server time, network storage, and other computing power as needed, without any unilateral or human interaction with the service provider.

[0028] Wide network access: Cloud capabilities are available over the network and can be accessed using standard mechanisms, facilitating usage by heterogeneous thin- or thick-client platforms (e.g., mobile phones, laptops, and PDAs).

[0029] Resource Pool: The provider's computing resources are pooled and offered to multiple consumers using a multi-tenant model. Various physical and virtual resources are dynamically allocated and reallocated according to demand. There is a sense of location independence; consumers typically have no control or knowledge regarding the exact location of the resources offered, although at a higher level of abstraction, they may be able to specify a location (e.g., country, state, or data center).

[0030] Rapid Elasticity: Cloud capacity can be quickly and elastically provisioned, in some cases automatically, to scale out quickly, and quickly released to scale in quickly. Capacity available for provisioning often appears to consumers as unlimited, available for purchase in any quantity at any time.

[0031] Metered Services: Cloud systems leverage metering capabilities to automatically control and optimize resource usage at an abstraction level appropriate to the type of service (e.g., storage, processing, bandwidth, and active user accounts). Resource usage can be monitored, controlled, and reported, providing transparency to both providers and consumers of utilized services.

[0032] The service model is as follows: SaaS (Software as a Service): The consumer is provided with the ability to use the provider's applications running on a cloud infrastructure. Those applications can be accessed from a variety of client devices through thin-client interfaces such as web browsers (e.g., web-based email). The consumer does not manage or control the underlying cloud infrastructure, including the network, servers, operating systems, storage, or individual application features, except for the possibility of setting limited user-specific application configuration settings.

[0033] PaaS (Platform as a Service): The ability offered to a consumer is to deploy applications they create or acquire, written using programming languages ​​and tools supported by the provider, onto a cloud infrastructure. The consumer does not manage or control the underlying cloud infrastructure, including the network, servers, operating systems, or storage, but does have control over the deployed applications and, in some cases, the configuration of the application hosting environment.

[0034] Infrastructure as a Service (IaaS): The capability provided to a consumer is the provisioning of processing, storage, network, and other basic computing resources, upon which the consumer can deploy and run any software, which may include operating systems and applications. The consumer does not manage or control the underlying cloud infrastructure, but has control over the operating systems, storage, and deployed applications, and in some cases has limited control over selected network components (e.g., host firewalls).

[0035] The deployment model is as follows: Private Cloud: This cloud infrastructure is operated solely for an organization and can be managed by that organization or a third party, and can reside on-premise or off-premise.

[0036] Community Cloud: This cloud infrastructure is shared by multiple organizations to support a specific community with shared interests (e.g., mission, security requirements, policy, and compliance considerations). It can be managed by these organizations or a third party and can reside on-premises or off-premises.

[0037] Public Cloud: This cloud infrastructure is available for use by the general public or large industry organizations and is owned by an organization that sells cloud services.

[0038] Hybrid cloud: This cloud infrastructure is a combination of two or more clouds (private, community, or public) that remain distinct but are joined together by standardized or proprietary technologies that allow for the portability of data and applications (e.g., cloud bursting to balance load between clouds).

[0039] A cloud computing environment is a service-oriented environment that emphasizes statelessness, loose coupling, modularity, and semantic interoperability. At the heart of cloud computing is an infrastructure that contains a network of interconnected nodes.

[0040] 1B, an exemplary cloud computing environment 52 is shown. As shown, the cloud computing environment 52 includes one or more cloud computing nodes 50 with which local computing devices used by cloud consumers (e.g., a personal digital assistant (PDA) or mobile phone 54A, a desktop computer 54B, a laptop computer 54C, and / or an automobile computer system 54N) can communicate. The nodes 50 may communicate with each other. The nodes 50 may be physically or virtually grouped in one or more networks (not shown), such as a private cloud, community cloud, public cloud, or hybrid cloud, or combinations thereof, as previously described herein. This enables the cloud computing environment 52 to provide an infrastructure, platform, and / or SaaS that does not require the cloud consumer to maintain resources on a local computing device. The types of computing devices 54A-N shown in FIG. 1B are intended to be illustrative only, and it is understood that computing node 50 and cloud computing environment 52 can communicate with any type of computer-controlled device via any type of network and / or network-addressable connection (e.g., a connection using a web browser).

[0041] Referring now to Figure 1C, a set of functional abstraction layers provided by cloud computing environment 52 (Figure 1B) is shown. It should be understood in advance that the components, layers, and functions shown in Figure 1C are intended to be illustrative only, and that embodiments of the present invention are not limited thereto. As shown, the following layers and corresponding functions are provided:

[0042] Hardware and software layer 60 includes hardware and software components. Examples of hardware components include mainframe 61, RISC (Reduced Instruction Set Computer) architecture-based server 62, server 63, blade server 64, storage device 65, and network and network components 66. In some embodiments, software components include network application server software 67 and database software 68.

[0043] The virtualization layer 70 comprises an abstraction layer capable of providing virtual entities such as virtual servers 71, virtual storage 72, virtual networks including virtual private networks 73, virtual applications and operating systems 74, and virtual clients 75.

[0044] By way of example, the management layer 80 may provide the following functions: Resource provisioning 81 dynamically procures computing and other resources used to execute tasks within the cloud computing environment; Metering and pricing 82 tracks costs as resources are utilized within the cloud computing environment and sends bills or invoices for the utilization of those resources; by way of example, those resources may include application software licenses; Security verifies the identity of cloud users and tasks and protects data and other resources; User portal 83 provides users and system administrators with access to the cloud computing environment; Service level management 84 allocates and manages cloud computing resources to meet required service levels; and Service Level Agreement (SLA) planning and execution 85 proactively prepares and procures cloud computing resources in accordance with SLAs in anticipation of future demand.

[0045] The Workload Layer 90 illustrates examples of functionality available in a cloud computing environment. Examples of workloads and functionality that may be provided from this layer include mapping and navigation 91, software development and lifecycle management 92, virtual classroom education delivery 93, data analytics processing 94, transaction processing 95, and time-bound cryptocurrency processing 96.

[0046] In addition to computing devices 54A-N, any of the nodes 50 in computing environment 52 may also be a DPS 10.

[0047] Basic details of blockchain As generally described and illustrated in the figures herein, the components herein can be arranged and designed in a wide variety of different configurations. Thus, the following detailed description of at least one embodiment of a method, apparatus, non-transitory computer-readable medium, and system, as represented in the accompanying figures, is not intended to limit the scope of the present application as claimed, but is merely representative of selected embodiments.

[0048] Features, structures, or characteristics described throughout this specification may be combined or eliminated in any suitable manner in one or more embodiments. For example, the use of the phrases “example embodiments,” “some embodiments,” or other similar language throughout this specification indicates that particular features, structures, or characteristics described in connection with an embodiment may be included in at least one embodiment. Thus, the appearances of the phrases “example embodiments,” “in some embodiments,” “in other embodiments,” or other similar language throughout this specification do not necessarily all refer to the same group of embodiments, and the described features, structures, or characteristics may be combined or eliminated in any suitable manner in one or more embodiments. Furthermore, in the figures, any connections between elements may allow for one-way or two-way communication, or both, even if the connections shown are one-way or two-way arrows. Also, any devices shown in the figures may be different devices. For example, when a mobile device is shown transmitting information, a wired device may also be used to transmit that information.

[0049] Additionally, while the term "message" may be used in describing the embodiments, the present application may apply to many types of networks and data. Furthermore, while particular types of connections, messages, and signaling may be shown in the example embodiments, the present application is not limited to the particular types of connections, messages, and signaling.

[0050] Example embodiments provide methods, systems, components, non-transitory computer-readable media, devices, and / or networks that provide sustainable tokens for supply chains using a confidentiality protocol within a blockchain network (referred to herein as a blockchain network).

[0051] In one embodiment, an application utilizes a distributed database (e.g., a blockchain), a distributed storage system containing multiple nodes communicating with each other. A distributed database includes an append-only, immutable data structure, similar to a distributed ledger, that allows records to be maintained among mutually untrusted parties. The untrusted parties are referred to herein as peers or peer nodes. Each peer maintains a copy of the database record, and no single peer can modify the database record without reaching consensus among the distributed peers. For example, peers may execute a consensus protocol to verify the validity of blockchain-stored transactions, group those stored transactions into blocks, and build a hash chain on the blocks. This process forms a ledger by ordering the stored transactions, as necessary, for consistency. Various embodiments may use permissioned or permissionless blockchains. Public or permissionless blockchains allow anyone to participate without specific identity. Public blockchains include native cryptocurrencies and can use consensus based on various protocols, such as Proof of Work (PoW). Permissioned blockchain databases, on the other hand, provide secure interactions within a group of entities that share a common goal but do not fully trust each other, such as businesses exchanging funds, goods, or information.

[0052] This application can utilize a blockchain that operates on arbitrary programmable logic, called a "smart contract" or "chaincode," tailored to the distributed storage method. In some cases, there may be a specialized chaincode for managing functions and parameters, called a system chaincode. The application can further utilize smart contracts, which are trusted distributed applications that leverage the tamper-resistant properties of the blockchain database and the underlying agreement between nodes, called a signature or signature policy. Blockchain transactions associated with this application can be "signed" before being committed to the blockchain, while unsigned transactions are ignored. The signature policy allows the chaincode to specify the signers of the transaction in the form of a set of peer nodes required for signing. When a client submits a transaction to the peer specified in the signature policy, a transaction validation check is performed. After validation, the transaction moves to the ordering phase, where a consensus protocol is used to generate an ordered sequence of signed transactions grouped into blocks.

[0053] This application can utilize nodes, which are the communicating entities in a blockchain system. A "node" may perform a logical function, meaning that multiple nodes of different types can run on the same physical server. Nodes are grouped within trust domains and associated with logical entities that control them in various ways. Nodes may include various types, such as client or submit-client nodes, which submit transaction calls to signers (e.g., peers) and broadcast transaction proposals to an ordering service (e.g., ordering node). Another type of node is a peer node, which can receive client-submitted transactions, commit transactions, and maintain a ledger state and copy of blockchain transactions. Peers can also assume the role of signers, but this is not a requirement. An ordering service node or ordering node is a node that performs communication services for all nodes and enforces delivery guarantees, such as broadcasting to each of the peer nodes in the system when committing transactions and when modifying the blockchain world state (another name for the initial blockchain transaction, which typically contains control and configuration information).

[0054] The application may utilize a ledger, which is an ordered, tamper-proof record of all state transitions of the blockchain. State transitions may result from chaincode invocations (i.e., transactions) submitted by participating parties (e.g., client nodes, ordering nodes, signer nodes, peer nodes, etc.). Each participating party (e.g., peer node) may maintain a copy of the ledger. A transaction may result in a set of asset key-value pairs being committed to the ledger as one or more operands (e.g., create, update, delete, etc.). The ledger includes a blockchain (also called a chain) used to store immutable, ordered records in blocks. The ledger also includes a state database that maintains the current state of the blockchain.

[0055] This application can utilize a chain, a transaction log structured as hash-linked blocks, where each block contains a sequence of N transactions, where N is greater than or equal to 1. The block header contains the hash of the block's transactions and the hash of the previous block's header. In this way, all transactions in the ledger may be ordered and cryptographically linked to each other. Therefore, ledger data cannot be tampered with without breaking the hash links. The hash of the most recently added blockchain block represents all transactions on the chain that occurred before it, allowing all peer nodes to be assured of a consistent and reliable state. The chain may be stored in the peer node's file system (i.e., local, attached storage, cloud, etc.), which efficiently supports the append-only nature of blockchain workloads.

[0056] The immutable ledger's current state represents the most recent values ​​for all keys contained in the chain's transaction log. The current state is sometimes called the world state, as it represents the most recent key values ​​known to the channel. Chaincode invocations execute transactions against data in the ledger's current state. To make those chaincode interactions efficient, the most recent key values ​​may be stored in a state database. The state database may simply be an indexed view into the chain's transaction log and therefore may be regenerated from the chain at any time. The state database may be automatically recovered (or generated if necessary) upon peer node startup, before any transactions are received.

[0057] Some of the advantages of the solutions described and illustrated herein include methods and systems for sustainable tokens for supply chains using a confidentiality protocol within a blockchain network in a blockchain network. Example embodiments address issues of time and trust by extending database features such as immutability, digital signatures, and the existence of a single source of truth. Example embodiments provide a solution for sustainable tokens for supply chains using a confidentiality protocol within a blockchain network in a blockchain-based network. Blockchain networks can be homogeneous based on asset types and the rules governing the assets based on smart contracts.

[0058] Blockchains differ from traditional databases in that they do not have a central storage device, but rather decentralized, immutable, and secure storage, and each node must share changes to records in storage. Some of the characteristics unique to blockchains and useful for implementing them include, but are not limited to, immutable ledgers, smart contracts, security, confidentiality, decentralization, consensus, signatures, and accessibility, which are further described herein. According to various aspects, due to the inherent immutable accountability, security, confidentiality, permissioned decentralization, the use of smart contracts, signatures, and accessibility unique to blockchains, a system for sustainable tokens for supply chains using confidentiality protocols in a blockchain network is implemented. In particular, data in the blockchain ledger is immutable, providing an efficient method for sustainable tokens for supply chains using confidentiality protocols in a blockchain network. Alternatively, the use of cryptography in blockchains provides security and builds trust. Smart contracts manage the state of assets and complete their lifecycle. An exemplary blockchain is decentralized and permissioned. Thus, each end user may have their own copy of the ledger for access. Multiple organizations (and peers) may be incorporated into the blockchain network. A central organization may act as a signing peer to verify the validity of smart contract execution results, read sets, and write sets. In other words, the unique features of blockchain provide an efficient implementation of a method for sustainable tokens for supply chains that uses confidentiality protocols within a blockchain network.

[0059] One advantage of example embodiments is that they improve the functionality of computing systems by implementing a method for a sustainable token for a supply chain using a security protocol in a blockchain-based system. The computing system can perform functions for a sustainable token for a supply chain using a security protocol in a blockchain network by providing access to capabilities such as distributed ledgers, peers, cryptography, MSPs, and event processing via the blockchain system described herein. Blockchains also enable the creation of business networks and the incorporation of any user or organization. Therefore, blockchains are more than just databases. They provide the ability to create business networks of users and incorporated and non-incorporated organizations to collaborate and execute service processes in the form of smart contracts.

[0060] Example embodiments provide numerous advantages over traditional databases, including the inherent immutable accountability, security, confidentiality, permissioned decentralization, smart contract enablement, signing, and accessibility inherent to blockchains.

[0061] On the other hand, example embodiments cannot be implemented using traditional databases because they do not bring all parties into a business network, do not create trusted collaboration, and do not provide efficient storage of digital assets. Traditional databases do not provide tamper-proof storage or protection for stored digital assets. Therefore, the proposed method for sustainable tokens for supply chains using confidentiality protocols within a blockchain network cannot be implemented with traditional databases.

[0062] On the other hand, if traditional databases were used to implement example embodiments, the example embodiments would suffer from unnecessary drawbacks such as lack of search capabilities, security, and slower transaction speeds. Furthermore, an automated method for sustainable tokens for supply chains using confidentiality protocols within a blockchain network would simply not be possible.

[0063] Thus, example embodiments provide specific solutions to problems in the art / area of ​​virtual currency control.

[0064] Example embodiments also modify how data may be stored within a blockchain's block structure. For example, digital asset data may be securely stored within specific portions of a data block (i.e., within the header, data segment, or metadata). Storing digital asset data within a blockchain's data block allows the digital asset data to be added to an immutable blockchain ledger via a hash-linked chain of blocks. In some embodiments, data blocks may differ from traditional data blocks in that personal data associated with digital assets is not stored with the assets within the blockchain's traditional block structure. By eliminating personal data associated with digital assets, blockchains can provide the benefits of anonymity based on immutable accountability and security.

[0065] According to example embodiments, a system and method for sustainable tokens for supply chains using a security protocol within a blockchain network is provided. A blockchain document processor may include two components:

[0066] - Private off-chain processors that manage the secure processing of personal information relating to participants, and

[0067] - A ledger processor that uses the network's consensus algorithm to manage the processing of common information shared with all participants in a blockchain network.

[0068] According to an example embodiment, each organization that wishes to share documents with other organizations uses a blockchain document processor connected to the blockchain network. The organization may use the document processor to set the following items on the ledger:

[0069] - list of document templates,

[0070] - Attributes of each document template shared in hashed form in the ledger;

[0071] - Combining key attributes from different templates to collate and share documents, and

[0072] - Partnership Merkel trees: Each partnership Merkel tree may be built based on the identifiers (IDs) of the partnering organizations.

[0073] All documents (files, JSON) are stored in an off-chain data store, and only a hash of the attributes and the document identifier (ID) are submitted as part of the blockchain transaction.

[0074] According to one example embodiment, the document identifier and document type may be linked to a hashed attribute for sharing. The hashed owner's org id may contain a composite key such that:

[0075] - Given a document ID, a document processor can retrieve all hashed attributes for sharing, and

[0076] Given the hashed attributes for sharing, the document processor can retrieve all document IDs and their hashed owner organization ids.

[0077] Given the hashed attributes for sharing when a document is recorded, the document processor may retrieve all documents and their hashed owner organization IDs. The processor may check whether the owner organization IDs of the incoming document and each owner organization ID are part of the partnership Merkle tree. If those IDs belong to the partnership Merkle tree of the subset of documents in the eligible organizational relationship, the processor may retrieve the template required for logical matching. Based on evaluating the hashed attribute matches, the processor may obtain a list of documents (and their owners) to which the incoming document should be linked. The processor may then create the linked document. The processor may generate a one-time passcode and pass it to all participants so that they can link to this document. The participants then query the blockchain using the one-time passcode and hashed organization ID to retrieve the incoming document key. The participants may use the document key to retrieve the shared document from the owning party (i.e., the blockchain node) and store the document in the recipient's off-chain storage.

[0078] FIG. 2A illustrates a blockchain architecture configuration 200 according to an example embodiment. Referring to FIG. 2A, the blockchain architecture 200 may include a particular blockchain element (e.g., a group of blockchain nodes 202). The blockchain nodes 202 may include one or more nodes 204-210 (four nodes are shown by way of example only). These nodes participate in multiple activities, such as adding and validating blockchain transactions (agreements). One or more of the blockchain nodes 204-210 may sign transactions based on a signature policy and provide ordering services to all blockchain nodes in the architecture 200. A blockchain node may initiate a blockchain validation and attempt to write to the blockchain's immutable ledger stored in the blockchain layer 216; a copy of this write may also be stored in the underlying physical infrastructure 214. A blockchain configuration may include one or more applications 224 linked to application programming interfaces (APIs) 222 for accessing and executing stored program / application code 220 (e.g., chaincode, smart contracts, etc.), which can be created according to customized configurations required by participants and can maintain their own state, control their own assets, and receive external information. Blockchain configurations can be deployed as transactions and installed on all blockchain nodes 204-210 by adding them to the distributed ledger.

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

[0080] The blockchain architecture of FIG. 2A may process and execute program / application code 220 through one or more interfaces and services exposed by the blockchain platform 212. The code 220 may control assets on the blockchain. For example, the code 220 may store and transfer data and be executed by the nodes 204-210 in the form of associated chaincode, including smart contracts and conditions, or other code elements subject to execution. As a non-limiting example, smart contracts may be created to implement reminders, updates, or changes, other notifications subject to updates, or a combination thereof. The smart contract itself may be used to identify permission and access requirements and rules associated with use of the ledger. For example, document attribute information 226 may be processed by one or more processing entities (e.g., virtual machines) included in the blockchain layer 216. Results 228 may include multiple linked shared documents. The physical infrastructure 214 may be utilized to retrieve any of the data or information described herein.

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

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

[0083] Chaincode may include a code interpretation of a smart contract along with additional functionality. As described herein, chaincode may be program code deployed on a computing network and executed together and validated by chain validators during the consensus process. The chaincode receives the hash and retrieves the hash from the blockchain associated with a data template created by using a previously stored feature extractor. If the hash of the hashed identifier matches the hash created from the stored identifier template data, the chaincode sends an authorization key to the requested service. The chaincode may write data associated with cryptographic details to the blockchain.

[0084] FIG. 2B illustrates an example blockchain transaction flow 250 between nodes of a blockchain, according to an example embodiment. Referring to FIG. 2B, the transaction flow may include a transaction proposal 291 sent by an application client node 260 to a signing peer node 281. The signing peer 281 may verify the client's signature and execute a chaincode function to initiate the transaction. The output may include the chaincode result, a set of key / value versions read into the chaincode (the read set), and a set of key / values ​​written into the chaincode (the write set). A proposal response 292, along with a signature if approved, is sent back to the client 260. The client 260 assembles the signature into a transaction payload 293 and broadcasts it to the ordering service node 284. The ordering service node 284 then distributes the ordered transaction as a block on a channel to all peers 281-283. Each peer 281-283 may verify the validity of the transaction before committing it to the blockchain. For example, a peer may check the signature policy to ensure that the correct allocation of the specified peer signed the result and authenticated the signature on the transaction payload 293.

[0085] Referring again to FIG. 2B, a client node 260 initiates a transaction 291 by constructing and sending a request to a peer node 281 (the signer). The client 260 may include an application utilizing a supported software development kit (SDK), which utilizes available APIs to generate a transaction protocol. The proposal is a request to invoke a chaincode function so that data can be read from the ledger, written to the ledger (i.e., writing a new key-value pair for an asset), or both. The SDK may act as a shim to package the transaction proposal into a suitably designed format (e.g., protocol buffers via remote procedure call (RPC)), receive the client's cryptographic credentials, and generate a unique signature for the transaction proposal.

[0086] In response, the signing peer node 281 may verify that (a) the transaction proposal is properly formed, (b) the transaction has not already been submitted previously (replay attack protection), (c) the signature is valid, and (d) the submitter (in this example, client 260) has the appropriate permissions to perform the proposed operation on that channel. The signing peer node 281 may receive the transaction proposal input as an argument to a chaincode function that is invoked. The chaincode is then executed against the current state database to generate a transaction result that includes a response value, a read set, and a write set; however, no updates are made to the ledger at this time. At 292, the set of values, along with the signing peer node 281's signature, is returned as a proposal response 292 to the client 260's SDK, which parses the payload for use by the application.

[0087] In response, the client 260 application inspects / verifies the signing peer's signature and compares the proposal response to determine whether the proposal response is the same. If the chaincode simply queries the ledger, the application inspects the query response and typically does not submit the transaction to the ordering node service 284. If the client application intends to submit a transaction to the ordering node service 284 to update the ledger, the application determines whether the specified signature policy is satisfied (i.e., whether all required peer nodes for the transaction have signed the transaction) before submitting. Here, the client may include only one of multiple parties in the transaction. In this case, each client may include its own signing node, and each signing node must sign the transaction. The architecture ensures that the signature policy is still enforced by peers and maintained during the commit validation phase, even if the application chooses not to inspect the response or otherwise forwards an unsigned transaction.

[0088] After successful verification, in step 293, the client 260 assembles the signatures into a transaction and broadcasts the transaction proposal and transaction response in a transaction message to the ordering node 284. The transaction may include a read / write set, the signing peer's signature, and a channel ID. The ordering node 284 does not need to inspect the entire contents of the transaction to perform its operation; instead, the ordering node 284 may simply receive transactions from all channels in the network, order them chronologically by channel, and create a block of transactions for each channel.

[0089] The block of transactions is distributed from the ordering node 284 to all peer nodes 281-283 on the channel. The transactions 294 in the block are validated to ensure that any signature policies are satisfied and to ensure that there have been no changes to the ledger state with respect to the variables in the read set since the read set was generated by the transaction's execution. The transactions in the block are tagged as valid or invalid. Further, in step 295, each peer node 281-283 adds the block to the channel's chain, and for each valid transaction, the write set is committed to the current state database. Events are published to notify the client application that the transaction (invocation) has been immutably added to the chain and whether the transaction has been validated or invalidated.

[0090] FIG. 3A illustrates an example of a permissioned blockchain network 300, which features a distributed, decentralized, peer-to-peer architecture. In this example, a blockchain user 302 may initiate a transaction against a permissioned blockchain 304. In this example, the transaction may be a deployment, invocation, or query and may be issued through a client-side application utilizing an SDK, directly through an API, or the like. The network may provide access to regulators 306, such as auditors. A blockchain network operator 308 manages member permissions, such as registering regulators 306 as “auditors” and blockchain users 302 as “clients.” Auditors may be limited to only querying the ledger, while clients may be authorized to deploy, invoke, and query certain types of chaincode.

[0091] A blockchain developer 310 can write chaincode and client-side applications. Through an interface, the blockchain developer 310 can deploy the chaincode directly to the network. To include authentication information from traditional data sources 312 in the chaincode, the developer 310 can access the data using an out-of-band connection. In this example, a blockchain user 302 connects to the permissioned blockchain 304 through a peer node 314. Before initiating any transactions, the peer node 314 obtains user registration and transaction certificates from a certificate authority 316, which manages user roles and permissions. In some cases, blockchain users must possess their digital certificates to execute transactions on the permissioned blockchain 304. Meanwhile, users seeking to utilize chaincode may need to verify their user credentials on traditional data sources 312. To verify the user's authorization, the chaincode can use an out-of-band connection to this data through a traditional processing platform 318.

[0092] FIG. 3B illustrates another example of a permissioned blockchain network 320, which features a decentralized, decentralized, peer-to-peer architecture. In this example, blockchain users 322 may submit transactions to a permissioned blockchain 324. In this example, transactions can be deploys, invokes, or queries and may be issued through a client-side application utilizing an SDK, directly through an API, or the like. The network may provide access to regulators 326, such as auditors. A blockchain network operator 328 manages member permissions, such as registering regulators 326 as “auditors” and blockchain users 322 as “clients.” Auditors can be limited to only querying the ledger, while clients may be allowed to deploy, invoke, and query certain types of chaincode.

[0093] A blockchain developer 330 writes chaincode and client-side applications. Through an interface, the blockchain developer 330 can deploy the chaincode directly to the network. To include authentication information from traditional data sources 332 in the chaincode, the developer 330 can access the data using an out-of-band connection. In this example, a blockchain user 322 connects to the network through a peer node 334. The peer node 334 obtains the user's registration and transaction certificate from a certificate authority 336 before initiating any transactions. In some cases, blockchain users must possess their digital certificates to execute transactions on the permissioned blockchain 324. Meanwhile, users seeking to utilize chaincode may need to verify their user's authentication information on traditional data sources 332. To verify the user's authorization, the chaincode can use an out-of-band connection to this data through a traditional processing platform 338.

[0094] In some embodiments, a blockchain herein may be a permissionless blockchain. In contrast to a permissioned blockchain, which requires permission to participate, anyone can participate in a permissionless blockchain. For example, to participate in a permissionless blockchain, a user may create a personal address and begin interacting with the network by submitting transactions, thus adding entries to the ledger. Furthermore, any participant may choose to run a node on the system and adopt a mining protocol to help validate transactions.

[0095] FIG. 3C illustrates a transaction process 350 being processed by a permissionless blockchain 352 that includes multiple nodes 354. A sender 356 wishes to send a payment or other form of value (e.g., a certificate, medical records, a contract, goods, services, or any other asset that can be encapsulated in a digital record) to a recipient 358 via the permissionless blockchain 352. In one embodiment, the sender device 356 and the recipient device 358 may each have a digital wallet (associated with the blockchain 352) that provides user interface controls and display of transaction parameters. In response, the transaction is broadcast to nodes 354 throughout the blockchain 352. Depending on the network parameters of the blockchain 352, nodes validate (360) the transaction based on rules (which may be predefined or dynamically assigned) established by the creator of the permissionless blockchain 352. For example, this validation may include verifying the identities of the parties involved. The transaction may be validated immediately, or the transaction may be placed in a queue with other transactions, and node 354 determines whether the transaction is valid based on a set of network rules.

[0096] In structuring 362, valid transactions are formed into blocks and sealed using a lock (hash). This process may be performed between nodes 354 by mining nodes. Mining nodes may utilize additional software to, among other things, mine and create blocks for the permissionless blockchain 352. Each block may be identified by a hash (e.g., a 256-bit number) created using an algorithm agreed upon by the network. Each block may include a header, a pointer or reference to the hash of the header of the previous block in the chain, and a group of valid transactions. The reference to the hash of the previous block is associated with creating a secure, independent chain of blocks.

[0097] Before a block can be added to the blockchain, it must be validated. Validation in a permissionless blockchain 352 may involve proof-of-work (PoW), which is the solution to a puzzle derived from the block's header. Another process for validating a block, not shown in the example of Figure 3C, is proof-of-stake. Unlike proof-of-work, in which an algorithm rewards miners for solving a mathematical problem, in proof-of-stake, the creator of a new block is selected deterministically according to their wealth (also defined as "stake"). Similar proofs are then performed by the selected nodes.

[0098] In mining 364, nodes attempt to solve a block by making incremental changes to one variable until the solution meets a network-wide target. This creates proof of work, thereby guaranteeing a correct answer. In other words, a possible solution must prove that computational resources were expended in solving the problem. In some types of permissionless blockchains, miners may be rewarded with value (e.g., coins) for successfully mining a block.

[0099] Here, the PoW process, along with block chaining, makes it extremely difficult to modify the blockchain, since an attacker must modify all subsequent blocks in order for a change to one block to be accepted. Furthermore, as new blocks are mined, the difficulty of modifying the block increases, as does the number of subsequent blocks. In distribution 366, successfully validated blocks are distributed throughout the permissionless blockchain 352, and all nodes 354 add the block to the majority chain, which is an auditable ledger of the permissionless blockchain 352. Furthermore, the value in the transaction submitted by the sender 356 is deposited or otherwise transferred into a digital wallet on the recipient device 358.

[0100] Figure 4 is a block diagram illustrating a basic blockchain sequence 400 of three transactions. The first block includes a first header 410a and a first group of transactions 420a that comprise the first block. The block header includes a hash 412a of the previous block header and a Merkle root 414a. The Merkle root 414a is a hash of all hashes of all transactions that are part of the block in the blockchain network, ensuring that the entire data block passed between peers is undamaged and unaltered. The second block includes a second header 410b and a second group of transactions 420b that comprise the second block. The block header includes a hash 412b of the previous block header 410a and a Merkle root 414b. The third block includes a third header 410c and a third group of transactions 420c that comprise the third block. The block header includes a hash 412c of the previous block header 410b and a Merkle root 414c. The number of blocks may be extended to any feasible length and the hash value may be checked / verified relatively easily.

[0101] FIG. 5A illustrates an example system 500 including a physical infrastructure 510 configured to perform various operations according to example embodiments. Referring to FIG. 5A, the physical infrastructure 510 includes a module 512 and a module 514. The module 514 includes a blockchain 520 and a smart contract 530 (which may reside on the blockchain 520), which may perform any of the operational steps 508 (within the module 512) included in any of the example embodiments. The steps / operations 508 may include one or more of the embodiments described or illustrated in the figures and may represent information written to, read from, output from, or written to one or more smart contracts 530 and / or the blockchain 520. The physical infrastructure 510, the module 512, and the module 514 may include one or more computers, servers, processors, memories, and / or wireless communication devices. Additionally, the modules 512 and 514 may be the same module.

[0102] FIG. 5B illustrates another exemplary system 540 configured to perform various operations in accordance with example embodiments. Referring to FIG. 5B, system 540 includes module 512 and module 514. Module 514 includes a blockchain 520 and a smart contract 530 (which may reside on blockchain 520), which may perform any of the operational steps 508 (within module 512) included in any of the example embodiments. Steps / operations 508 may include one or more of the embodiments described or illustrated in the figures and may represent information written to, read from, output from, or written to one or more smart contracts 530 and / or blockchain 520. Physical modules 512 and 514 may include one or more computers, servers, processors, memories, or wireless communication devices, or a combination thereof. Additionally, modules 512 and 514 may be the same module.

[0103] FIG. 5C illustrates an exemplary system configured to utilize an intermediary server configured to configure smart contracts between contracting parties and enforce the terms of the smart contracts on a blockchain, according to an example embodiment. Referring to FIG. 5C, configuration 550 may represent a communication session, an asset transfer session, or a process or procedure, and is driven by a smart contract 530 that explicitly identifies one or more user devices 552 and / or 556. The execution, operation, and results of the smart contract may be managed by a server 554. The contents of smart contract 530 may require digital signatures by one or more of the entities 552 and 556 that are participants in the smart contract transaction. The results of the smart contract execution may be written to blockchain 520 as a blockchain transaction. Smart contract 530 resides on blockchain 520, which may reside on one or more computers, servers, processors, memories, and / or wireless communication devices.

[0104] FIG. 5D illustrates a system 560 including a blockchain, according to an example embodiment. Referring to the example of FIG. 5D, an application programming interface (API) gateway 562 provides a common interface for accessing the blockchain's logic (e.g., smart contracts 530 or other chaincode) and data (e.g., distributed ledger, etc.). In this example, API gateway 562 is a common interface for executing transactions (calls, queries, etc.) against the blockchain by connecting one or more entities 552 and 556 to blockchain peers (i.e., servers 554). Here, servers 554 are peer components of the blockchain network that maintain copies of the world state and the distributed ledger, allowing clients 552 and 556 to query data about the world state and submit transactions to the blockchain network, where the signing peers execute smart contracts 530 according to smart contract 530 and signing policies.

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

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

[0107] Figure 6A illustrates a process 600 for a new block being added to a distributed ledger 620 according to an example embodiment, and Figure 6B illustrates the contents of a new data block structure 630 in a blockchain according to an example embodiment. The new data block 630 may contain documents that link data.

[0108] Referring to FIG. 6A, a client (not shown) may submit a transaction to blockchain nodes 611, 612, or 613, or a combination thereof. A client may be an instruction received from any source to specify an activity on the blockchain 620. As an example, a client may be an application acting on behalf of a requester, such as a device, person, or entity, proposing a blockchain transaction. Multiple blockchain peers (e.g., blockchain nodes 611, 612, and 613) may maintain a copy of the blockchain network state and the distributed ledger 620. Various types of blockchain nodes / peers may exist within a blockchain network, including signing peers that simulate and sign transactions proposed by clients, and commit peers that verify signatures, confirm the validity of the transactions, and commit the transactions to the distributed ledger 620. In this example, blockchain nodes 611, 612, and 613 may perform the role of signer nodes, committer nodes, or both.

[0109] The distributed ledger 620 includes a blockchain, which stores immutable, ordered records in blocks, and a state database 624 (current world state), which maintains the current state of the blockchain 622. There may be one distributed ledger 620 per channel, and each peer maintains its own copy of the distributed ledger 620 for each channel in which it is a member. The blockchain 622 is a transaction log structured as hash-linked blocks, with each block containing a sequence of N transactions. A block may contain various components, such as those shown in Figure 6B. Block links (shown by arrows in Figure 6A) may be generated by adding a hash of the previous block's header to the block header of the current block. In this way, all transactions on the blockchain 622 are ordered and cryptographically linked to each other, preventing tampering with the blockchain data without breaking the hash links. Furthermore, because of these links, the most recent block in the blockchain 622 represents all transactions that came before it. The blockchain 622 may be stored in the file system (local or attached storage) of a peer that supports additional dedicated blockchain workloads.

[0110] The current state of the blockchain 622 and distributed ledger 622 may be stored in a state database 624, where the current state data represents the latest values ​​of all keys ever included in the chain transaction log of the blockchain 622. Chaincode invocations execute transactions against the current state in the state database 624. To make these chaincode interactions highly efficient, the latest values ​​of all keys are stored in the state database 624. The state database 624 may contain an indexed view into the blockchain 622 transaction log and therefore can be regenerated off-chain at any time. The state database 624 may be automatically restored (or generated if necessary) upon peer startup, before any transactions are received.

[0111] A signing node receives transactions from clients and signs them based on the simulation results. The signing node holds a smart contract that simulates a transaction proposal. When a signing node signs a transaction, it creates a transaction signature, which is a signed response from the signing node to the client application that indicates the signature of the simulated transaction. The way in which a transaction is signed is determined by a signature policy that may be specified in the chaincode. An example of a signature policy is "a majority of the signing peers must sign the transaction." Different channels may have different signature policies. The signed transaction is forwarded by the client application to the ordering service 610.

[0112] The ordering service 610 receives signed transactions, orders them into blocks, and distributes the blocks to committing peers. For example, the ordering service 610 may initiate a new block when a transaction threshold is reached, a timer times out, or another condition occurs. In the example of FIG. 6A, blockchain node 612 is a committing peer that receives a new data block 630 of new data for storage in the blockchain 620. The first block in a blockchain may be called a genesis block, which contains information about the blockchain, its members, the stored data, etc.

[0113] The ordering service 610 may consist of a cluster of ordering nodes. The ordering service 610 does not process transactions, smart contracts, or maintain a shared ledger. Rather, the ordering service 610 may receive signed transactions and specify the order in which those transactions are committed to the distributed ledger 620. The architecture of the blockchain network may be designed so that specific implementations of "ordering" (e.g., Solo, Kafka, BFT, etc.) are pluggable components.

[0114] Transactions are written to the distributed ledger 620 in a consistent order. The order of transactions is established to ensure that updates to the state database 624 are valid when transactions are committed to the network. Unlike cryptocurrency blockchain systems (e.g., Bitcoin) where ordering occurs through solving cryptographic puzzles or mining, in this example, the participants in the distributed ledger 620 may choose the ordering mechanism that best suits their network.

[0115] When the ordering service 610 initializes a new data block 630, the new data block 630 may be broadcast to commit peers (e.g., blockchain nodes 611, 612, and 613). In response, each commit peer verifies the validity of the transactions in the new data block 630 by checking to ensure that the read set and write set still match the current world state in the state database 624. In particular, the commit peer can determine whether the read data that existed when the signer simulated the transaction is identical to the current world state in the state database 624. If the commit peer verifies the validity of the transaction, the transaction is written to the blockchain 622 of the distributed ledger 620, and the state database 624 is updated with the write data from the read / write set. If the transaction fails, i.e., if the commit peer detects that the read / write set does not match the current world state in the state database 624, the transactions ordered in the block are still included in the block but are marked as invalid, and the state database 624 is not updated.

[0116] Referring to FIG. 6B, a new data block 630 (also referred to as a data block) stored in the blockchain 622 of the distributed ledger 620 may include multiple data segments, such as a block header 640, block data 650, and block metadata 660. It should be understood that the various illustrated blocks and their contents, such as the new data block 630 and its contents illustrated in FIG. 6B, are exemplary only and are not intended to limit the scope of example embodiments. The new data block 630 may store transaction information for N (e.g., 1, 10, 100, 500, 1000, 2000, 3000, etc.) transactions in the data block 650. The new data block 630 may include a link to a previous block (e.g., on the blockchain 622 of FIG. 6A) in the block header 640. In particular, the block header 640 may include a hash of the previous block's header. The block header 640 may include a unique block number for the new data block 630, a hash of the block data 650, etc. The block numbers for the new data block 630 are unique and may be assigned in various orders, such as a progressive / consecutive order starting from 0.

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

[0118] In some embodiments, block data 650 may store new data 662 that adds additional information to the hash-linked chain of blocks in blockchain 622. The additional information may include one or more of the steps, features, processes, or operations described or illustrated herein, or any combination thereof. Accordingly, new data 662 may be stored in an immutable log of blocks on distributed ledger 620. Some of the advantages of storing such new data 662 are reflected in the various embodiments disclosed and illustrated herein. In FIG. 6B, new data 662 is shown within block data 650, but it may also be within block header 640 or block metadata 660. New data 662 may include a document composite key used to link documents within an organization.

[0119] The block metadata 660 may store multiple fields of metadata (e.g., as a byte array). The metadata fields may include a signature at the time of block creation, a reference to the last constituent block, a transaction filter that identifies valid and invalid transactions in the block, and the last persistent offset of the ordering service that ordered the block. The signature, last constituent block, and ordering node metadata may be added by the ordering service 610. Meanwhile, the block committer (e.g., blockchain node 612) may add valid / invalid information based on signature policies, validation of the read / write set, etc. The transaction filter may include a byte array with a size equal to the number of transactions in the block data 650 and a validation code that identifies whether the transaction was valid or invalid.

[0120] Figure 6C illustrates an embodiment of a blockchain 670 for digital content, in accordance with embodiments described herein. Digital content may include one or more files and associated information. These files may include media, images, video, audio, text, links, graphics, animations, web pages, documents, or other forms of digital content. The immutable, append-only nature of blockchain serves as a safeguard to protect the integrity, validity, and authenticity of digital content, making it appropriate for use in legal proceedings where admissibility rules apply or in other situations where evidence is considered or the presentation and use of digital information is otherwise subject. In this case, the digital content may be referred to as digital evidence.

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

[0122] In one embodiment, the digital content may not be included in the blockchain. For example, the blockchain may store an encrypted hash of the contents of each block, which does not contain any digital content. The digital content may be stored in a separate storage area or memory address relative to the hash value of the original file. The other storage area may be the same storage device used to store the blockchain, or it may be a different storage area or a separate relational database. The digital content of each block may be referenced or accessed by obtaining or querying the hash value of the block in question and then searching the storage area for that hash value stored corresponding to the actual digital content. This operation may be performed, for example, by a database gatekeeper. This may be illustrated as follows: Blockchain Storage Space Hash value of block 1 Hash value of block 1 Contents Hash value of block N Hash value of block N...Contents

[0123] In the example embodiment of FIG. 6C, the blockchain 670 comprises multiple cryptographically linked blocks 6781, 6782, ... 678 in an ordered sequence. N , where N≧1. Blocks 6781, 6782, ... 678 N The encryption used to link the blocks 6781, 6782, ... 678 may be either multiple keyed or unkeyed hash functions. N are subjected to a hash function (where n is 256 or another number) that produces an n-bit alphanumeric output from input that is based on the information in the block. Examples of such hash functions include, but are not limited to, SHA-type (SHA stands for Secure Hash Algorithm) algorithms, Merkle-Dangard algorithms, HAIFA algorithms, Merkle tree algorithms, nonce-based algorithms, and non-collision-resistant PRF algorithms. In another embodiment, blocks 6781, 6782, ..., 678 N may be cryptographically linked by a function different from the hash function. For illustrative purposes, the following description is given with reference to a hash function (e.g., SHA-2).

[0124] Blocks 6781, 6782, ... 678 in the blockchain N Each of the file versions includes a header, a file version, and a value. The header and value vary from block to block as a result of hashing within the blockchain. In one embodiment, the value may be included in the header. As described in more detail below, the file version may be the original file or a different version of the original file.

[0125] The first block 6781 in a blockchain is called the genesis block and contains a header 6721, an original file 6741, and an initial value 6761. The hashing scheme used for the genesis block, and indeed for all subsequent blocks, may vary. For example, all of the information in the first block 6781 may be hashed together simultaneously, or each or portions of the information in the first block 6781 may be hashed separately, followed by a hash of the separately hashed portions.

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

[0127] The original file 6741 in the genesis block may be, for example, data captured by a device, with or without processing before inclusion in the blockchain. The original file 6741 may be received from a device, media source, or node through a system interface. The original file 6741 may be associated with metadata, which may be generated, for example, by a user, device, or system processor, or a combination thereof, either manually or automatically. The metadata may be included in the first block 6781 in association with the original file 6741.

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

[0129] Other blocks in the blockchain: 6782-678 N However, unlike the first block 6721, the headers 6722 to 6723 in the other blocks also contain headers, files, and values. N Each of the remaining blocks contains the hash value of the immediately preceding block, which may simply be the hash of the previous block's header, or it may be the hash value of the entire previous block. By including the hash value of the preceding block in each of the remaining blocks, a block-by-block trace can be performed from the Nth block back to the genesis block (and associated original files), as indicated by arrow 680, establishing an auditable and immutable chain of custody.

[0130] Headers 6722 to 672 in other blocks N Each of the may generally include other information (e.g., a version number, a timestamp, a nonce, root information, difficulty level, consensus protocol, or other parameters or information associated with the corresponding file or blockchain or both, or a combination thereof).

[0131] Files 6742 to 674 in other blocks N A block may be the same as the original file in the genesis block, or it may be a modified version of the original file, depending, for example, on the type of processing performed. The type of processing performed may vary from block to block. Processing may include any modification of the file in the preceding block, such as editing or otherwise changing the content of the file, removing information from the file, or adding information to the file.

[0132] Additionally or alternatively, processing may include simply copying a file from a previous block, changing the storage location of a file, analyzing a file from one or more previous blocks, moving a file from one storage or memory location to another, or performing an operation on a file and / or associated metadata in the blockchain. Processing including analyzing a file may include, for example, adding, including, or otherwise associating various analyses, statistics, or other information associated with the file.

[0133] Other blocks 6762~676 N The value contained in each block is unique and different as a result of the operations that were performed. For example, the value in any one block corresponds to an updated version of the value in the previous block. This update is reflected in the hash of the block to which the value was assigned. Thus, the value of a block provides an indication of what operations were performed in the block and also makes it possible to trace the blockchain back to the original file. This tracking ensures the integrity of the file throughout the blockchain.

[0134] For example, consider the case where a portion of a file in a previous block is redacted, blocked, or pixelated to protect the identity of a person indicated in the file. In this case, the block containing the edited file would include metadata associated with the edited file, such as how the edit was performed, who performed the edit, a timestamp of when the edit occurred, etc. This metadata may be hashed to form a value. Because the block's metadata is different from the information hashed to form the value in the previous block, the values ​​are different from each other and may be recovered when decrypted.

[0135] In one embodiment, the value of the previous block may be updated (e.g., a new hash value may be calculated) to form the value of the current block if any one or more of the following occurs: The new hash value, in this example embodiment, may be calculated by hashing all or part of the information set forth below: (a) A new SHA-2 computed hash value when the file is processed in any way (e.g., when the file is edited, copied, modified, accessed, or any other action is performed on it). (b) The new storage location of the file (c) Identified new metadata associated with the file. (d) Transfer of file access or control from one blockchain participant to another blockchain participant.

[0136] FIG. 6D illustrates an embodiment of a block that may represent the structure of a block in a blockchain 690, according to one example embodiment. i ) is header 672 i , File 674 i , and the value 676 i Contains:

[0137] Header 672 i is the previous block (blocki-1 ) and additional reference information, which may be, for example, any of the types of information described herein (e.g., header information containing references, properties, parameters, etc.). Every block references the hash of the previous block, except, of course, for the genesis block. The hash value of the previous block may simply be the hash of the header in the previous block, or it may be a hash of all or part of the information in the previous block, including files and metadata.

[0138] File 674 i contains multiple pieces of data, such as Data 1, Data 2, ..., Data N, in turn. The data are tagged with Metadata 1, Metadata 2, ..., Metadata N, which describe the content and / or characteristics associated with the data. For example, the metadata for each piece of data may include information to indicate a timestamp for the data, keywords indicating the process of the data, people or other content depicted in the data, or other characteristics that establish the validity and content of the file as a whole and may be particularly useful for using digital evidence, e.g., as described in connection with the embodiments described below, or a combination thereof. In addition to the metadata, each piece of data may include a reference to the previous piece of data (Reference 1, Reference 2, ..., Reference N) to prevent tampering, gaps in the file, and sequential referencing throughout the file. N ) may be tagged.

[0139] After metadata is assigned to data (e.g., via a smart contract), it cannot be changed without changing the hash, which can be easily identified as invalid. Thus, the metadata creates a data log of information that may be accessed for use by participants in the blockchain.

[0140] Value 676 i is a hash value or other value calculated based on any of the types of information previously described. For example,i ), the value of that block may be updated to reflect the operation performed on that block (e.g., a new hash value, a new storage location, new metadata for the associated file, control or access transfer, identifier, or other action or added information). Although the values ​​in each block are shown as being separate from the metadata of the file and header data, in other embodiments, the values ​​may be based in part or in whole on this metadata.

[0141] At any point after the blockchain 670 is formed, an immutable archival record of a file may be obtained by querying the blockchain for the transaction history of values ​​across blocks. This query or tracking procedure may begin by decrypting the value of the last included block (e.g., the last (Nth) block), and then continue decrypting values ​​of other blocks until the genesis block is reached and the original file is recovered. Decryption may include decoding the header and file and associated metadata in each block.

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

[0143] Generating a key pair is similar to creating an account on the blockchain, but in reality, there is no need to register anywhere. Also, every transaction performed on the blockchain is digitally signed by the sender using the private key. This signature ensures that only the account owner (within the scope of permissions determined by the smart contract) can track and process files on the blockchain.

[0144] 7A and 7B illustrate additional use cases for blockchain that may be incorporated and used herein. In particular, FIG. 7A illustrates an example 700 of a blockchain 710 storing machine learning (artificial intelligence) data. Machine learning relies on large amounts of historical data (or training data) to build predictive models for accurate predictions on new data. Machine learning software (e.g., neural networks) can sift through millions of records to discover often non-intuitive patterns.

[0145] In the example of FIG. 7A , a host platform 720 builds and deploys machine learning models for predictive monitoring of assets 730. Here, the host platform 720 may be a cloud platform, an industrial server, a web server, a personal computer, a user device, etc. The assets 730 may be any type of asset (e.g., machinery or equipment), such as an aircraft, a locomotive, a turbine, medical equipment, oil and gas equipment, a boat, a ship, a vehicle, etc. As another example, the assets 730 may be intangible assets, such as stocks, currency, digital coins, insurance, etc.

[0146] The blockchain 710 can be used to significantly improve both the machine learning model training process 702 and the prediction process 704 based on the trained machine learning model. For example, in 702, historical data may be stored on the blockchain 710 by the asset 730 itself (or through an intermediary, not shown) rather than requiring a data scientist / engineer or other user to collect the data. This can significantly reduce the collection time required by the host platform 720 when performing predictive model training. For example, smart contracts can be used to transfer data directly and reliably from its original location to the blockchain 710. The smart contracts can send data directly from the asset to the individuals who use the data to build the machine learning model, using the blockchain 710 to ensure the security and ownership of the collected data. This enables data sharing between assets 730.

[0147] The collected data may be stored on the blockchain 710 based on a consensus mechanism. The consensus mechanism controls (authorized nodes) to ensure that the data being recorded is verified and accurate. The recorded data is time-stamped, cryptographically signed, and immutable. Therefore, the recorded data is auditable, transparent, and secure. Adding IoT devices that write directly to the blockchain can increase the frequency and accuracy of data recording in certain cases (i.e., supply chain, healthcare, logistics, etc.).

[0148] Furthermore, the training of the machine learning model on the collected data may undergo a series of refinements and tests by the host platform 720. Each refinement and test may be based on additional data or data not previously considered to help expand the machine learning model's knowledge. At 702, the host platform 720 may store the different training and testing steps (and associated data) on the blockchain 710. Each refinement of the machine learning model (e.g., changes in variables, weights, etc.) may be stored on the blockchain 710, thereby providing verifiable proof of how the model was trained and what data was used to train the model. Furthermore, when the host platform 720 achieves a final trained model, the resulting model may be stored on the blockchain 710.

[0149] After the model is trained, it may be deployed to a live environment, where predictions / decisions can be made based on the execution of the final trained machine learning model. For example, at 704, the machine learning model may be used for condition-based maintenance (CBM) for assets such as aircraft, wind turbines, and medical machinery. In this example, feedback data from the asset 730 may be input into the machine learning model and used to make event predictions such as failure events, error codes, and the like. Decisions made by the execution of the machine learning model on the host platform 720 may be stored on the blockchain 710 to provide auditable / verifiable proof. As one non-limiting example, the machine learning model may predict a future outage / failure in a part of the asset 730 and generate an alert or notification to replace the part. The data behind this decision may be stored on the blockchain 710 by the host platform 720. In one embodiment, the features and / or operations described and / or illustrated herein may occur on or with respect to the blockchain 710.

[0150] New transactions on the blockchain can be collected together in a new block and added to an existing hash value. This hash value is then encrypted to create a new hash for the new block. This new hash is added to the next list of transactions, such as when the transaction is encrypted. The result is a chain of blocks, each containing the hash values ​​of all preceding blocks. Computers storing these blocks periodically compare the hash values ​​of the blocks to ensure they all agree. Any computers that do not agree discard the offending record. While this method is good at ensuring the blockchain is tamper-proof, it is not perfect.

[0151] One way to game the system is for a malicious user to modify the list of transactions in a way that does not change the hash. This can be done through a brute force attack, in other words, by modifying the record, encrypting the result, and checking if the hash value is the same. If the hash value is not the same, try again and again until you find a matching hash. The security of blockchain is based on the idea that ordinary computers can only perform this type of brute force attack over completely impractical timescales, such as the age of the universe. Quantum computers, in contrast, are extremely fast (thousands of times faster) and therefore pose a much greater threat.

[0152] Figure 7B shows an example 750 of a quantum-secure blockchain 752 that implements quantum key distribution (QKD) to protect against quantum computing attacks. In this example, blockchain users can verify each other's identities using QKD, which uses quantum particles, such as photons, to transmit information that cannot be copied by an eavesdropper without being corrupted. In this way, senders and receivers can verify each other's identities via the blockchain.

[0153] In the example of Figure 7B, there are four users (754, 756, 758, and 760). Each pair of users can share a secret key 762 (i.e., QKD) between themselves. Because there are four nodes in this example, there are six pairs of nodes, and therefore, QKD AB , QKD AC , QKD AD , QKD BC , QKD BD , and QKD CDSix different private keys 762 are used, including: Each pair can create QKD by using quantum particles such as photons to transmit information, which cannot be copied by an eavesdropper without being corrupted. This way, pairs of users can verify each other's identities via the blockchain.

[0154] The operation of blockchain 752 is based on two steps: (i) transaction creation and (ii) the construction of blocks, which collect new transactions. New transactions may be created in the same way as in traditional blockchain networks. Each transaction may contain information about the sender, recipient, creation time, the amount (or value) being transferred, and a list of reference transactions that justify the sender's funds for the operation. This transaction record is then sent to all other nodes and entered into a pool of unconfirmed transactions. Here, two parties (i.e., a pair of users from 754-760) authenticate the transaction by providing a shared secret key 762 (QKD). This quantum signature is attached to every transaction, making it extremely difficult to tamper with. Each node checks the transaction entry against its local copy of blockchain 752 and verifies that each transaction has sufficient funds. However, the transaction is not yet confirmed.

[0155] Rather than performing a traditional mining process on blocks, blocks may be created in a decentralized manner using a broadcast protocol. Over a predetermined period of time (e.g., seconds, minutes, hours, etc.), the network may apply the broadcast protocol to any unconfirmed transactions, thereby achieving Byzantine consensus on the correct version of the transaction. For example, each node may possess a private value (that particular node's transaction data). First, the nodes send the private value to each other. Then, the nodes communicate the information they previously received from other nodes. Now, an authentic node can create the complete set of transactions in a new block. This new block can be added to the blockchain 752. In one embodiment, features and / or operations described and / or illustrated herein may occur in or with respect to the blockchain 752.

[0156] 8, there is shown a high-level block diagram of an exemplary computer system 800 that may be used to implement one or more of the methods, tools, and modules described herein, and any associated functionality, in accordance with embodiments of the present disclosure (e.g., using one or more processor circuits or computer processors of a computer). This computer system may, in some embodiments, be DPS 10, as previously described. In some embodiments, the major components of computer system 800 may include one or more CPUs 802, a memory subsystem 804, a terminal interface 812, a storage interface 816, an I / O (Input / Output) device interface 814, and a network interface 818, all of which may be communicatively coupled, directly or indirectly, for communication between components via a memory bus 803, an I / O bus 808, and an I / O bus interface unit 810.

[0157] Computer system 800 may include one or more programmable general-purpose central processing units (CPUs) 802A, 802B, 802C, and 802D, collectively referred to herein as CPUs 802. In some embodiments, computer system 800 may include multiple processors, as is typical in larger systems, while in other embodiments, computer system 800 may alternatively be a single-CPU system. Each CPU 802 may execute instructions stored in memory subsystem 804 and may include one or more levels of on-board cache.

[0158] System memory 804 may include computer system-readable media in the form of volatile memory, such as random access memory (RAM) 822 or cache memory 824. Computer system 800 may further include other removable / non-removable, volatile / non-volatile computer system storage media. By way of example only, a storage system 826 may be provided for reading from and writing to non-removable, non-volatile magnetic media, such as a "hard drive." Although not shown, a magnetic disk drive may be provided for reading from and writing to a removable, non-volatile magnetic disk (e.g., a "floppy disk"), or an optical disk drive may be provided for reading from or writing to a removable, non-volatile optical disk, such as a CD-ROM, DVD-ROM, or other optical media. Additionally, memory 804 may include flash memory (e.g., a flash memory stick drive or flash drive). Memory devices may be connected to memory bus 803 by one or more data media interfaces. The memory 804 may include at least one program product comprising a series of (eg, at least one) program modules configured to perform the functions of various embodiments.

[0159] One or more programs / utilities 828, each including at least one set of program modules 830, may be stored in memory 804. The programs / utilities 828 may include a hypervisor (also called a virtual machine monitor), one or more operating systems, one or more application programs, other program modules, and program data. Each of the operating system, one or more application programs, other program modules, and program data, or a combination thereof, may include an implementation of a network environment. The programs 828 and / or program modules 830 typically perform the functions or methods of the various embodiments.

[0160] 8 is depicted as a single bus structure providing a direct communication path between CPU 802, memory subsystem 804, and I / O bus interface 810, memory bus 803, in some embodiments, may include multiple distinct buses or communication paths, which may be arranged in any of a variety of forms, such as point-to-point links in a hierarchical, star, or web configuration, multiple hierarchical buses, redundant parallel paths, or any other suitable type of configuration. Furthermore, while I / O bus interface 810 and I / O bus 808 are each depicted as single units, computer system 800, in some embodiments, may include multiple I / O bus interface units 810, multiple I / O buses 808, or both. Furthermore, while multiple I / O interface units are depicted separating I / O bus 808 from the various communication paths reaching the various I / O devices, in other embodiments, some or all of the I / O devices may be directly connected to one or more system I / O buses.

[0161] In some embodiments, computer system 800 may be a multi-user mainframe computer system, a single-user system, or a server computer, or similar device that has little or no direct user interface but receives requests from other computer systems (clients). Further, in some embodiments, computer system 800 may be implemented as a desktop computer, a portable computer, a laptop or notebook computer, a tablet computer, a pocket computer, a telephone, a smartphone, a network switch or router, or any other suitable type of electronic device.

[0162] Figure 8 illustrates major representative components of an exemplary computer system 800. However, in some embodiments, individual components may be of greater or lesser complexity than those depicted in Figure 8, other or additional components may be present than those depicted in Figure 8, and the number, type, and configuration of such components may vary.

[0163] As described in further detail herein, it is contemplated that some or all of the operations of some embodiments of the methods described herein may be performed in a different order or not at all, and further, multiple operations may occur simultaneously or as part of a larger process.

[0164] Sustainable Tokens Given that environmentally conscious corporate goals are becoming increasingly important to organizations, many mechanisms that can help advance such goals are being considered. All supply chains involving physical goods require a means to move these goods and / or their constituent components from location A to location B, as well as potentially many intermediate locations. Like any mode of transportation, moving an object using a vehicle requires some kind of energy source, whether it be a gasoline-powered truck, a nuclear-powered ship, or an electric car.

[0165] Carbon dioxide (CO2) is recognized as one of the most pervasive greenhouse gases, and reductions in the release of this gas (among other things) into the atmosphere are considered essential to prevent global warming from reaching catastrophic levels. Most forms of transportation ultimately produce CO2. Even seemingly clean forms of transportation, such as electric vehicles, may not be completely clean. For example, electric vehicles may be associated with the production of some CO2 because the electricity used to charge the vehicle's battery may emit some CO2 into the atmosphere, as may the manufacturing of solar cells. However, it is clear that some forms of transportation emit less CO2 than others. Transportation that emits less CO2 is said to have a small carbon dioxide footprint, while transportation that emits more CO2 is said to have a large carbon dioxide footprint. All other factors being equal, it is desirable to consider having a smaller carbon dioxide footprint per unit of a good.

[0166] This disclosure addresses one method for helping reduce carbon emissions within supply chains: providing incentives in the form of rewards for using elements in the supply chain that have smaller carbon footprints. These incentives involve the creation and use of sustainable tokens that contain sustainable token value for the supply chain while maintaining confidentiality for participating parties. As used herein, a sustainable token is a cryptocurrency reward that can be offered to users, manufacturers, or other entities in the supply chain to encourage environmentally conscious activities. These sustainable tokens have the basic properties of being generated based on one or more factors related to carbon emissions, having business value, and being able to be earned by using the supply blockchain for transportation. However, it is important that confidential information is not available on-chain, and that the calculation of carbon emissions, as well as the allocation of earned tokens, is performed without data leakage (i.e., leaking private data to entities that should not have such data). Some embodiments may provide one or more advantages associated with the sustainable tokens and / or systems disclosed herein. Sustainable tokens may have monetary value and may be convertible to and from other currencies (both virtual and non-virtual), so they may be shareable between businesses. Sustainable tokens can help certify businesses as "climate-friendly," thus increasing their appeal to customers and other businesses. Sustainable tokens may be modified by shipping type, value, or other characteristics. Finally, using optimization services within the blockchain may result in more sustainable tokens as well as reduced costs. In some aspects, sustainable tokens may be similar to cryptocurrencies. Environmental organizations may partner with other organizations to process sustainable tokens as part of certification programs.

[0167] According to various embodiments disclosed herein, one or more of the following solution elements may be employed: A blockchain network administration may handle stakeholder membership management. Homologations (hereinafter referred to as "approvals" by a mandate, which may be a specific climate change organization) may be submitted for each transportation mode and carbon footprint standard by climate change organizations that meet certain criteria. A confidential token generation protocol may be provided that includes one or more manufacturers and transportation companies. The chain may be responsible for calculating the carbon footprint, generating tokens, and assigning tokens to entities. In some embodiments, when variables such as multiple orders, companies, and transportation modes are involved, the system may maximize token generation by optimizing these variables. Climate change organizations may be homologators (approvers) of data associated with carbon footprints, providing information about carbon footprints for each transportation mode to the blockchain network and granting membership certificates to transportation organizations.

[0168] 9 is a block diagram illustrating various components of a sustainable token system 900. The system 900 utilizes a blockchain network 910 as an electronic ledger for recording transactions. A controller 905 may be used to control, coordinate, and perform other functions related to the sustainable token system 900 described herein. The controller 905 may operate on a standalone system, interface with the blockchain network 910, or be integrated into the blockchain network 910. The controller 905 may be implemented, for example, in the DPS 10 described above.

[0169] In the following description, a use case is employed to illustrate various features of system 900, but the present invention should not be considered limited to the details set forth in this use case. In the use case, a first lumber manufacturer 920A (FirstCo) supplies wood to a customer 950 in the form of lumber as a physical product. A second lumber manufacturer 920B (SecondCo) supplies the same product. FirstCo primarily uses trucks 922A for transportation, and SecondCo primarily uses ships 922B for transportation. In this specification, when referring to elements collectively or representatively, reference numerals may be used without a suffix.

[0170] After the blockchain network 910 is established by the creator (not shown), each manufacturer 920 acquires an associated public key A PuK and private key A PrK may generate an address A in the blockchain network 910 along with a pair of private keys A and B. PrK is known only to each manufacturer 920. This procedure may be performed for each order or according to some predefined frequency to prevent linkability, which could potentially compromise confidentiality by allowing information from orders to be linked together. In a use case, a customer 950 may place an order O for 50 8-foot (2.44 m) 2-inch (5.08 cm) x 4-inch (10.16 cm) pieces to be delivered to Main Street 123 (location B, with FirstCo at location A). A manufacturer, such as FirstCo 920A, may determine certain information associated with order O that contains both public and private information. For example, the manufacturer may determine order public information O PuI may determine that the distance between location A and location B is 300 Km, the weight of the package is 100 Kg, and the container containing the product is 4 ft (1.22 m) x 4 ft (1.22 m) x 8 ft (2.44 m). PrIIt may further be determined that the order disclosure information O contains the order contents itself (products to be moved, contents, etc.). Such personal information may be disclosable only to relevant parties or parties with a "need to know". This may include the order disclosure information O containing necessary information (e.g., information needed to transport goods from location A to location B and / or information needed to calculate carbon footprint). PuI In other words, order personal information O PrI may partially or exclusively include information about the order that is not necessary for transportation and that is not necessary to determine the carbon footprint associated with the order.

[0171] The manufacturer (FirstCo420A in our use case) first creates a hash of the entire order personal information, H(O PrI ) and then generate a hash of the entire public order information, H(O PuI ) and generate a hash of the order public information H(O PuI ) is the hash of the order personal information H(O PrI ) Any form of secure hash may be used, such as MD5, SHA-2, and CRC32. PrK (H(O PuI )) and the signed order public information hash sH(O PuI ) (also referred to herein as a signature).

[0172] The manufacturer, FirstCo920A, then calculates the hash H(O PuI ), signature sH(O PuI), and the address of truck 922A to the transportation agency. The transportation agency may then fulfill the order O and submit the transaction to blockchain network 910 (e.g., as part of some automated function by the transportation agency, as part of an action performed by the transportation agency operator such as signing a delivery receipt, or by any other means consistent with this disclosure). A controller 905 associated with blockchain network 910 may then combine (a) the transportation agency's signature, the manufacturer's signature sh(O) on the order data, and PuI ), and address; (b) calculate the sustainable tokens earned based on the carbon dioxide consumption of the vehicle (and any other carbon dioxide-producing elements); and (c) allocate the sustainable tokens to the specified address. The allocation of the sustainable tokens may be recorded on the blockchain ledger.

[0173] To ensure that appropriate certification of carbon dioxide emissions is used, various climate change entities 924 may provide carbon dioxide emission information to the controller 905 of the blockchain network 910. For example, a first climate change entity 924A may provide a carbon dioxide emission standard for a shipment that is a truck 922A to a trucking organization using truck 922A, and a second climate change entity 924B may provide a carbon dioxide emission standard for a shipment that is a vessel 922B to a shipping organization using vessel 922B. Such information may be based on engine size, payload, age, etc., and may take into account various factors related to the vehicle, route information, etc.

[0174] In addition to providing carbon footprint information to controller 905, climate change organization 924 may further provide approval and / or certification that the information associated with the vehicle is correct. Vehicle 922 may transmit information regarding the dispatch and status of order O. Upon completion, vehicle 922 may transmit that information to controller 905 on the blockchain network, which then assigns sustainable tokens to factory 920 determined taking into account the dispatch and status of order O, along with the carbon footprint information provided by climate change organization 924A.

[0175] As an example, consider the following use case: Sustainable tokens may be awarded based on a reduction (or negative change) in CO2 emissions. To measure the change, a reference unit and a reference measurement result may be established, defining a predefined baseline carbon dioxide emission. For example, the reference unit may be CO2 mass per distance per payload weight (e.g., kilograms (Kg) of CO2 per kilometer (Km) per Kg of payload). In this way, a more efficient propulsion mechanism may reduce the carbon dioxide emission for travel between location A and location B. To illustrate using the previous example, FirstCo 920A may utilize truck 922A as a transportation vehicle. At the baseline level, it has been determined, as is FirstCo's standard operating procedure, that the truck emits 1.5 Kg of CO2 per Km for a 10,000 Kg payload when using regular gasoline. Therefore, a 300Km shipment of a 100Kg order O between location A and location B (assuming the vehicle is carrying a maximum payload of 10,000Kg) will produce the following CO2 emissions:

[0176]

number

[0177] The "value" of a sustainable token may be established arbitrarily, e.g., 1 sustainable token = 1 Kg of CO2 saved. This value is arbitrary because the sustainable token value has a conversion value into units of real currency, e.g., 1 sustainable token may at some point have a conversion rate of 5 USD.

[0178] Continuing with this example, it can be discovered that by using ethanol-based gasoline, the truck's emissions under the same conditions will be reduced to only 1.2 Kg of CO2. In other words, using an ethanol-based truck to dispatch order O will produce the following CO2 emissions:

[0179]

number

[0180] The difference in CO2 emissions between using regular gasoline and using ethanol-based gasoline for this order O is 0.9 Kg of CO2, which, using the figures above, results in a sustainable token value of 0.9, which may be transferred to the blockchain 910 entity, i.e., either the transportation agency of truck 922A or FirstCo 920A, depending on the agreement between the parties involved. The use of electric vehicles may result in even greater savings, but likely not 100% savings, as generating electricity to charge the electric vehicle's battery or to manufacture solar cells may still generate some amount of carbon dioxide that must be taken into account in calculating the carbon footprint.

[0181] Standard levels may be established for a particular transportation agency 922 (to incentivize the transportation agency to find carbon dioxide reduction strategies), a particular manufacturer 920 (to incentivize the transportation agency to use the transportation mode with the lowest carbon dioxide emissions), an entire industry (to maximize competition in finding the transportation mode with the lowest carbon dioxide emissions), or any other criteria that may help improve the reduction of CO2 emissions.

[0182] In addition to improvements in vehicle efficiency as described above, various creditable factors of change may be considered in determining savings (in terms of carbon dioxide emissions differential). Route improvements may be considered. For example, if a new route between location A and location B is discovered that reduces the distance from 300 km to 250 km, a sustainable token credit reflecting this reduction in distance may be applied. In another example, staging improvements may be considered. Assume a baseline is based on half the standard maximum payload (e.g., 5,000 kg). If customer 950, manufacturer 920, or fleet 922, or a combination thereof, is willing to accept a delay until, for example, truck 922A's 10,000 kg maximum payload can be acquired, the sustainable token credit may also reflect this. In another example, coordination improvements may be considered. If a manufacturer is willing to coordinate and share a particular fleet, the resulting reduction in CO2 emissions will be awarded sustainable tokens reflecting the savings. For example, if customer 950 places an order 1 O1 with FirstCo 920A and an order 2 O2 with SecondCo 920B, and if FirstCo 920A and SecondCo 920B are located in close proximity (or simply in such a way that the combined shipments would save CO2 emissions), FirstCo 920A and SecondCo 920B can agree to use a particular vehicle (truck 922A) to ship both O1 and O2 to customer 950, thereby reducing total CO2 emissions (resulting in sustainable tokens).

[0183] Although a very simple illustration was used above, it is also possible to consider determining more complex solutions, such as using multiple transports for a particular order O, performing multiple combinations, and rearranging all orders O to be dispatched.

[0184] 10 is a flowchart of example processes 1000, 1050 according to some embodiments. The first process 1000 includes operations that may be performed by the manufacturer 920, and the second process 1050 includes operations that may be performed by the controller 905.

[0185] At operation 1005 of the first process 1000, the manufacturer 920 may issue an order request based on an order received by the manufacturer 920 from the customer 950. At operation 1010, the manufacturer 920 may generate an address in the blockchain network 910 along with a public key and a private key, the private key being held by the manufacturer 920. At operation 1015, the manufacturer 920 may generate a hash of the order public information and a hash of the order personal information. At operation 1020, the manufacturer 920 may further generate a signature of the hash based on the address private key. The manufacturer 920 may then send the order request, along with the hash, signature, and address in the blockchain network 910, to a transportation agency 922.

[0186] At operation 1055 of second process 1050, controller 905 in blockchain network 910 receives an indication from transportation agency 922 that the order has been fulfilled (i.e., delivery of the product has occurred). Controller 905 validates the transaction sent by transportation agency 922, which includes the transportation agency's signature and the manufacturer's signature over the order data and address. Next, at operation 1060, the controller calculates earned sustainable tokens based on the difference in carbon dioxide consumption from the baseline, and at operation 1065, assigns the earned sustainable tokens to the address received by the controller to award to the entity based on the improvement in carbon dioxide emissions.

[0187] Technical Applications Accordingly, one or more embodiments disclosed herein provide improvements to computer technology, such as improvements to digital transaction ledgers and systems that use sustainable tokens while protecting confidentiality, allowing for more efficient and effective documentation of computer transactions, including greater security, and encouraging a reduction in carbon emissions.

[0188] Computer-readable medium The present invention may be a system, a method, and / or a computer-readable medium at any possible level of technical detail of integration. A computer program product may include a computer-readable storage medium containing computer-readable program instructions for causing a processor to perform aspects of the present invention.

[0189] A computer-readable storage medium can be a tangible device that can hold and store instructions for use by an instruction execution device. A computer-readable storage medium can be, for example, but is not limited to, an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination thereof. A non-exhaustive list of more specific examples of computer-readable storage media includes portable floppy disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), static random access memory (SRAM), portable compact disk read-only memory (CD-ROM), digital versatile disk (DVD), memory stick, floppy disk, mechanically encoded devices such as punch cards or ridge-in-groove structures on which instructions are recorded, and any suitable combination thereof. As used herein, a computer-readable storage medium should not itself be construed as a transitory signal such as an electric wave or other freely propagating electromagnetic wave, an electromagnetic wave propagating through a waveguide or other transmission medium (e.g., a light pulse passing through a fiber optic cable), or an electrical signal transmitted over a wire.

[0190] The computer-readable program instructions described herein may be downloaded from a computer-readable storage medium to each computing / processing device or to an external computer or storage device over a network (e.g., the Internet, a local area network, a wide area network, and / or a wireless network). This network may include copper transmission cables, optical fiber transmissions, wireless transmissions, routers, firewalls, switches, gateway computers, and / or edge servers. A network adapter card or network interface within each computing / processing device receives the computer-readable program instructions from the network and forwards the computer-readable program instructions for storage on a computer-readable storage medium within each computing / processing device.

[0191] Computer-readable program instructions for carrying out the operations of the present invention may be source or object code written in any combination of one or more programming languages, including assembler instructions, instruction set architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, state setting data, configuration data for integrated circuits, or object-oriented programming languages ​​such as Smalltalk®, C++, and procedural programming languages ​​such as the "C" programming language or similar programming languages. The computer-readable program instructions may execute entirely on the user's computer, partially on the user's computer as a standalone software package, partially on the user's computer and on a remote computer, or entirely on a remote computer or server. In the latter scenario, the remote computer may be connected to the user's computer via any type of network, including a local area network (LAN) or a wide area network (WAN), or the connection may be to an external computer (e.g., via the Internet using an Internet Service Provider). In some embodiments, to carry out aspects of the present invention, electronic circuitry including, for example, a programmable logic circuit, a field programmable gate array (FPGA), or a programmable logic array (PLA), may execute computer readable program instructions to customize the electronic circuitry by utilizing state information of the computer readable program instructions.

[0192] Aspects of the present invention are described herein with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer-readable program instructions.

[0193] These computer-readable program instructions may be provided to a processor of a general-purpose computer, special-purpose computer, or other programmable data processing apparatus to create a machine, where the instructions, executed by the processor of the computer or other programmable data processing apparatus, create means for performing the functions / acts specified in the blocks of the flowcharts and / or block diagrams. These computer-readable program instructions may be stored on a computer-readable storage medium and capable of directing a computer, programmable data processing apparatus, or other device, or combination thereof, to function in a particular manner, such that the computer-readable storage medium on which the instructions are stored comprises an article of manufacture containing instructions that implement aspects of the functions / acts specified in the blocks of the flowcharts and / or block diagrams.

[0194] Computer-readable program instructions may be loaded into a computer, other programmable data processing apparatus, or other device such that the instructions, which execute on the computer, other programmable apparatus, or other device, perform the functions / acts specified in the flowchart and / or block diagram blocks, thereby causing a series of operable steps to be performed on the computer, other programmable apparatus, or other device to produce a computer-implemented process.

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

Claims

1. 1. A computer-implemented method for a security token generation protocol, comprising: initiating an order request, the order request including public order information and personal order information related to the order; generating an address in a blockchain network using the private key; generating a hash of data incorporating the order personal information and a signature of the hash, wherein the signature of the hash is generated using the private key; sending the order request, including the address, the hash, and the signature, to a vehicle associated with the order; Identifying that the vehicle has fulfilled the order request; A computer-implemented method for performing

2. The computer-implemented method of claim 1 , wherein the hash is generated to incorporate order disclosure information.

3. the processor: receiving the order; using information in said order in said order; The computer-implemented method of claim 1 , further comprising:

4. The computer-implemented method of claim 1 , wherein the order personal information includes information about the order that is not necessary for transportation or for determining a carbon footprint associated with the order.

5. the processor: receiving a token value associated with the order from the blockchain network; The computer-implemented method of claim 1 , further comprising:

6. The computer-implemented method of claim 5 , wherein the token value is a sustainable token value related to a carbon footprint associated with the order.

7. 7. The computer-implemented method of claim 6, wherein the sustainable token value is based on a carbon footprint differential that is the difference between a carbon footprint created by fulfilling the order and a baseline carbon footprint.

8. 8. The computer-implemented method of claim 7, wherein the carbon dioxide emissions differential is based on factors selected from the group consisting of improved vehicle efficiency, improved routing, improved staging, and improved coordination.

9. the processor: generating a second hash of the order personal information; including the second hash in the hash; The computer-implemented method of claim 1 , further comprising:

10. 2. The computer-implemented method of claim 1, wherein the hash is selected from the group consisting of MD5, SHA-2, and CRC32.

11. 1. A computer-implemented method for a security token generation protocol, comprising: receiving order information related to an order requiring the use of a transportation facility, the order information including an address within a blockchain network; validating that the vehicle has fulfilled the order; and calculating a token value associated with the vehicle, the token value being related to a carbon footprint of the vehicle for transporting the order; assigning said token value to said address; A computer-implemented method for performing

12. The computer-implemented method of claim 11 , wherein the token value relates to a difference in carbon dioxide emissions between a carbon dioxide emissions for shipping the order and a predefined baseline carbon dioxide emissions.

13. the processor: receiving carbon dioxide emissions information associated with the transportation from a climate change organization; using said carbon footprint information in said assigning said token values; The computer-implemented method of claim 11 , further comprising:

14. 12. The computer-implemented method of claim 11, wherein the carbon dioxide emissions difference is based on factors selected from the group consisting of improved vehicle efficiency, improved routing, improved staging, and improved coordination.

15. the processor: recording the allocation of the token values ​​as a transaction on the blockchain. The computer-implemented method of claim 11 , further comprising:

16. a manufacturer system; Blockchain Controller and 1. A system for implementing a security token, comprising: The system comprises: Using a processor of the blockchain controller, receiving order information related to an order requiring the use of a transportation facility, the order information including an address within a blockchain network; validating that the vehicle has fulfilled the order; and calculating a token value associated with the vehicle, the token value being related to a carbon footprint of the vehicle for transporting the order; assigning said token value to said address; Run using a processor of said manufacturer system; initiating an order request, the order request including public order information and personal order information regarding the order; generating said address in a blockchain network using a private key; generating a hash of data incorporating the order personal information and a signature of the hash, wherein the signature of the hash is generated using the private key; sending the order request, including the address, hash, and signature, to the transportation facility; Identifying that a vehicle has fulfilled the order request; A system configured to run

17. and wherein the system further comprises: using a processor of the vehicle; receiving certification from a climate change organization; transmitting information associated with completing the transportation of the order; The system of claim 16 , further configured to:

18. the processor of the manufacturer system: receiving the order; using information in said order in said order; receiving a token value associated with the order from the blockchain network; 20. The system of claim 17, further configured to:

19. the token value is a sustainable token value related to a carbon footprint associated with the order; the sustainable token value is based on a carbon footprint differential that is the difference between a carbon footprint created by fulfilling the order and a baseline carbon footprint; 20. The system of claim 17, wherein the carbon dioxide emissions differential is based on factors selected from the group consisting of improved vehicle efficiency, improved routing, improved staging, and improved coordination.

20. 20. The system of claim 19, wherein the processor of the blockchain controller is further configured to record the assignment of the token value in the blockchain.

Images