Dynamic rights assignment and enforcement for transport processes

Abstract

Exemplary operations can include one or more of receiving shipping data for a multi-party shipping process, identifying documents and events associated with the multi-party shipping process based on the received shipping data, dynamically determining read and write permissions to the documents and events of the multi-party shipping process based on predefined roles, and storing an identifier of the multi-party shipping process and the dynamically determined read and write permissions in a block on a blockchain.

Description

TECHNICAL FIELD

[0001] The present application relates generally to storing data on a blockchain, and more specifically, to a system for dynamically determining permissions of parties in a multi-party transport process based on roles and managing access to transport data based on the permissions. BACKGROUND

[0002] A centralized database stores and maintains data in a single database (e.g., database server) that is at one location. The location is often a central computer, such as a desktop central processing unit (CPU), a server CPU, or a mainframe computer. The information stored on a centralized database is typically accessible from multiple different points. Multiple users or client workstations can work on the centralized database simultaneously, such as based on a client / server configuration. Centralized databases are easy to manage, maintain, and control due to their single location, especially for security purposes. Within a centralized database, data redundancy is minimized because a given set of data has only one master record.

[0003] However, centralized databases have significant drawbacks. For example, centralized databases have a single point of failure if there are no fault-tolerant considerations. Thus, if a hardware failure occurs (e.g., a hardware, firmware, and / or software failure), all data within the database is lost and all users’ work is interrupted. Additionally, centralized databases are highly dependent on network connectivity. Thus, the slower the connection, the greater the amount of time required for each database access. Another drawback is that centralized databases experience bottlenecks when they experience high traffic due to the single location. Furthermore, centralized databases provide limited access to data because the database only maintains one copy of the data.

[0004] Organizations have recently turned to blockchains as a means for securely storing data that is not limited by a central entity and is accessible from multiple points. In a blockchain network, peers are responsible for collectively managing and storing data on the blockchain. The blockchain can be stored on a ledger that can be distributed / copied among the blockchain peers. The blockchain provides a new mechanism for securing interactions of non-trusted parties by using a decentralized architecture.

[0005] At the same time, the shipping / transportation ecosystem makes a huge contribution to the global economy. For example, since the containerization revolution, the transportation industry has grown to an astonishing size and encompasses ships / barges, trucks, trains, aircraft, and any other means of moving goods from one geographic location to another. However, like most things of this size, the industry has developed significant inefficiencies and complexities. For example, communication between parties can be difficult because many parties do not deal directly with each other. Additionally, parties have different priorities in most transactions, which creates vastly different goals / points of view. The transportation process is also subject to fraud and wasted time / resources, especially because paper documents are still relied upon as proof. Thus, what is needed is a solution that overcomes these shortcomings and limitations. SUMMARY

[0006] One example embodiment provides an apparatus comprising one or more of: a network interface configured to receive shipping data for a multi-party shipping process; and a processor configured to one or more of: identify documents and events associated with the multi-party shipping process based on the received shipping data; dynamically determine read and write permissions to the documents and events of the multi-party shipping process based on predefined roles; and store an identifier for the multi-party shipping process and the dynamically determined read and write permissions in a block on a blockchain.

[0007] Another example embodiment provides a method comprising one or more of: receiving shipping data for a multi-party shipping process; identifying documents and events associated with the multi-party shipping process based on the received shipping data; dynamically determining read and write permissions to the documents and events of the multi-party shipping process based on predefined roles; and storing an identifier for the multi-party shipping process and the dynamically determined read and write permissions in a block on a blockchain.

[0008] A further example embodiment provides a non-transitory computer-readable medium comprising instructions that, when read by a processor, cause the processor to perform one or more of: receiving shipping data for a multi-party shipping process; identifying documents and events associated with the multi-party shipping process based on the received shipping data; dynamically determining read and write permissions to the documents and events of the multi-party shipping process based on predefined roles; and storing an identifier for the multi-party shipping process and the dynamically determined read and write permissions in a block on a blockchain.

[0009] From a first aspect, the invention provides an apparatus comprising: a network interface configured to receive shipping data for a multi-party shipping process; and a processor configured to: identify documents and events associated with the multi-party shipping process based on the received shipping data; dynamically determine read and write permissions to the documents and events of the multi-party shipping process based on predefined roles; and store an identifier for the multi-party shipping process and the dynamically determined read and write permissions in a block on a blockchain.

[0010] Preferably, the invention provides an apparatus wherein the processor is configured to derive permissions of parties included in the multi-party shipping process to read and write data to the blockchain based on predefined roles of the parties mapped to the multi-party shipping process by chaincode of the blockchain.

[0011] Preferably, the invention provides an apparatus wherein the processor is further configured to receive a request to access one or more of the documents and events of the multi-party shipping process and grant the request based on the dynamically determined read and write permissions stored in the blockchain.

[0012] Preferably, the invention provides an apparatus wherein the processor is further configured to receive a request to access one or more of the documents and events of the multi-party shipping process and deny the request based on the dynamically determined read and write permissions stored in the blockchain.

[0013] Preferably, the invention provides an apparatus wherein the processor determines the read and write permissions based on an origin, a destination, and one or more intermediate locations of the multi-party shipping process.

[0014] Preferably, the invention provides an apparatus wherein the network interface is further configured to receive event data updates for the multi-party process and store the event data updates and read and write permissions to the event data updates in a block on the blockchain.

[0015] Preferably, the invention provides an apparatus wherein the event data updates comprise modifications to previously stored documents.

[0016] Preferably, the invention provides an apparatus wherein the event data updates comprise modifications to previously determined read and write permissions to events and their data.

[0017] Viewed from another perspective, the present invention provides a method comprising: receiving shipping data for a multi-party shipping process; identifying documents and events associated with the multi-party shipping process based on the received shipping data; dynamically determining read and write permissions to the documents and events of the multi-party shipping process based on predefined roles; and storing an identifier for the multi-party shipping process and the dynamically determined read and write permissions in a block on a blockchain.

[0018] Preferably, the present invention provides a method wherein the dynamically determining comprises deriving permissions of parties included in the multi-party shipping process to read and write data to the blockchain based on predefined roles of the parties mapped to the parties by chaincode of the blockchain.

[0019] Preferably, the present invention provides a method further comprising receiving a request to access one or more of the documents and events of the multi-party shipping process, and authorizing the request based on the dynamically determined read and write permissions stored in the blockchain.

[0020] Preferably, the present invention provides a method further comprising receiving a request to access one or more of the documents and events of the multi-party shipping process, and denying the request based on the dynamically determined read and write permissions stored in the blockchain.

[0021] Preferably, the present invention provides a method wherein the dynamically determining the read and write permissions is further based on an origin, a destination, and one or more intermediate locations of the multi-party shipping process.

[0022] Preferably, the present invention provides a method further comprising receiving an event data update for the multi-party process, and storing the event data update and read and write permissions to the event data update in a block on the blockchain.

[0023] Preferably, the present invention provides a method wherein the event data update comprises a modification to a previously stored document.

[0024] Preferably, the present invention provides a method wherein the event data update comprises a modification to a previously determined read and write permissions to an event and data thereof.

[0025] Viewed from another aspect, the present application provides a non-transitory computer readable medium comprising instructions that, when read by a processor, cause the processor to perform a method comprising: receiving shipping data for a multi-party shipping process; identifying documents and events associated with the multi-party shipping process based on the received shipping data; dynamically determining read and write permissions to the documents and events of the multi-party shipping process based on predefined roles; and storing an identifier of the multi-party shipping process and the dynamically determined read and write permissions in a block on a blockchain.

[0026] Preferably, the present application provides a non-transitory computer readable medium wherein the dynamically determining comprises deriving permissions of parties included in the multi-party shipping process to read and write data to the blockchain based on predefined roles of the parties mapped by chaincode of the blockchain.

[0027] Preferably, the present application provides a non-transitory computer readable medium wherein the method further comprises receiving a request to access one or more of the documents and events of the multi-party shipping process, and granting the request based on the dynamically determined read and write permissions stored in the blockchain.

[0028] Preferably, the present application provides a non-transitory computer readable medium wherein the method further comprises receiving a request to access one or more of the documents and events of the multi-party shipping process, and denying the request based on the dynamically determined read and write permissions stored in the blockchain. BRIEF DESCRIPTION OF DRAWINGS

[0029] Figure 1 is an illustration showing a trade ecosystem for managing shipments and their associated milestones (events and documents) in accordance with an example embodiment.

[0030] Figure 2A is an illustration showing a blockchain architecture configuration in accordance with an example embodiment.

[0031] Figure 2B is an illustration showing a blockchain transaction flow in accordance with an example embodiment.

[0032] Figure 3A is an illustration showing a permissioned blockchain network in accordance with an example embodiment.

[0033] Figure 3B is an illustration showing another permissioned blockchain network in accordance with an example embodiment.

[0034] Figure 3C is an illustration showing an un-permissioned blockchain network in accordance with an example embodiment.

[0035] Figure 4A is an illustration showing a service of a host platform for assigning permissions and controlling access, according to an example embodiment.

[0036] Figure 4B is an illustration showing a mapping between participant types and participant roles, according to an example embodiment.

[0037] Figure 4C is an illustration showing a table for storing access rights to documents based on roles, according to an example embodiment.

[0038] Figure 4D is an illustration showing a process for dynamically determining read and write permissions to documents and events, according to an example embodiment.

[0039] Figure 5 is an illustration showing a method for dynamically determining read and write permissions, according to an example embodiment.

[0040] Figure 6A is an illustration showing an example system configured to perform one or more operations described herein, according to an example embodiment.

[0041] Figure 6B is an illustration showing another example system configured to perform one or more operations described herein, according to an example embodiment.

[0042] Figure 6C is an illustration showing another example system configured to utilize a smart contract, according to an example embodiment.

[0043] Figure 6D is an illustration showing yet another example system configured to utilize a blockchain, according to an example embodiment.

[0044] Figure 7A is an illustration showing a process for adding a new block to a distributed ledger, according to an example embodiment.

[0045] Figure 7B is an illustration showing content of a new data block, according to an example embodiment.

[0046] Figure 7C is an illustration showing a blockchain for digital content, according to an example embodiment.

[0047] Figure 7D is an illustration showing a block that can represent a block in a blockchain, according to an example embodiment.

[0048] Figure 8Ais an illustration showing an example blockchain storing machine learning (artificial intelligence) data, according to an example embodiment.

[0049] Figure 8B is an illustration showing an example quantum secure blockchain, according to an example embodiment.

[0050] Figure 9 is an illustration showing an example system supporting one or more of the example embodiments. DETAILED DESCRIPTION

[0051] It will be readily understood that the components, as generally described and illustrated in the figures herein, can be arranged and designed in a wide variety of different configurations. Thus, the following detailed description, which describes at least one embodiment of a method, apparatus, non-transitory computer readable medium, and system as represented in the figures, is not intended to limit the scope of the present application, but is merely representative of selected embodiments.

[0052] In one or more embodiments, the current features, structures, or characteristics as described throughout this specification can be combined or removed in any suitable manner. For example, the use of the phrases “example embodiment,” “some embodiments,” or other similar language throughout this specification refers to the fact that a particular feature, structure, or characteristic being described can be included in at least one embodiment. Thus, the appearance of the phrases “example embodiment,” “in some embodiments,” “in other embodiments,” or other similar language throughout this specification does not necessarily refer to the same group of embodiments, and the described features, structures, or characteristics can be combined or removed in any suitable manner in one or more embodiments. Additionally, in the illustrations, any connections between elements are meant to permit one-way and / or two-way communication, even if the depicted connection is a one-way or two-way arrow. Also, any device depicted in the drawings can be a different device. For example, if a mobile device is shown as sending information, a wired device can also be used to send the information.

[0053] Additionally, while the term “message” can have been used in the description of embodiments, the present application can apply to many types of networks and data. Moreover, while certain types of connections, messages, and signaling can be depicted in example embodiments, the present application is not limited to a type of connection, message, and signaling.

[0054] Example embodiments provide methods, systems, components, non-transitory computer readable media, devices, and / or networks for dynamically determining read and write permissions to data of a multi-party shipping process and controlling access to the data based on the dynamically determined permissions via a blockchain.

[0055] In one embodiment, the present application utilizes a decentralized database, such as a blockchain, which is a distributed storage system that includes multiple nodes that communicate with each other. The decentralized database includes an append-only immutable data structure that is similar to a distributed ledger that is capable of maintaining records between mutually untrusted parties. The untrusted parties are referred to herein as peers or peer nodes. Each peer maintains a copy of the database records, and a single peer cannot modify the database records without consensus among the distributed peers. For example, the peers can execute a consensus protocol to validate blockchain storage transactions, group the storage transactions into blocks, and build a chain of hashes on the blocks. To be consistent, the process forms a ledger by ordering the storage transactions, if necessary. In various embodiments, permissioned and / or permissionless blockchains can be used. In a public or permissionless blockchain, anyone can participate without a specific identity. The public blockchain can involve native cryptocurrencies and use consensus based on various protocols, such as proof of work (PoW). On the other hand, a permissioned blockchain database provides secure interactions among a group of entities that have a common goal but do not fully trust each other, such as businesses that exchange funds, goods, information, and the like.

[0056] The present application can utilize a blockchain that operates any programmable logic, customized for a decentralized storage scheme, and referred to as a“smart contract” or“chaincode.” In some cases, there can be a special chaincode for managing functions and parameters, which is referred to as a system chaincode. The present application can also utilize a smart contract, which is a trusted distributed application that utilizes the tamper-proof nature of the blockchain database and the underlying agreement among the nodes, which is referred to as endorsement or endorsement policy. Blockchain transactions associated with the present application can be“endorsed” before being submitted to the blockchain, and unendorsed transactions will be ignored. The endorsement policy allows the chaincode to specify endorsers of a transaction in the form of a set of peer nodes required for endorsement. When a client sends a transaction to the peers specified in the endorsement policy, the transaction is executed to validate the transaction. After validation, the transaction enters an ordering phase, in which a consensus protocol is used to produce an ordered sequence of endorsed transactions that are grouped into blocks.

[0057] The present application can utilize nodes that are communication entities of a blockchain system. A "node" can perform logical functions in the sense that different types of multiple nodes can run on the same physical server. Nodes are grouped in trust domains and associated with logical entities that control them in various ways. Nodes can include different types, such as a client or submitting client node that submits transaction invocations to endorsers (e.g., peers) and broadcasts transaction proposals to an ordering service (e.g., an ordering node). Another type of node is a peer node that can receive transactions submitted by clients, commit transactions, and maintain a state and copy of a ledger of blockchain transactions. A peer can also play the role of an endorser, but this is not required. An ordering service node or orderer is a node that runs a communication service for all nodes and implements delivery guarantees, such as broadcast to each of the peer nodes in the system when committing transactions and modifying the world state of the blockchain, which is another name for the initial blockchain transaction that typically includes control and setup information.

[0058] The present application can utilize a ledger that is an immutable, ordered record of all state transitions of a blockchain. State transitions can result from chaincode invocations (i.e., transactions) submitted by participants (e.g., client nodes, ordering nodes, endorser nodes, peer nodes, etc.). Each participant, such as a peer node, can maintain a copy of the ledger. Transactions can cause a set of asset key-value pairs to be committed to the ledger as one or more operations (such as create, update, delete, etc.). The ledger includes a blockchain (also referred to as a chain) for storing immutable, ordered records in blocks. The ledger also includes a state database that maintains the current state of the blockchain.

[0059] The present application can utilize a chain that is a transaction log structured as a hash-linked sequence of blocks, and each block contains a sequence of N transactions, where N is equal to or greater than one. A block header includes a hash of the transactions of the block, and a hash of the header of the previous block. In this way, all transactions on the ledger can be ordered and cryptographically linked together. Thus, it is not possible to tamper with the ledger data without breaking the hash link. The hash of a recently added blockchain block represents every transaction on the chain that appears before it, thereby ensuring that all peer nodes are in a consistent and trusted state. The chain can be stored on a peer node file system (i.e., local, attached storage, cloud, etc.), thereby efficiently supporting the append-only nature of blockchain workloads.

[0060] The current state of the immutable ledger represents the latest values of all keys included in the chain transaction log. Since the current state represents the latest key values known by the channel, it is sometimes referred to as the world state. Chaincode calls perform transactions against the current state data of the ledger. To make these chaincode interactions efficient, the latest values of keys can be stored in a state database. The state database can simply be an indexed view of the chain transaction log, so it can be regenerated from the chain at any time. The state database can be restored (or generated, if needed) automatically at peer startup and before transactions are accepted.

[0061] The global trade ecosystem makes a huge contribution to the global economy. For example, sea shipping is one of the most critical means of trade in goods. The trade ecosystem has grown to an astonishing size since the containerization revolution of the 1960s, but like most things of great size, the trade ecosystem has developed inefficiencies and complexity. These inefficiencies come from trying to create point-to-point connections between all the different parties involved, data that can be trapped in silos, vastly different views of transactions, and processes that are subject to fraud and wasted time. It has been supported under the burden of paper processes that have always inhibited innovation and speed.

[0062] There are two main types of data related to managing global trade, including shipment milestones (referred to herein as events) and trade documentation. Milestones can include various steps of a container's journey, such as a projected arrival date determined before the container actually moves, the time the container is sealed at the point of origin, the air temperature to which the container is exposed at various points in the journey, and the like. These examples are just a few of the many milestones that are critical to the supply chain ecosystem to plan and execute a shipment. Equally critical are the documents that formally define and authorize a shipment. Documents include the packing list and bill of lading documents and a variety of documents that vary by region and trade route. This documentation plays a central role in the supply chain.

[0063] Sea shipping (and other forms of transportation) is quite competitive and highly regulated. Carriers must trust that the participating platform will not put them at risk of competition or regulation. For example, a sea shipping carrier can generate critical documents that others will use (e.g., bills of lading, sea waybills, etc.). In the same way, other participants on the network need to present documents and guarantee that only the correct parties have access to them. Examples of private information include, but can not be limited to, shipment participants, documents, detailed location data (addresses), and the like. What is needed is a way to share data with all participants on the ecosystem while maintaining the security of confidential or private information and only accessible or changeable by the correct parties.

[0064] Exemplary embodiments provide a system that can dynamically assign permissions to participants (e.g., organizations, etc.) involved in a multi-party transport process. The system can store predefined roles that are mapped to different participant types. When a participant is identified as being part of a process, the system can determine the participant's role for that particular process, and dynamically assign read and write permissions to documents and event data of the process based on the determined role. The role assigned to a participant can differ based on the participant's position in the process. Thus, the system can dynamically determine a participant's role based on the particular details of the process at runtime, and assign read / write permissions accordingly. Moreover, the system can store such permissions to a blockchain, such that it is stored securely / immutable, and can be accessed across different locations / points in the network. When new data becomes available, the permissions on the blockchain can be updated to reflect the changed data, and permissions can be updated / assigned accordingly. When a participant (or a user thereof) attempts to access data, the blockchain can enforce access permissions, thereby preventing unauthorized access to data, while also providing a convenient mechanism for different parties to view data.

[0065] The systems described herein support global trade permissions and controlled access to data, resources, and documents in a dynamic and automated manner, without the need to define access in a point-to-point manner for participants involved in a process. Exemplary embodiments combine the concept of a role that each party can assume in a given shipment with the types of documents and event types that each role can produce / access. Moreover, the system can derive access controls that need to be enforced at runtime for each user accessing each document or piece of data. For example, to determine a given participant's access to trade information, including milestones and documents, the system can determine access controls from information about the participant's role in a given shipment. During runtime, various policy services enforce permissions such that each party can only see allowed data. In some embodiments, the system can enable a transport service to override permissions for a given shipment, allow an uploader of a document to adjust permissions based on their preferences, support access controls for each level of a shipment hierarchy, etc.

[0066] Some of the benefits of the system described herein include providing access to data for multiple parties without having to create a one-to-one connection with each of the parties involved. As a result, there are many advantages for the parties, including end-to-end visibility across the shipment corridor and real-time access to information, resulting in rich port collaboration and improved dock planning. The system also provides digital audit trail of shipment events and documents, which reduces customer service and network integration costs and reduces misdeclarations of cargo. The system also provides shared and digitized import / export information, which results in more reliable risk assessment, less paperwork, and easier connection to national platforms. The system also provides real-time access to supply chain events of a shipment and provides improved asset planning and utilization for overland transportation, reducing bottlenecks. Additionally, with streamlining across the entire supply chain, predictability is significantly improved, allowing for earlier notification of issues and reduced inventory. The system also provides the efficacy of tracking and traceability tools, which allows for improved customs brokerage tools. Furthermore, the use of blockchain provides an immutable source of information for trade finance, providing access to real-time data for financial services.

[0067] As described further herein, participants can be dynamically authorized for access to blockchain data, such as event data (milestones) and documents associated with a multi-party transportation process. As described herein, the term “transportation” should be understood to mean any method of transporting goods or commodities, including ocean / ship, rail / train, highway / truck, air / aircraft, etc.

[0068] Examples of participant types include, but are not limited to, a cargo owner, an agent, a marine carrier, a transportation intermediary, an overland carrier, a terminal operator, a customs authority, a financial service, etc.

[0069] Examples of roles that can be granted to participant types include, but are not limited to, a buyer, a seller, an exporter, an importer, a shipper, a consignee, a transportation service buyer, a transportation service provider, an origin or destination third-party logistics (3PL), a customs house (export, import, etc.), a marine terminal (origin, destination, etc.), a rail operator, a truck operator, a barge operator, feeder vessel, transshipment terminal, port community service (PCS), an export authority, an import authority, a bank (of the seller, of the buyer, etc.), an insurance provider, etc.

[0070] Each participant type can map to multiple different roles. For example, a cargo owner can play the role of a seller, a buyer, an exporter, an importer, a shipper, a consignee, a transportation service buyer, etc. based on the activities of the cargo owner in the multi-party transport process. When the policy service described further herein receives details of a multi-party transport process, the policy service can assign one or more roles to each participant based on the mapping and based on the actions of the participant in the transport process. For example, if the cargo owner is both the original owner of the goods being sold and the shipper of the goods from one country to the next, the cargo owner can assume the roles of seller, exporter, and shipper.

[0071] Examples of documents that can be part of a multi-party transport process include, but are not limited to, a booking confirmation, an invoice, a shipping instruction, a bill of lading, a sea manifest, a sub-bill of lading, a forwarder’s cargo receipt, a notice of arrival, a dangerous goods declaration, a booking request, etc.

[0072] Examples of events that can occur during a multi-party transport process include, but are not limited to, an administrator event, an origin planning event, a sea planning event, a destination planning event, an origin estimation event, a sea estimation event, a destination estimation event, an origin actual event, a sea actual event, a destination actual event, etc.

[0073] By dynamically combining the mapping of participants to roles within the multi-party transport hierarchy with assertions of the different milestone events of a shipment and the permissions to different trade documents by the parties to the roles, the system can derive and enforce permissions to access (read / write) certain data of the multi-party transport process. As a non-limiting example, the system can determine that a sea carrier can upload a bill of lading document for a shipment, but an overland carrier (e.g., a truck driver) cannot access the document. The entire system is composed of services that derive the permissions information and then enforce it as part of the access to objects from the system, including the milestone events and the documents.

[0074] Figure 1 A trade ecosystem 100 for managing the transport of goods is shown in accordance with an example embodiment. Referring to FIG. 1, the trade ecosystem 100 includes a plurality of participants 102, a plurality of trade documents 104, a plurality of milestone events 106, and a plurality of services 108. Figure 1The host platform 130 can host the system described herein and can include an application programming interface (API) 132, one or more services 134, and a blockchain 136. The participants 110 of the system can access the services 134 via one or more applications 120 or the API 132 to upload initial shipping data for a multi-party shipping process (e.g., the parties involved, route information, cargo information, etc.). Based on this information, the services 134 can identify a role for each of the parties involved and dynamically assign access rights (e.g., read and / or write data) to documents and event data for the multi-party shipping process. The dynamically assigned access information, along with the multi-party shipping process, events, and documents, can also store identifiers for the parties on the blockchain 136.

[0075] Meanwhile, the API 132 can enable data communication between the participants 110 and the host platform 130, between the applications 120 and the host platform 130, etc. in the multi-party shipping process. Cargo-related data can also be uploaded from the participants 110 and integrated via the integration framework 112 into a format suitable for the platform 130. For example, imaging data for the cargo can be captured (e.g., scanning a product ID or a container ID) and then submitted to the blockchain 136 along with contextual information in the form of a textual description, such as a geographic location of the cargo, a current participant in possession of the cargo, an identifier of a transportation means (barges, trucks, rail, etc.) in possession of the cargo, sensor data for the environment in which the cargo is located (e.g., temperature, speed, humidity, etc.), etc. The data can be stored on the blockchain 136 in an immutable manner so that the parties can later review the data in the event of a problem. This can provide for a quick understanding of the reasons why the cargo / shipment failed to meet expectations, etc.

[0076] Initially, the participants 110 can participate as organizations in the solution. Each participant can be assigned a participant type that defines a specific set of roles that the organization can assume in a shipment. For example, a participant type for a cargo owner can play the role of a seller, a buyer, an importer, an exporter, a shipper, a consignee, a transportation service buyer, etc. The services 134 can assign the roles, define read / write permissions for each role / each party in the multi-party shipping process, and control access to data for the multi-party shipping process based on the defined read and write permissions. For example, a party can be allowed to read data for a certain document or milestone event, but can not be allowed to write data. As another example, a party can be allowed to view some documents, but not all of the documents involved in the multi-party shipping process. The services 134 can dynamically assign the permissions and subsequently control access to the data based on the dynamically assigned permissions. The data for the multi-party shipping process can be stored on the blockchain 136, off-chain systems, etc.

[0077] For example, events / milestones of a shipment as it moves through a multi-party transport process can be stored in association with the blockchain 136. Event data can be uploaded from participants 110 via the integration framework 112. The event data can be stored on the blockchain 136. As another example, the event data can be stored off-chain, with a hash of the event data (for verification purposes) stored on the blockchain 136. Examples of events include a container status event, which refers to the PID (physical ID) of a container, and the location of the container at a given time. For example, an image of the PID can be captured and uploaded to the host platform 130 along with contextual information. The service 134 can create a hash of the event data and store it on the blockchain 136 when the event data is stored off-chain. When a user (e.g., of a participant of the multi-party transport process) subsequently attempts to access the event data, access can be controlled by a policy service (which includes a smart contract), and this will be about Figure 4A to Figure 4D Further description. Access to event data can be based on roles dynamically assigned to participants during runtime.

[0078] Likewise, documents associated with the multi-party transport process can be stored on the blockchain 136, or they can be stored off-chain, with a hash of the documents stored on the blockchain 136. Similar to event data, access to document data can be controlled by a policy service, and access to documents can be based on roles dynamically assigned to participants during runtime.

[0079] Each of the interactions with the host platform 130 can be authenticated, and users and organizations (participants) can be mapped to digital identities registered on the blockchain by a CA (certificate authority). Further, the use of the blockchain 136 brings many advantages to the solution. For example, the blockchain 136 provides an immutable, shared, replicated ledger that can solve problems that can occur when multiple untrusted parties are doing transactions together, such as lack of trust. The blockchain 136 also provides a single version of truth. This can be helpful because disputes are common, and the cost of resolving them is high. Further, the blockchain 136 can be used to prove authenticity and ownership. The blockchain 136 can be used to track and control access to multiple steps of a paperwork process (global trade documents, supply chain finance, etc.). The blockchain 136 also provides reliable visibility of events across multiple parties, including recalls, regulatory chain tracking, provenance, etc. Due to the distributed nature of the blockchain 136, the blockchain 136 can also provide auditability and prevent fraud / tampering through the immutable ledger.

[0080] Figure 2A A blockchain architecture configuration 200 is shown in accordance with an example embodiment. Reference is made to Figure 2AThe blockchain architecture 200 can include certain blockchain elements, such as a set of blockchain nodes 202. The blockchain nodes 202 can include one or more nodes 204-210 (four nodes are depicted by way of example only). These nodes participate in a number of activities, such as blockchain transaction addition and validation processes (consensus). One or more of the blockchain nodes 204-210 can endorse transactions based on an endorsement policy, and can provide ordering services for all blockchain nodes in the architecture 200. Each of the blockchain nodes 204-210 can have installed therein a blockchain platform 212, application code 220 (e.g., smart contracts, etc.), application programming interfaces (APIs) 222, applications 224, etc. For example, a blockchain node can initiate a blockchain transaction and find its way to write to a blockchain immutable ledger stored in a blockchain layer 216, a copy of which can also be stored on the underlying physical infrastructure 214 of the blockchain platform 212. The blockchain configuration can include applications 224 that link to the APIs 222 to access and execute stored program / application code 220 (e.g., blockchain clients, chaincode, smart contracts, etc.), which can be created according to a custom configuration sought by a participant, and can maintain its state, receive external information, and communicate with blockchain APIs. This can be deployed and installed on all blockchain nodes 204-210.

[0081] The blockchain base or platform 212 can include blockchain data, services (e.g., cryptographic trust services, virtual execution environments, etc.), and various layers of underlying physical computer infrastructure that can be used to receive and store new transactions and provide access for auditors seeking to access data entries. The blockchain layer 216 can expose an interface that provides access to a virtual execution environment necessary to process program code and use the physical infrastructure 214. Cryptographic trust services 218 can be used to verify transactions, such as asset replacement transactions, and keep information private.

[0082] Figure 2AThe blockchain architecture configuration of the blockchain platform 212 can process and execute program / application code 220 via one or more interfaces exposed by the blockchain platform 212 and services provided by the blockchain platform. The code 220 can control blockchain assets. For example, the code 220 can store and transmit data and can be executed in the form of a smart contract by the nodes 204-210 and associate chaincode with conditions or other code elements subject to its execution. As a non-limiting example, a smart contract can be created to perform a reminder, update, and / or other notification subject to change, update, etc. The smart contract itself can be used to identify rules associated with authorization and access requirements and use of the ledger. For example, reading data can be handled by a smart contract in the application code 220 to determine proper access and return only results visible to the requesting party. Likewise, writing data can be handled by a smart contract in the application code 220 to determine whether the party / organization is allowed access to a particular asset.

[0083] A smart contract can be created in a programming language and then associated / instantiated / deployed on a channel of all blockchain nodes. A smart contract can include executable code that is registered, stored, and / or replicated with a blockchain channel or ledger (e.g., a distributed network of blockchain peers). Transactions are submitted by an application or blockchain client, which can cause execution of the smart contract code for validation or consensus purposes. Successfully executing a smart contract can trigger a trusted modification to the state of the digital blockchain ledger. The modification to the blockchain ledger caused by execution of a smart contract can be replicated automatically throughout the distributed network of blockchain peers through a communication protocol within the blockchain.

[0084] A smart contract can write data to the blockchain in the format of key-value pairs. Further, the smart contract code can read values stored in the blockchain and use them for application operations. The smart contract code can write the output of various logical operations to the blockchain. The data written to the blockchain can be public and / or can be encrypted and maintained as private. Temporary data used / generated by the smart contract is saved in memory by the provisioning execution environment and then deleted once the data required by the blockchain is identified.

[0085] Chaincode can include code interpretation of a smart contract as well as additional features. As described herein, chaincode can be program code deployed on a network of blockchain nodes, where the chaincode is executed and validated together by chain validators during a consensus process.

[0086] Figure 2B An example of a blockchain transaction flow 250 between nodes of a blockchain is shown in accordance with example embodiments. Reference is made to FIG. 2 for an overview of the blockchain architecture. Figure 2BThe transaction flow can include a transaction proposal 291 sent by the application client node 260 to the endorsing peer nodes 281. The endorsing nodes 281 can verify the client signature and execute the chaincode function to initiate the transaction. Executing the chaincode in 281 can include permission checks to verify the correct read and / or write permissions of the party / organization calling the transaction. For example, a party can be checked to see if it is authorized to view document or event data. The output can include the chaincode result, a set of key / value versions read in the chaincode (read set), and a set of key / values written in the chaincode (write set). If approved, the proposal response 292 is sent back to the client 260 along with the endorsement signature. The client 260 compiles the endorsements into a transaction payload 293 and broadcasts it to the ordering service nodes 284. The ordering service nodes 284 then deliver the ordered transaction as a block to all peers 281-283 on the channel. Before committing to the blockchain, each peer 281-283 can validate the transaction. For example, the peers can check the endorsement policy to ensure the correct distribution of endorsing peers has signed the result and verify the signature against the transaction payload 293.

[0087] Referring again to Figure 2B The client node 260 initiates the transaction 291 by constructing a request and sending it to the peer nodes 281 that are endorsers. The client 260 can include an application that utilizes a supported software development kit (SDK) that utilizes available APIs to generate the transaction proposal. The proposal is a request to call a chaincode function such that data can be read and / or written to the ledger (i.e., a new key / value pair is written for an asset). The SDK can be used as a shim to package the transaction proposal into a properly architected format (e.g., protocol buffers over remote procedure calls (RPCs)) and employ the client's cryptographic credentials to produce a unique signature of the transaction proposal.

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

[0089] In response, the application of client 260 checks / verifies the endorsement peer signatures and compares the proposal responses to determine if the proposal responses are identical. If the chaincode only queries the ledger, the application will check the query response and typically will not commit the transaction to ordering node service 284. If the client application intends to commit the transaction to ordering node service 284 to update the ledger, the application determines if the specified endorsement policy has been fulfilled prior to committing (i.e., if all peers necessary for the transaction have endorsed the transaction). Here, a client can only include one of the multiple parties to the transaction. In this case, each client can have its own endorsement node, and each endorsement node will need to endorse the transaction. This architecture makes the endorsement policy enforced by the peers and maintained in the commit validation phase even if the application chooses not to check the response or otherwise forward a transaction that is not endorsed.

[0090] After a successful check, in step 293, client 260 assembles the endorsements into a transaction and broadcasts the transaction proposal and responses within a transaction message to ordering nodes 284. The transaction can contain the read / write set, the endorsement peer signatures, and the channel ID. Ordering nodes 284 do not need to check the entire contents of the transaction to perform their operations, rather, ordering nodes 284 can simply receive transactions from all channels in the network, order them by channel and time, and create blocks of transactions by channel.

[0091] The blocks of transactions are delivered from ordering nodes 284 to all peer nodes 281-283 on the channel. The transactions within the block are validated 294 to ensure that any endorsement policy is fulfilled and that the ledger state of the read set variables has not changed since the read set was generated by the transaction execution. The transactions in the block are marked as valid or invalid. Further, in step 295, each peer node 281-283 appends the block to the chain of the channel, and for each valid transaction, commits the write set to the current state database. An event is emitted to notify the client application that the transaction (invocation) has been immutably appended to the chain, and whether the transaction is valid or invalid.

[0092] Figure 3A An example of a permissioned blockchain network 300 is shown, featuring a distributed, decentralized peer-to-peer architecture. In this example, a blockchain user 302 can initiate a transaction to a permissioned blockchain 304. In this example, the transaction can be a deployment, invocation, or query, and can be published by a client-side application utilizing an SDK, directly through an API, etc. The network can provide access to a regulator 306, such as an auditor. A blockchain network operator 308 manages member permissions, such as registering regulator 306 as an “auditor” and registering blockchain user 302 as a “client.” An auditor can be restricted to only querying the ledger, while a client can be authorized to deploy, invoke, and query certain types of chaincode.

[0093] A blockchain developer 310 can write chaincode and client-side applications. The blockchain developer 310 can deploy chaincode directly to the network through an interface. In this example, a blockchain user 302 connects to a permissioned blockchain 304 through a peer 314. Before any transactions can be made, the peer 314 retrieves the user’s enrollment and transaction certificates from a certificate authority 316 that manages user roles and permissions. The blockchain user must possess these digital certificates to make transactions on the permissioned blockchain 304. At the same time, a user attempting to utilize chaincode can be required to verify their credentials.

[0094] Figure 3B Another example of a permissioned blockchain network 320 is shown, featuring a distributed, decentralized peer-to-peer architecture. In this example, a blockchain user 322 can submit transactions to a permissioned blockchain 324. In this example, transactions can be deployments, invocations, or queries, and can be published through a client-side application utilizing an SDK, directly through an API, and the like. The network can provide access to a regulator 326, such as an auditor. A blockchain network operator 328 manages member permissions, such as enrolling the regulator 326 as an “auditor” and the blockchain user 322 as a “client.” The auditor can be restricted to querying the ledger only, while the client can be authorized to deploy, invoke, and query certain types of chaincode.

[0095] A blockchain developer 330 writes chaincode and client-side applications. The blockchain developer 330 can deploy chaincode directly to the network through an interface. To include credentials from a legacy data source 332 in the chaincode, the developer 330 can use an out-of-band connection to access the data. In this example, a blockchain user 322 connects to the network through a peer 334. Before any transactions can be made, the peer 334 retrieves the user’s enrollment and transaction certificates from a certificate authority 336. In some cases, the blockchain user must possess these digital certificates to make transactions on the permissioned blockchain 324. At the same time, a user attempting to utilize chaincode can be required to verify their credentials on a legacy data source 332. To confirm the user’s authorization, the chaincode can use an out-of-band connection to the data through a legacy processing platform 338.

[0096] In some embodiments, the blockchain herein can be a permissionless blockchain. In contrast to a permissioned blockchain, which requires permission to join, anyone can join a permissionless blockchain. For example, to join a permissionless blockchain, a user can create a personal address and begin interacting with the network (by submitting transactions and thus adding entries to the ledger). Additionally, all parties can choose to run a node on the system and employ a mining protocol to help verify transactions.

[0097] Figure 3C A process 350 is shown in which a transaction is processed by a permissionless blockchain 352 comprising a plurality of nodes 354. A sender 356 desires to send a payment or some other form of value (e.g., a contract, medical record, contract, good, service, or any other asset that can be encapsulated in a digital record) to a recipient 358 via the permissionless blockchain 352. In one embodiment, each of the sender device 356 and the recipient device 358 can have a digital wallet (associated with the blockchain 352) that provides user interface controls and transaction parameter displays. In response, the transaction is broadcast to the nodes 354 throughout the blockchain 352. Depending on the network parameters of the blockchain 352, the nodes verify 360 the transaction based on rules established by the permissionless blockchain 352 creator, which can be predefined or dynamically assigned. For example, this can include verifying the identity of the parties involved, etc. The transaction can be immediately verified, or the transaction can be placed in a queue with other transactions, and the nodes 354 determine whether the transaction is valid based on a set of network rules.

[0098] In structure 362, valid transactions are formed into blocks and sealed with a lock (hash). This process can be performed by a mining node among the nodes 354. The mining node can utilize additional software that is specialized for mining blocks for and creating blocks of the permissionless blockchain 352. Each block can be identified by a hash (e.g., 256 bits, etc.) created using an algorithm agreed upon by the network. Each block can include a header, a pointer to or reference of a hash of the header of the previous block in the chain, and a set of valid transactions. The reference to the hash of the previous block is associated with the creation of a secure, independent chain of blocks.

[0099] Before a block can be added to the blockchain, the block must be validated. Validation for the permissionless blockchain 352 can include proof of work (PoW), which is a solution to a puzzle derived from the header of the block. Although not shown in the example of Figure 3C Another process for validating blocks is proof of stake, which is not shown in the example of FIG. 3. Unlike proof of work, in which miners are rewarded for solving a mathematical problem, in proof of stake, the creator of a new block is selected in a deterministic way depending on their wealth, also defined as “stake.” A similar proof is then performed by the selected node.

[0100] In the case of mining 364, a node attempts to solve the block by incrementally changing one variable until the solution satisfies a network-wide goal. This creates the PoW, which ensures the correct answer. In other words, the potential solution must prove that computing resources were exhausted in solving the problem. In some types of permissionless blockchains, a miner can be rewarded with value (e.g., coins, etc.) for correctly mining a block.

[0101] Here, the PoW process and the chaining of blocks makes modification of the blockchain extremely difficult because an attacker would have to modify all subsequent blocks for a modification of one block to be accepted. Moreover, as new blocks are mined, the difficulty of modifying blocks increases and the number of subsequent blocks also increases. In the case of distribution 366, a successfully validated block is distributed through the permissionless blockchain 352 and all nodes 354 add the block to the main stream chain, which is the auditable ledger of the permissionless blockchain 352. Moreover, the value in the transaction submitted by the sender 356 is deposited or otherwise transferred to the digital wallet of the receiver device 358.

[0102] Figure 4A A service 420 for a host platform for assigning permissions and controlling access is shown in accordance with example embodiments. In this example, the service 420 includes a permissions service 422, an access control service 424, and a role determination service 426. Here, the access control service 424 and the role determination service 426 can be referred to as policy services. The permissions service 422 can be seeded with templates for deriving permissions that a participant role can have. For example, a shipper role in a shipment can write (upload) a commercial invoice document but not read an import declaration document. These permissions can be accessed by the role determination service 426 and the access control service 424.

[0103] When a new shipment is created by a user device 406 (e.g., a user or system associated with a participant of a shipment, etc.), the user device 406 can provide shipment information 436 that includes data associated with a multi-party shipping process, including details that specify participants 402 (identifiers), geographic origin, destination, transshipment port, shipping plan, milestone events, trade documents, etc. In response, the role determination service 426 can analyze the received shipment information 436, construct a shipping profile, and determine which participants 402 should be added to the multi-party shipping process and play which role. The identifier of the shipment, the identifier of the participant / role, access rights to documents and events, etc. can be stored on the blockchain as role / shipment data 412. Here, the role and shipment data 412 can be stored as data blocks in a hash-linked chain of blocks of the blockchain as transactions.

[0104] For example, the role determination service 426 can receive shipment information 436 that identifies a multi-modal process and details thereof. In response, the role determination service 426 can identify terminals / ports that correspond to the geographic locations in the shipment information 436 at the locations identified as the origin, destination, transshipment, etc. The terminals / ports can be added to the shipment as terminals, and thus they can be properly notified. As another example, a country of transit can be identified from the shipment information 436, and the role determination service 426 can determine the customs authorities (participants) of the country of transit of the shipment that can be added as the origin / destination customs. As another example, a seller and a buyer can be identified from trade documents. The seller can be added as a shipper role, and the buyer identified in the trade documents can be added as a consignee role. Further, the role determination service 426 can assign access rights to users of each of the identified participants / roles to the system to read / write events or documents through different services (e.g., query services, subscription services, etc.).

[0105] As the containers, cargo, pallets, shipments, etc. move through the chain of multi-party transportation processes, different events can be stored. For example, the participants 402 can upload event data to the permissions service 422 or other services. The event data can be stored on the blockchain 410, or the event data can be hashed and stored as hash data 414 on the blockchain, and written to off-chain storage 428 to save storage on the blockchain 410. Likewise, documents can be received from the participants 402 and stored on the blockchain 410, or a hash of the document can be stored in the hash data 414 on the blockchain 410, and the document itself can be stored in the off-chain storage 428.

[0106] At the same time, when a user device 404 accesses data / documents of a multi-party transportation process, the access of the user device can be controlled by the access control service 424. Here, the access control service 424 can control access to data and documents based on the read / write permissions of the corresponding participants assigned by the role determination service 426. Thus, each participant (and its users) on the system can only access the data that they are allowed to access. In some embodiments, the logic for the role determination service 426 and the access control service 424 can be implemented using a smart contract.

[0107] By dynamically combining the organizations on each level of the shipment hierarchy to a party role with assertions of that party role's permissions to different milestones of the shipment and to different trade documents, the system is able to derive and enforce permissions to access (read / write) data in a given shipment. For example, the derived access can determine that a marine carrier can upload a bill of lading document for a shipment, but an overland transport service (truck driver) cannot access the document. The overall system is composed of services 422, 424, and 426 that derive permission information and then enforce it as part of access to objects (including milestone events and documents) from the trade system.

[0108] Figure 4B A mapping 440 between participant types 442 and participant roles 444 is shown in accordance with example embodiments. Referring to Figure 4B , organizations involved in a multi-party transport process can be assigned as a particular participant type 442. Figure 4B Examples of participant types 442 in Figure 4B should not be considered exhaustive, and other participant types are possible. When an organization registers with the system, it can be assigned a participant type. In addition, when a new transport object is received (identifying a new shipment / transport), the role determination service 426 can assign each participant identified in the transport object as one or more of the participant roles 444. As shown in , participant types 442 can map to multiple different participant roles 444. In addition, some participant types 442 can map to the same participant roles 444. According to various embodiments, the role determination service 426 can determine which participant role 444 each participant should be assigned based on data read by the role determination service 426 from trade documents of the multi-party transport process, shipment information provided by the customer, etc.

[0109] Figure 4C A table 450 showing storage of access permissions to documents 456 based on roles is shown in accordance with example embodiments. Referring to Figure 4C , examples of access rights for two types of participants 452 (marine carriers and overland transporters) are shown. As shown, each participant type 452 can include multiple different roles 454, where each of the roles can have individual access rights assigned to it. Thus, different roles 454 can have different access rights to the documents 456. Although not shown in Figure 4C , access rights for all participant types and roles can be stored and managed by the permissions service 422 and can be accessed by the access control service 424.

[0110] Figure 4D A process 400D to dynamically determine read and write permissions to documents and events is shown in accordance with example embodiments. Referring to Figure 4DAs another example, the shipment information 436 can be curated by the platform from events and documents received from multiple parties of the shipment. The role determination service 426 can examine the documents, received information, etc., and identify the multiple participants 461-465. Further, the role determination service 426 can dynamically assign roles to each participant 461-465. Based on the dynamically assigned roles, the role determination service 426 can also identify the documents 471 and events 472 that the participants have access to. The dynamic assignment of the participants 461-465 and their roles, permissions, etc., can be stored on the blockchain 410 as object data 412 and used by the access control service 424 to manage / control access to data of the multi-party transportation process.

[0111] Figure 5 A method 500 of dynamically determining read and write permissions is shown in accordance with example embodiments. Reference is made to FIG. 4 for purposes of explanation of the method 500. Figure 5 In 510, the method can include receiving transportation data of a multi-party transportation process. For example, the transportation data can identify an origin, a destination, a shipping / transportation entity, intermediate entities, ports, customs entities, a buyer, a seller, etc. As another example, the transportation data can be extracted from documents received in 510, such as invoices, bills of lading, bills of sea, etc.

[0112] In 520, the method can include identifying documents and events associated with the multi-party transportation process based on the received transportation data. The documents can include any documents associated with parties of the multi-party transportation process. The events (also referred to as milestones) can include container-based events that occur as a container moves from one location to the next.

[0113] In 530, the method can include dynamically determining read and write permissions to the documents and events of the multi-party transportation process based on predefined roles. For example, the dynamic determination can include deriving permissions of multiple parties included in the multi-party transportation process to read and write data of the blockchain based on predefined roles of the parties mapped to the parties by chaincode of the blockchain. In some embodiments, the dynamic determination of the read and write permissions can also be determined based on the origin, the destination, and one or more intermediate locations of the multi-party transportation process. In 540, the method can also include storing an identifier of the multi-party transportation process and the dynamically determined read and write permissions in a block on the blockchain.

[0114] In some embodiments, the method can include receiving a request to access one or more of the documents and events of the multi-party transport process, and authorizing the request based on the dynamically determined read and write permissions stored in the blockchain. In some embodiments, the method can also include receiving a request to access one or more of the documents and events of the multi-party transport process, and denying the request based on the dynamically determined read and write permissions stored in the blockchain. In some embodiments, the method can also include receiving an event data update for the multi-party process, and storing the event data update and read and write permissions for the event data update in a block on the blockchain. In some embodiments, the event data update can include a modification to a previously stored document. In some embodiments, the event data update can include a modification to a previously determined read and write permissions for an event and its data.

[0115] Figure 6A An example system 600 including physical infrastructure 610 configured to perform various operations is shown in accordance with example embodiments. Referring to Figure 6A , the physical infrastructure 610 includes modules 612 and modules 614. The modules 614 include a blockchain 620 and smart contracts 630 (which can reside on the blockchain 620) that can perform any of the operational steps 608 included in any of the example embodiments (in the modules 612). The steps / operations 608 can include one or more of the described or depicted embodiments, and can represent output or write information written or read from one or more of the smart contracts 630 and / or the blockchain 620. The physical infrastructure 610, modules 612, and modules 614 can include one or more computers, servers, processors, memories, and / or wireless communication devices. Additionally, the modules 612 and modules 614 can be the same module.

[0116] Figure 6B Another example system 640 configured to perform various operations is shown in accordance with example embodiments. Referring to Figure 6B , the system 640 includes modules 612 and modules 614. The modules 614 include a blockchain 620 and smart contracts 630 (which can reside on the blockchain 620) that can perform any of the operational steps 608 included in any of the example embodiments (in the modules 612). The steps / operations 608 can include one or more of the described or depicted embodiments, and can represent output or write information written or read from one or more of the smart contracts 630 and / or the blockchain 620. In Figure 6A and Figure 6B example, the physical infrastructure 610, modules 612, and modules 614 can include one or more computers, servers, processors, memories, and / or wireless communication devices. Additionally, the modules 612 and modules 614 can be the same module.

[0117] Figure 6C An exemplary system configured to utilize a smart contract between parties and a mediation server configured to enforce smart contract terms on a blockchain is shown in accordance with an exemplary embodiment. Referring to Figure 6C , configuration 650 can represent a communication session, an asset transfer session, or a process or procedure driven by a smart contract 630 that explicitly identifies one or more user devices 652 and / or 656. The execution, operation, and results of the smart contract execution can be managed by a server 654. The content of the smart contract 630 can require a digital signature of one or more of the entities 652 and 656 as parties to the smart contract transaction. The results of the smart contract execution can be written to the blockchain 620 as a blockchain transaction. The smart contract 630 resides on a blockchain 620 that can reside on one or more computers, servers, processors, memories, and / or wireless communication devices.

[0118] Figure 6D A system 660 including a blockchain is shown in accordance with an exemplary embodiment. Referring to Figure 6D , an application programming interface (API) gateway 662 provides a common interface for accessing blockchain logic (e.g., smart contracts 630 or other chaincode) and data (e.g., distributed ledgers, etc.). In this example, the API gateway 662 is a common interface for performing transactions (invocations, queries, etc.) on the blockchain by connecting one or more entities 652 and 656 to blockchain peers (i.e., servers 654). Here, the servers 654 are blockchain network peers that hold a copy of the world state and a distributed ledger, allowing clients 652 and 656 to query data about the world state and submit transactions to the blockchain network, where endorsing peers will run the smart contract 630 depending on the smart contract 630 and endorsement policy.

[0119] The above-described embodiments can be implemented in hardware, computer program executed by a processor, firmware, or a combination thereof. The computer program can be embodied in a computer readable medium such as a storage medium. For example, the computer program can 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, hard disk, a removable disk, a compact disc read-only memory ("CD-ROM"), or any other form of storage medium known in the art.

[0120] An exemplary storage medium can 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 can be integral to the processor. The processor and the storage medium can reside in an application-specific integrated circuit ("ASIC"). In the alternative, the processor and the storage medium can exist as discrete components.

[0121] Figure 7A A process 700 of adding a new block to a distributed ledger 720 is shown in accordance with an exemplary embodiment, and Figure 7B The contents of a new data block structure 730 for a blockchain in accordance with an exemplary embodiment are shown. Referring to Figure 7A A client (not shown) can submit a transaction to the blockchain nodes 711, 712, and / or 713. The client can be an instruction received from any source to act on the blockchain 720. As an example, the client can be an application acting on behalf of a requestor (such as a device, person, or entity) to propose a transaction to the blockchain. Multiple blockchain peers (e.g., blockchain nodes 711, 712, and 713) can maintain the state of the blockchain network and a copy of the distributed ledger 720. There can be different types of blockchain nodes / peers in the blockchain network, including endorsement peers that simulate and endorse transactions proposed by clients and commit peers that inspect the endorsements, validate the transactions, and commit the transactions to the distributed ledger 720. In this example, the blockchain nodes 711, 712, and 713 can play the role of an endorser node, a committer node, or both.

[0122] The distributed ledger 720 includes a blockchain that stores immutable ordered records in blocks, and a state database 724 that maintains the current state of the blockchain 722 (the current world state). There can be one distributed ledger 720 per channel, and each peer maintains its own copy of the distributed ledger 720 for each channel it belongs to. The blockchain 722 is a transaction log constructed in hash-linked blocks, where each block contains a sequence of N transactions. The blocks can include various components and transactions as shown in Figure 7B The link of a block can be generated by adding the hash of the header of the previous block in the block header of the current block (shown by the arrow in Figure 7A ). In this way, all transactions on the blockchain 722 are ordered and cryptographically linked together, preventing tampering of the blockchain data without breaking the hash link. Moreover, due to the link, the latest block in the blockchain 722 represents every transaction that happened before it. The blockchain 722 can be stored on a peer-to-peer file system (local or attached storage) that supports an append-only blockchain workload.

[0123] The current state of the blockchain 722 and distributed ledger 722 can be stored in a state database 724. Here, the current state data represents the latest values of all keys that were once included in the chain transaction log of the blockchain 722. Chaincode calls execute transactions against the current state in the state database 724. To make these chaincode interactions very efficient, the latest values of all keys are stored in the state database 724. The state database 724 can include an indexed view of the transaction log of the blockchain 722, and thus can be regenerated from the chain at any time. The state database 724 can be automatically restored (or generated if needed) at peer startup, before transactions are accepted.

[0124] An endorsing node receives a transaction from a client and endorses the transaction based on the simulation results. The endorsing node holds the smart contract that simulated the transaction proposal. When the endorsing node endorses the transaction, the endorsing node will create a transaction endorsement, which is the endorsing node's signed response to the client application indicating endorsement of the simulated transaction. The method of endorsing a transaction depends on the endorsement policy that can be specified in the chaincode. One example of an endorsement policy is "a majority of endorsing peers must endorse the transaction." Different channels can have different endorsement policies. The endorsed transaction is forwarded by the client application to the ordering service 710.

[0125] The ordering service 710 receives the endorsed transactions, orders them into blocks, and delivers the blocks to the committing peers. For example, the ordering service 710 can initiate a new block when a transaction threshold is reached, a timer expires, or another condition. The ordering service 710 can be implemented as a stateless service that does not store any data. Figure 7A In the example, the blockchain node 712 is a committing peer that has received a new block of data 730 for storage on the blockchain 720. The first block in a blockchain can be referred to as the genesis block, which includes information about the blockchain, its members, data stored therein, and the like.

[0126] The ordering service 710 can be composed of a cluster of orderers. The ordering service 710 does not process transactions, smart contracts, or maintain a shared ledger. Instead, the ordering service 710 can accept endorsed transactions and specify the order in which these transactions are committed to the distributed ledger 720. The architecture of the blockchain network can be designed such that the specific implementation of "ordering" (e.g., Solo, Kafka, BFT, etc.) is a pluggable component.

[0127] Transactions are written to the distributed ledger 720 in a consistent order. The order of transactions is established to ensure that the updates to the state database 724 are valid when the transactions are committed to the network. Unlike a cryptocurrency blockchain system (e.g., Bitcoin, etc.) that orders transactions by solving a cryptographic puzzle or mining, in this example, the parties to the distributed ledger 720 can select the ordering mechanism that best suits the network.

[0128] When the ordering service 710 initializes the new data block 730, the new data block 730 can be broadcast to the endorsing peers (e.g., blockchain nodes 711, 712, and 713). In response, each endorsing peer validates the transactions in the new data block 730 by checking to ensure that the read set and the write set still match the current world state in the state database 724. Specifically, the endorsing peers can determine whether the read data that existed when the endorsers simulated the transactions is the same as the current world state in the state database 724. When the endorsing peers validate the transactions, the transactions are written to the blockchain 722 on the distributed ledger 720, and the state database 724 is updated with the write data from the read-write set. If the transactions fail, i.e., if the endorsing peers find that the read-write set does not match the current world state in the state database 724, the transaction that was ordered into the block will still be included in the block, but it will be marked as invalid, and the state database 724 will not be updated.

[0129] Reference Figure 7B The new data block 730 (also referred to as a data block) stored on the blockchain 722 of the distributed ledger 720 can include a plurality of data segments, such as a block header 740, block data 750, and block metadata 760. It should be appreciated that the various described blocks and their contents, such as the new data block 730 and its contents, are merely examples and are not intended to limit the scope of the example embodiments. The new data block 730 can store, within the block data 750, transaction information for N (e.g., 1, 10, 100, 500, 1000, 2000, 3000, etc.) transactions. The new data block 730 can also include, in the block header 740, a link to a previous block (e.g., on the blockchain 722 in Figure 7B Figure 7A The block header 740 can include a hash of the header of the previous block. The block header 740 can also include a unique block number, a hash of the block data 750 of the new data block 730, etc. The block number of the new data block 730 can be unique and assigned in various orders, such as an increasing / sequential order starting from zero.

[0130] ​Block data 750 can store transaction information for each transaction recorded within new data block 730. For example, transaction data can include one or more of the following: type of transaction, version, timestamp, channel ID of distributed ledger 720, transaction ID, epoch, payload visibility, chaincode path (deploy transaction), chaincode name, chaincode version, inputs (chaincode and function), client (creator) identity (such as a public key and certificate), client's signature, endorser identity, endorser signature, proposal hash, chaincode event, response status, namespace, read set (list of keys and versions read by transaction, etc.), write set (list of keys and values, etc.), start key, end key, list of keys, Merkle tree query summary, etc. Transaction data for each of N transactions can be stored.

[0131] According to various embodiments, block data 750 can also store downstream shipment data 752, which can include an identifier of a shipment / transport, identifiers of parties involved in the transport, roles of the parties, permissions to authorize the parties to read and write (such as files, event data, etc.), etc. Transport data 752 can be used to verify whether a user requesting access to transport information is allowed to access such data based on permissions stored in transport data 752. Transport data 752 includes one or more of the steps, features, processes, and / or actions described or depicted herein. Accordingly, transport data 752 can be stored in an immutable block log on distributed ledger 720. Some of the benefits of storing transport data 752 on a blockchain are reflected in the various embodiments disclosed and depicted herein.

[0132] Block metadata 760 can store a plurality of metadata fields (e.g., in the form of byte arrays, etc.). Metadata fields can include a signature at the time of block creation, a reference to the last configuration block, a transaction filter that identifies valid and invalid transactions within the block, a last offset at which a sequencing service persisted in sequencing transport 710, etc. Sequencing service 710 can add the signature, last configuration block, and sequencer metadata. Meanwhile, a submitting party of the block (such as a blockchain node 712) can add validity / invalidity information based on endorsement policies, verification of read / write sets, etc. A transaction filter can include a byte array of a size equal to the number of transactions in block data 750 and a verification code that identifies whether a transaction is valid or invalid. In some embodiments, although not shown in FIG. 7, block metadata 760 can store metadata for a recommended smart contract therein. Figure 7B

[0133] Figure 7C ​An embodiment of a blockchain 770 for digital content is shown in accordance with the embodiments described herein. The digital content can include one or more files and related information. These files can include media, images, video, audio, text, links, graphics, animations, web pages, documents, or other forms of digital content. The immutable, append-only aspect of the blockchain serves as a safeguard to protect the integrity, validity, and authenticity of the digital content, making it suitable for use in legal proceedings where admissibility rules apply, or other scenarios where evidence is considered or where the presentation and use of digital information is also important. In this case, the digital content can be referred to as digital evidence.

[0134] The blockchain can be formed in various ways. In one embodiment, the digital content can be included in the blockchain itself and accessed therefrom. For example, each block of the blockchain can store a hash value of reference information (e.g., block header, value, etc.) and associated digital content. The hash value and associated digital content can then be encrypted together. Thus, the digital content of each block can be accessed by decrypting each block in the blockchain, and the hash value of each block can serve as a basis for referencing the previous block. This can be illustrated as follows:

[0135]

[0136] In one embodiment, the digital content can not be included in the blockchain. For example, the blockchain can store an encrypted hash of the content of each block without any digital content. The digital content can be stored in another storage area or memory address in association with the hash value of the original file. The other storage area can be the same storage device used to store the blockchain, or it can be a different storage area or even a separate relational database. The digital content of each block can be referenced or accessed by obtaining or querying the hash value of the block of interest and then looking up the hash value stored in the storage area corresponding to the actual digital content. This operation can be performed by, for example, a database gatekeeper. This can be illustrated as follows:

[0137]

[0138] In Figure 7C an exemplary embodiment, the blockchain 770 includes a number of blocks 7781, 7782,..., 778 N linked cryptographically in an ordered sequence. The number of blocks 7781, 7782,..., 778 N The cryptography used to link the blocks 7781, 7782,..., 778 NA hash function that produces an n-bit alphanumeric output from an input based on information in the block (where n is 256 or another number). Examples of such hash functions include, but are not limited to, SHA-type (SHA stands for Secure Hash Algorithm) algorithms, Merkle-Damagard algorithms, HAIFA algorithms, Merkle tree algorithms, random number based algorithms, and non-collision resistant PRF algorithms. In another embodiment, the blocks 7781, 7782,..., 778 N The cryptographic chaining can be done by a function other than a hash function. For ease of illustration, the following description refers to a hash function, e.g., SHA-2.

[0139] Each block 7781, 7782,..., 778 N includes a header, a version of the file, and a value. Due to the hashing in the blockchain, the header and the value of each block are different. In one embodiment, the value can be included in the header. As described in more detail below, the version of the file can be the original file or a different version of the original file.

[0140] The first block 7781 in the blockchain is referred to as the genesis block and includes a header 7721, an original file 7741, and an initial value 7761. The hashing scheme for the genesis block can be different than the hashing scheme for all subsequent blocks. For example, all of the information in the first block 7781 can be hashed together at the same time, or each or a portion of the information in the first block 7781 can be hashed separately and then the separately hashed portions can be hashed.

[0141] The header 7721 can include one or more initial parameters, e.g., that can include a version number, a timestamp, a random number, root information, a difficulty level, a consensus protocol, a duration, a media format, a source, descriptive keywords, and / or other information associated with the original file 7741 and / or the blockchain. The header 7721 can be generated automatically (e.g., by blockchain network management software) or manually by a blockchain participant. Unlike the headers in the other blocks 7782 to 778 N in the blockchain, the header 7721 in the genesis block does not reference a previous block, simply because there is no previous block.

[0142] The original file 7741 in the genesis block can be, for example, data captured by a device that is processed or unprocessed prior to its inclusion in the blockchain. The original file 7741 is received from a device, a media source, or a node through an interface of the system. The original file 7741 is associated with metadata that can be generated manually or automatically, e.g., by a user, a device, and / or a system processor. The metadata can be included in the first block 7781 in association with the original file 7741.

[0143] The value 7761 in the genesis block is an initial value generated based on one or more unique attributes of the original file 7741. In one embodiment, the one or more unique attributes can include a hash value of the original file 7741, metadata of the original file 7741, and other information related to the file. In one implementation, the initial value 7761 can be based on the following unique attributes:

[0144] 1) SHA-2 computed hash value of the original file

[0145] 2) Originating device ID

[0146] 3) Start time stamp of the original file

[0147] 4) Initial storage location of the original file

[0148] 5) Blockchain network member ID for the software currently controlling the original file and associated metadata

[0149] Other blocks 7782 through 778 N Also have a header, a file, and a value. However, unlike the header 7721 of the first block, the headers 7722 through 772 N in the other blocks each include a hash value of the immediately preceding block. The hash value of the immediately preceding block can be just the hash of the header of the previous block, or it can be the hash value of the entire previous block. By including the hash value of the previous block in each of the remaining blocks, the genesis block (and the associated original file) can be traced back block-by-block from the Nth block, as shown by the arrow 780, to establish an auditable and immutable chain of custody.

[0150] Each of the headers 7722 through 772 N in the other blocks can also include other information, e.g., a version number, a time stamp, a nonce, root information, a difficulty level, a consensus protocol, and / or other parameters or information generally associated with the corresponding file and / or blockchain.

[0151] The files 7742 through 774 N in the other blocks can be equal to the original file, or can be a modified version of the original file in the genesis block, depending on, for example, the type of processing performed. The type of processing performed can vary from block to block. The processing can involve, for example, any modifications to the file in the previous block, such as revising information or otherwise changing the contents of the file, removing information from the file, or adding or appending information to the file.

[0152] Additionally or alternatively, the processing can involve only copying the file from the previous block, changing the storage location of the file, analyzing the file in one or more previous blocks, moving the file from one storage or memory location to another, or performing an action with respect to the file and / or its associated metadata of the blockchain. Processing involving analyzing the file can include, for example, appending, including, or otherwise associating various analytics, statistics, or other information associated with the file.

[0153] Each of the other blocks 7762to 776 N are unique values and all different due to the processing performed. For example, the value in any one block corresponds to an updated version of the value in the previous block. The update is reflected in the hash of the block to which the value is assigned. Thus, the value of the block provides an indication of what processing was performed in the block and also allows tracking back to the original file through the blockchain. This tracking confirms the chain of custody of the file throughout the blockchain.

[0154] For example, consider the case where a portion of the file in the previous block is redacted, chunked, or pixelated in order to protect the identity of a person shown in the file. In this case, the block that includes the redacted file will include metadata associated with the redacted file, e.g., how the redaction was performed, who performed the redaction operation, a timestamp of when the redaction occurred, etc. The metadata can be hashed to form the value. Since the metadata of the block is different from the information that was hashed in the previous block to form the value, the values are different from each other and can be recovered upon decryption.

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

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

[0157] b) a new storage location of the file

[0158] c) new metadata associated with the file that is identified

[0159] d) a transfer of access or control of the file from one blockchain participant to another

[0160] Figure 7D An embodiment of a block is shown that can represent the structure of a block in the blockchain 790 according to one embodiment. This block (block i ) includes a header 772 i , a file 774i and value 776 i .

[0161] header 772 i includes a hash value of the previous block block i-1 and additional reference information, which can be any type of information discussed herein (e.g., header information including references, features, parameters, etc.), for example. All blocks reference the hash value of the previous block, except for the genesis block, of course. The hash value of the previous block can be just the hash of the header in the previous block, or it can be the hash of all or a portion of the information in the previous block (including files and metadata).

[0162] file 774 i includes a plurality of data, such as data 1, data 2,..., data N in order. The data is tagged with metadata metadata 1, metadata 2,..., metadata N describing content and / or features associated with the data. For example, the metadata for each data can include information indicating a timestamp of the data, processing the data, keywords indicating people or other content depicted in the data, and / or other features that can help establish the validity and content of the file as a whole, especially its use as digital evidence, for example, as described in connection with the embodiments discussed below. In addition to the metadata, each data can also be tagged with a reference REF 1, REF 2,..., REF N to the previous data to prevent tampering, gaps in the file, and sequential references through the file.

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

[0164] value 776 i is a hash value or other value computed based on any type of information discussed previously. For example, for any given block block i , the value of the block can be updated to reflect processing performed on the block, such as a new hash value, a new storage location, new metadata for the associated file, a transfer of control or access, an identifier, or other action or information to be added. Although the value in each block is shown as separate from the metadata and header of the data of the file, in another embodiment, the value can be based in part or in whole on the metadata.

[0165] Once the blockchain 770 is formed, an immutable chain of custody of the file can be obtained at any point in time by querying the blockchain for the transaction history of the values across the blocks. This query or tracing process can begin with the decryption of the value of the most recently included block (e.g., the last (Nth) block) and then continue with the decryption of the values of other blocks until the genesis block is reached and the original file is recovered. The decryption can also involve the decryption of the header and file at each block, as well as the associated metadata.

[0166] The decryption is performed based on the type of encryption that occurs in each block. This can involve the use of a private key, a public key, or a public-private key pair. For example, when using asymmetric encryption, a blockchain participant or processor in the network can use a predetermined algorithm to generate a public and private key pair. The public and private keys are linked to each other through some mathematical relationship. The public key can be publicly distributed to use as an address, e.g., an IP address or home address, to receive messages from other users. The private key is kept secret and 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 determine that only the sender could have sent the message.

[0167] Generating a key pair can be similar to creating an account on a blockchain but without having to actually register anywhere. Moreover, every transaction performed on the blockchain is digitally signed by the sender using their private key. This signature ensures that only the owner of the account can track and process (if within the scope of permissions determined by a smart contract) the files of the blockchain.

[0168] Figure 8A and Figure 8B Additional examples of use cases of blockchains that can be incorporated and used herein are shown. In particular, Figure 8A An example 800 of a blockchain 810 that stores machine learning (artificial intelligence) data is shown. Machine learning relies on large amounts of historical data (or training data) to build a predictive model for accurate predictions on new data. Machine learning software (e.g., neural networks, etc.) can often sift through millions of records to find non-intuitive patterns.

[0169] In the example of Figure 8A , a host platform 820 builds and deploys a machine learning model for predictive monitoring of an asset 830. Here, the host platform 820 can be a cloud platform, an industrial server, a web server, a personal computer, a user device, etc. The asset 830 can be any type of asset (e.g., machine or device, etc.), such as an aircraft, a locomotive, a turbine, a medical machine and device, an oil and gas equipment, a ship, a vessel, a vehicle, etc. As another example, the asset 830 can be an intangible asset, such as a stock, a currency, a digital coin, an insurance, etc.

[0170] The blockchain 810 can be used to significantly improve the training process 802 of machine learning models and the prediction process 804 based on trained machine learning models. For example, in 802, historical data can be stored on the blockchain 810 by the assets 830 themselves (or through a mediator, 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 820 in performing the prediction model training. For example, using a smart contract, data can be transferred directly and reliably from the originating location to the blockchain 810. By using the blockchain 810 to ensure the security and ownership of the collected data, the smart contract can send the data directly from the asset to the individual using the data to build the machine learning model. This allows for the sharing of data between assets 830.

[0171] The collected data can be stored in the blockchain 810 based on a consensus mechanism. The consensus mechanism pulls in (permissioned nodes) to ensure that the data being recorded is verified and accurate. The recorded data is time-stamped, cryptographically signed, and immutable. Thus, the recorded data is auditable, transparent, and secure. In certain cases (i.e., supply chain, healthcare, logistics, etc.), the addition of IoT devices that write directly to the blockchain can increase both the frequency and accuracy of the data being recorded.

[0172] Further, the training of machine learning models on the collected data can be performed by the host platform 820 in several rounds of refinement and testing. Each round can be based on additional data or previously unconsidered data to help expand the knowledge of the machine learning model. In 802, the different training and testing steps (and their associated data) can be stored on the blockchain 810 by the host platform 820. Each refinement of the machine learning model (e.g., changes to variables, weights, etc.) can be stored on the blockchain 810. This provides a verifiable proof of how the model was trained and with what data. Further, when the host platform 820 has achieved a final trained model, the resulting model can be stored on the blockchain 810.

[0173] After the model has been trained, it can be deployed to a real-world environment, where predictions / decisions can be made based on the execution of the final trained machine learning model. For example, in 804, the machine learning model can be used for condition-based maintenance (CBM) of an asset, such as an aircraft, a wind turbine, a healthcare machine, etc. In this example, data fed back from the asset 830 can be input into the machine learning model and used to make event predictions, such as a failure event, an error code, etc. The determination made by executing the machine learning model at the host platform 820 can be stored on the blockchain 810 to provide an auditable / inspectable proof. As one non-limiting example, the machine learning model can predict a future damage / failure of a part of the asset 830 and create an alert or notification to replace the part. The data behind this decision can be stored by the host platform 820 on the blockchain 810. In one embodiment, the features and / or actions described and / or depicted herein can occur on or with respect to the blockchain 810.

[0174] New transactions of the blockchain can be gathered into a new block and added to the existing hash value. This is then encrypted to create a new hash of the new block. This is added to the next list of transactions when they are encrypted, and so on. The result is a blockchain that contains the hash value of all previous blocks in each block. The computers that store these blocks periodically compare their hash values to make sure they all agree. Any computer that does not agree discards the record that caused the problem. This approach is beneficial for ensuring the tamper resistance of the blockchain, but it is not perfect.

[0175] One way that a dishonest user can manipulate the system is to change the list of transactions in a way that is favorable to themselves but leaves the hash unchanged. This can be done by brute force, in other words, by changing the record, encrypting the result, and seeing if the hash value is the same. And if it is not, then trying repeatedly until a matching hash is found. The security of the blockchain is based on the belief that ordinary computers can only conduct such brute force attacks on a time scale that is completely impractical, such as the age of the universe. In contrast, quantum computers are much faster (thousands of times faster), and thus pose a much greater threat.

[0176] Figure 8B An example 850 of a quantum secure blockchain 852 is shown that implements quantum key distribution (QKD) to prevent quantum computing attacks. In this example, the blockchain users can use QKD to verify each other’s identity. This uses quantum particles, such as photons, to send information, which a eavesdropper cannot copy without destroying the quantum particle. In this way, the sender and receiver can confirm each other’s identity through the blockchain.

[0177] In Figure 8BIn this case, there are four users 854, 856, 858, and 860. Each pair of users can share a key 862 (i.e., a QKD) between them. Since there are four nodes in this example, there are six pairs of nodes, and thus six different keys 862 are used, including QKDs AB , QKD AC , QKD AD , QKD BC , QKD BD , and QKD CD . Each pair can create a QKD by sending information using quantum particles, such as photons, which cannot be copied by an eavesdropper without destroying the quantum particle. In this way, a pair of users can confirm each other’s identity.

[0178] The operation of the blockchain 852 is based on two procedures: (i) the creation of transactions, and (ii) the construction of blocks that aggregate new transactions. New transactions can be created similarly to a traditional blockchain network. Each transaction can contain information about the sender, the recipient, the time of creation, the amount (or value) to be transferred, a list of reference transactions that judge that the sender has the funds for the operation, etc. This transaction record is then sent to all other nodes, where it is input into a pool of unconfirmed transactions. Here, the two parties (i.e., a pair of users in 854-860) authenticate the transaction by providing their shared key 862 (QKD). This quantum signature can be attached to each transaction, making it extremely difficult to tamper with. Each node checks its entries about the local copy of the blockchain 852 to verify that each transaction has enough funds. However, the transactions have not yet been confirmed.

[0179] Instead of performing a traditional mining process on the blocks, a broadcast protocol can be used to create the blocks in a decentralized manner. At a predetermined period of time (e.g., seconds, minutes, hours, etc.), the network can apply a broadcast protocol to any unconfirmed transactions, thereby achieving a Byzantine agreement (consensus) on the correct version of the transactions. For example, each node can have a private value (the transaction data for that particular node). In the first round, the nodes transmit their private values to each other. In subsequent rounds, the nodes communicate the information they received from other nodes in the previous round. Here, the honest nodes are able to create a set of complete transactions within a new block. This new block can be added to the blockchain 852. In one embodiment, the features and / or actions described and / or depicted herein can occur on or with respect to the blockchain 852.

[0180] Figure 9An exemplary system 900 that supports one or more of the example embodiments described and / or depicted herein is shown. The system 900 includes a computer system / server 902, which is operational with numerous other general purpose or special purpose computing system environments or configurations. Examples of well- known computing systems, environments, and / or configurations that can be suitable for use with computer system / server 902 include, but are not limited to, personal computer systems, server computer systems, thin clients, thick clients, hand-held or laptop devices, multiprocessor systems, microprocessor-based systems, set top boxes, programmable consumer electronics, network PCs, minicomputer systems, mainframe computer systems, and distributed cloud computing environments that include any of the above systems or devices, and the like.

[0181] Computer system / server 902 can be described in the general context of computer system-executable instructions, such as program modules, being executed by a computer system. Generally, program modules can include routines, programs, objects, components, logic, data structures, and so on that perform particular tasks or implement particular abstract data types. Computer system / server 902 can be practiced in distributed cloud computing environments with remote processing devices that are linked through a communications network. In a distributed cloud computing environment, program modules can be located in both local and remote computer system storage media including memory storage devices.

[0182] As Figure 9 shown in FIG. 11, computer system / server 902 in cloud computing node 900 is operational with numerous other general purpose or special purpose computing system environments or configurations. Computer system / server 902 can include one or more processors or processing units 904, system memory 906, and a bus 908 that couples various system components including system memory 906 to processor 904.

[0183] Bus 908 represents one or more of any of several types of bus structures, including a memory bus or memory controller, a peripheral bus, an accelerated graphics port, and a processor or local bus using any of a variety of bus architectures. By way of example, and not limitation, such architectures include Industry Standard Architecture (ISA) bus, Micro Channel Architecture (MCA) bus, Enhanced ISA (EISA) bus, Video Electronics Standards Association (VESA) local bus, and Peripheral Component Interconnect (PCI) bus.

[0184] The computer system / server 902 typically includes a variety of computer system readable media. Such media can be any available media that is accessible by computer system / server 902, and includes both volatile and non-volatile media, removable and non-removable media. In one embodiment, the system memory 906 implements the flow diagrams of the other figures. The system memory 906 can include computer system readable media in the form of volatile memory, such as random access memory (RAM) 910 and / or cache memory 912. Computer system / server 902 can further include other removable / non-removable, volatile / non-volatile computer system storage media. By way of example only, a storage system 914 can be provided for reading from and writing to non-removable, non-volatile magnetic media (not shown and typically called a "hard drive"). Although not shown, a magnetic disk drive can also be provided for reading from and writing to a removable, non-volatile magnetic disk (e.g., a "floppy disk"), and an optical disk drive can 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). Each can be connected to bus 908 by one or more data media interfaces. As will be further depicted and described below, memory 906 can include at least one program product having a set (e.g., at least one) of program modules that are configured to carry out the functions of embodiments of the application.

[0185] Program / utility 916 having a set (at least one) of program modules 918 can be stored in memory 906, by way of example, and not limitation, as well as an operating system, 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 some combination thereof, can include an implementation of a networking environment. Program modules 918 generally carry out the functions and / or methodologies of embodiments of the application as described herein.

[0186] As will be appreciated by one of skill in the art, aspects of the present application can be embodied as a system, method, or computer program product. Accordingly, aspects of the present application can take the form of an entirely hardware embodiment, an entirely software embodiment (including firmware, resident software, micro-code, etc.) or combinations of software and hardware that can all generally be referred to herein as a "circuit," "module" or "system." Furthermore, aspects of the present application can take the form of a computer program product embodied in one or more computer readable medium(s) having computer readable program code embodied thereon.

[0187] The computer system / server 902 can also communicate with one or more external devices 920 such as a keyboard or pointing device, a display 922, etc.; one or more devices that enable a user to interact with the computer system / server 902; and / or any devices (e.g., network card, modem, etc.) that enable the computer system / server 902 to communicate with one or more other computing devices. Such communication can be via I / O interface(s) 924. Still yet, the computer system / server 902 can communicate with one or more networks such as a local area network (LAN), a general wide area network (WAN), and / or a public network (e.g., the Internet) via network adapter 926. As depicted, network adapter 926 communicates with the other components of the computer system / server 902 via a bus. It should be appreciated that although not shown, other hardware and / or software components could be used in conjunction with the computer system / server 902. Examples include, but are not limited to: microcode, device drivers, redundant processing units, external disk drive arrays, RAID systems, tape drives, and data archival storage systems, etc.

[0188] While example embodiments of at least one of a system, method, and non-transitory computer readable medium have been shown and described in the drawings and detailed description above, it will be understood by those of ordinary skill in the art that the application is not limited to the embodiments disclosed, but rather can be practiced with modification and alteration within the scope and spirit of the appended claims. For example, the capabilities of the systems of the various figures can be performed by one or more of the modules or components described herein, or in a distributed architecture across the various components and modules. Additionally, the functionality of the modules or components can be performed by one or more of the modules or components described herein, or in a distributed architecture across the various components and modules. Furthermore, the information sent between the modules or components can be sent via at least one of: a data network, the Internet, a voice network, an Internet Protocol network, a wireless device, a wired device, and / or via multiple protocols. Also, the messages sent or received by any of the modules can be sent or received directly and / or via one or more of the other modules.

[0189] Those skilled in the art will appreciate that a "system" can embody the personal computer, server, console, personal digital assistant (PDA), cellular telephone, tablet computing device, smart phone, or any other suitable computing device, or combination of devices. Presenting the above-described functions as being performed by a "system" is not intended to limit the scope of the application in any way, but is merely to provide one illustrative example of a manner in which the methods, systems, and devices disclosed herein can be implemented. Indeed, a localized and distributed form of implementation can be implemented in keeping with the computing technology.

[0190] It should be noted that some of the system features described in this specification are presented as modules in order to more particularly emphasize their implementation independence. For example, a module can be implemented as a hardware circuit comprising custom very-large-scale integration (VLSI) circuits or gate arrays, off-the-shelf semiconductors such as logic chips, transistors, or other discrete components. A module can also be implemented in programmable hardware devices such as field programmable gate arrays, programmable array logic, programmable logic devices, graphics processing units, and the like.

[0191] Modules can also, at least partially, be implemented in software for execution by various types of processors. An identified unit of executable code may, for instance, comprise one or more physical or logical blocks of computer instructions that may, for instance, be organized as an object, a procedure, or a function. Nevertheless, the executables of an identified module need not be physically located together, but can comprise disparate instructions stored in different locations that, when joined logically together, comprise the module and achieve the stated purpose for the module. Further, modules can be stored on a computer-readable medium, which can be, for instance, a hard disk drive, flash device, random access memory (RAM), tape, or any other such medium that stores data for use by a computer.

[0192] Indeed, a module of executable code can be a single instruction, or many instructions, and can even be distributed over several different code segments, among different programs, and across several memory devices. Similarly, operational data can be identified and illustrated herein within modules, and can be embodied in any suitable form and organized within any suitable type of data structure. The operational data can be collected as a single data set, or can be distributed over different locations including over different storage devices, and can exist, at least partially, merely as electronic signals on a system or network.

[0193] It will be readily appreciated that the components of the application, as generally described and illustrated in the figures herein, can be arranged and designed in a wide variety of different configurations. Thus, the

[0194] Those of ordinary skill in the art will readily understand that the above description is meant as a selection of embodiments of the application and is not intended to limit the scope of the application, which is defined by the appended claims.

[0195] While preferred embodiments of the application have been described, it will be understood that the described embodiments are merely illustrative of the application and that modifications of detail can be made therein without departing from the scope of the application as defined by the appended claims, which are to be interpreted as broadly as the prior art will permit.

Claims

1. An apparatus for a multi-party shipping process, the apparatus comprising: a network interface configured to receive shipping data for a multi-party shipping process; and a processor configured to: identify documents and events associated with the multi-party shipping process based on the received shipping data; dynamically determine read and write permissions to the documents and events of the multi-party shipping process based on predefined roles of the multi-party shipping process, an origin of the multi-party shipping process, a destination of the multi-party shipping process, and intermediate locations of the multi-party shipping process; and store an identifier of the multi-party shipping process and the dynamically determined read and write permissions in a block on a blockchain, wherein the network interface is further configured to receive event data updates for the multi-party shipping process and store the event data updates and read and write permissions to the event data updates in a block on the blockchain.

2. The apparatus of claim 1, wherein the processor is configured to derive permissions of parties included in the multi-party shipping process to read and write data to the blockchain based on predefined roles of the parties mapped through chaincode of the blockchain.

3. The apparatus of claim 1, wherein the processor is further configured to receive a request to access one or more of the documents and events of the multi-party shipping process and grant the request based on the dynamically determined read and write permissions stored in the blockchain.

4. The apparatus of claim 1, wherein the processor is further configured to receive a request to access one or more of the documents and events of the multi-party shipping process and deny the request based on the dynamically determined read and write permissions stored in the blockchain.

5. The apparatus of claim 1, wherein the event data updates include modifications to previously stored documents.

6. The apparatus of claim 1, wherein the event data updates include modifications to previously determined read and write permissions to events and their data.

7. A method for a multi-party shipping process, the method comprising: receiving shipping data for a multi-party shipping process; identifying documents and events associated with the multi-party shipping process based on the received shipping data; dynamically determining read and write permissions to the documents and events of the multi-party shipping process based on predefined roles of the multi-party shipping process, an origin of the multi-party shipping process, a destination of the multi-party shipping process, and intermediate locations of the multi-party shipping process; and storing an identifier of the multi-party shipping process and the dynamically determined read and write permissions in a block on a blockchain, wherein the method further comprises receiving event data updates for the multi-party shipping process and storing the event data updates and read and write permissions to the event data updates in a block on the blockchain.

8. The method of claim 7, wherein dynamically determining includes deriving permissions of parties included in the multi-party shipping process to read and write data to the blockchain based on predefined roles of the parties mapped through chaincode of the blockchain.

9. The method of claim 7, further comprising receiving a request to access one or more of the documents and events of the multi-party transport process, and authorizing the request based on the dynamically determined read and write permissions stored in the blockchain.

10. The method of claim 7, further comprising receiving a request to access one or more of the documents and events of the multi-party transport process, and denying the request based on the dynamically determined read and write permissions stored in the blockchain.

11. The method of claim 7, wherein the event data update comprises a modification to a previously stored document.

12. The method of claim 7, wherein the event data update comprises a modification to a previously determined read and write permissions to an event and its data.

13. A non-transitory computer-readable medium comprising instructions that, when read by a processor, cause the processor to perform a method comprising: receiving transport data of a multi-party transport process; identifying documents and events associated with the multi-party transport process based on the received transport data; dynamically determining read and write permissions to the documents and events of the multi-party transport process based on predefined roles of the multi-party transport process, an origin of the multi-party transport process, a destination of the multi-party transport process, and intermediate locations of the multi-party transport process; and storing an identifier of the multi-party transport process and the dynamically determined read and write permissions in a block on a blockchain, wherein the method further comprises receiving an event data update of the multi-party transport process, and storing the event data update and read and write permissions to the event data update in a block on the blockchain.

14. The non-transitory computer-readable medium of claim 13, wherein dynamically determining comprises deriving permissions of parties included in the multi-party transport process to read and write data of the blockchain based on predefined roles of the parties mapped to the multi-party transport process by chaincode of the blockchain.

15. The non-transitory computer-readable medium of claim 13, wherein the method further comprises receiving a request to access one or more of the documents and events of the multi-party transport process, and authorizing the request based on the dynamically determined read and write permissions stored in the blockchain.

16. The non-transitory computer-readable medium of claim 13, wherein the method further comprises receiving a request to access one or more of the documents and events of the multi-party transport process, and denying the request based on the dynamically determined read and write permissions stored in the blockchain.

17. A computer program product comprising a computer program which, when executed by a processor, performs the method according to any one of claims 7-12. ​

Images