TWI753367B - Zero trust communication system for freight shipping organizations, and methods of use - Google Patents

Abstract

Presented herein are systems and methods of securely sharing data from multiple sources with different client terminals. A server may establish an electronic document for defining a transaction. The electronic document may have data fields. Each data field may be from a client terminal. The server may identify encryption keys to encrypt the corresponding data fields included in the electronic document. The server may distribute the encryption keys across the client terminals in accordance with an access control policy. The access control policy may specify access permissions for a client terminal to each of the plurality of data fields based on a role of the client terminal in the transaction. The server may provide, to each client terminal with access to the data fields in the electronic document via the encryption keys distributed in accordance with the access control policy.

Description

Zero-trust communication system for freight transportation organization and its use method

The present invention relates to systems and methods for exchanging encrypted data, including but not limited to systems and methods for exchanging encrypted data in a zero trust communication environment.

Shipping goods over long distances in containers is a standard form of transportation. Intermodal containers are used to transport goods by car, train and ship. Units are stackable and designed to move from one form of shipping to another without opening the container. A shipment that may involve the delivery of one or more containers is a shipping carrier's commitment to deliver the Goods in intermodal containers or as item goods (collectively, "Goods" or "Cargo"). In order to successfully complete a shipment, relevant information needs to be shared among the different parties involved in the shipment. Such parties include, but are not limited to, shipping carriers, ship operators in transit, ports/terminals, government agencies, and carriers in transit (including shippers, consignees, and sometimes forwarders and notifying party). Other parties may also be involved in a shipment of goods.

Described herein are systems and methods for using a communication system in which zero trust is involved. The communication system may be designed to work with users who may be direct competitors or sub-competitors of each other, but sometimes desire or may need to work in the same space in order to achieve their business goals.

Businesses involved in the loading, unloading, and movement of shipping containers (sometimes called intermodal containers) communicate with each other using business-to-business (B2B) communications, electronic data interchange (EDI), and application programming interface (API) calls. These communication channels are point-to-point, requiring one party to communicate with another party. The person-to-person nature of this communication generally does not allow multiple parties to "stay in the loop" at the same time. There are also variations in the agreements adopted by different parties in how they handle communications, so communications may be delayed or subject to corporate principles that reduce the timeliness of such communications. The geographical distribution of the parties in moving goods causes communication delays. Goods can originate in Asia and go to locations in the Americas, Europe or Africa. A convenient time to attempt a communication by one party may be after the other party's business hours, resulting in further delays.

Organizations that compete directly with each other sometimes share resources to accomplish their corporate responsibilities. Such as two or more shipping companies share their ships to transport goods, so that better service coverage and economies of scale can be achieved. Another example is where multiple shippers using the same forwarder can share a single intermodal container to avoid each having to pay and transport a separate partially filled intermodal container. Other economical and better service performance is achieved when companies can coordinate their activities. However, coordination often requires revealing confidential information, which companies are reluctant to do. There are also regulatory requirements that prohibit the sharing of certain types of information with certain parties. More generally, each party has confidential information. The need to protect confidential information (such as business contacts, customer lists, pricing information, etc.) is critical to maintaining a competitive advantage and regulatory compliance in the marketplace. Therefore, parties that compete with each other or need to use each other's services do not share their confidential information.

Methods of handling intermodal containers and tracking their location tend to focus on the contents of the container, or tracking in small locations rather than in a global sense. Therefore, there remains a need for a communications and data control system that allows parties working together for a common task to share confidential information in a format that allows each party to see only what they need to perform part of their task information, while keeping any other information confidential from the source (of the information). There is a further need for a system that reduces the time required to track shipments anywhere in the path of the shipping process and provides timely updates of the location of both intermodal containers and item shipments.

There is a further need to provide various parties associated with the shipping, delivery loading and unloading of intermodal containers and project shipments with timely status and shipping updates for such shipments, while protecting data privacy and commercial confidentiality. These and other objectives can be met by the following disclosure.

A system for generating a shipping document is described. The system may have a transport document control hub and one or more user nodes. The transport document control center may have a computer having a logic, a memory and a communication device. The hub may also have a message broker capable of sending and receiving event messages. There may be an access policy repository that stores the global membership list, the access policy document list, and the role list list. There may also be a public key repository stored on the memory. There may also be an identification code (ID) repository having a list of one or more users, one or more user login credentials, and one or more user parameters. There may also be a blockchain database comprising one or more blockchain nodes that store the encrypted shipping document, the encrypted data encryption key and the signature of the document originator. The user nodes may have a computer, a message broker, a key store for decrypting transport documents, an API interface with a cryptographic layer for encrypting transport documents, and for accessing the transport One or more of one of the portals of the document control center. The API interface can be implemented logically on the user's computer and communicate with the transport document control hub message broker.

An independent user node for use in generating a single common shipping document transaction is also described. The user node may have a computer with logic for executing program instructions, a memory device, a user interface, and a communication device for accessing a transport document control hub. The user node may have a message broker capable of sending and receiving event messages. An API interface may have a cryptographic access layer, the API interface coordinating the correspondence between the common transport document transaction and the transport document control center. The user node may also have a blockchain database stored on the memory device. The memory device can be local, remote, cloud-based or removable. The blockchain database may have shipping documents associated with user roles in a single shared shipping document transaction.

An independent transport document control hub for coordinating communications between a first user node and a second user node in a common transport (electronic) document distribution is also described. The shared shipping document may have encrypted data attributes, encrypted data encryption keys, and/or a digital signature of the originator of the document. The transport document control hub may use a computer having logic for executing program instructions, a memory device, and a communication device for communicating with the user nodes. There may be a communication routing controller that may use a routing logic to route a common shipping document received from the first user node to the second user node. The second user node may be one of the transporters of the shipping documents provided by the first user node. There may be a distributed ledger stored on the memory. The decentralized ledger can be a blockchain database for storing encrypted shared shipping documents (or selecting data attributes of a shared shipping document). A hash of the encrypted data encryption key and the encrypted common shipping document and the digital signature of a document originator of the common shipping document may also be stored.

There is also a method of generating a common shipping document. The method may involve: generating a shared transport document and encrypting the shared transport document by a cryptographic access layer in an API interface; the encrypted shared transport document, an encrypted data encryption key and a digital signature of the document originator Submit to a transport document control hub (hub); identify one or more users, and each user may have at least one assigned role according to an access control principle; the encrypted common transport document, the encrypted The data encryption key and the digital signature of the originator of the document are forwarded to the one or more users, where the one or more users may Assign a role to perform one of the roles of the encrypted transport document.

There may also be a method for identifying user access rights to the common shipping document. The method may involve receiving a shipping document to be shared by at least one user, the document having an originator, a role list, and an identification code. Then identify the originator, determine the role of the originator based on a global user list (or global membership list), verify the role list of the shared transport document, and use the data encryption key to at least one of the shared transport documents Encrypting data attributes, encrypting the data encryption keys with the public key of the relevant transporter according to the access principle, and distributing at least one data attribute thereof to at least one authenticated user.

Additional aspects are also described.

The cargo tracking systems and methods described herein can help companies and individuals track the progress of cargo containers, such as intermodal containers, through the shipping process. This can be accomplished by assigning each party a role as each party provides shipping documents to the system. The system can organize the shipping documents and encrypt the shipping documents according to a logical scheme. The shipping documents may undergo a process in which the encrypted shipping documents may be shared with other parties that are logically related to each other (eg, when all of them are associated with a common carrier or agent). The information corresponding to the transported goods may be updated at various times and events during the transport of the goods from the origin point to the destination point. Each update results in new encrypted shipping documents that can be shared with all parties sharing a logical, business or financial relationship.

A shipping document representing a shipment may contain information about the shipment of the shipment, such as which product can be shipped, how much it weighs, and whether it requires any special handling (to name a few). The shipping document may also contain information about the parties involved (eg shipper, consignee, shipping carrier) and route information for the shipment. Additionally, the shipping document may contain one or more event records that store things that occurred during shipping that are meaningful to its status. In summary, the shipping document may cover various other details that may be relevant to any shipment. The access policy for the shipping document may also contain information about who can take on a shipping role. A shipping document can be added, edited or read in the system. In some embodiments, the shipping document may contain information about a user. In some embodiments, the shipping document may be a virtual document for a shipment of goods. In some embodiments, the shipping document may contain information about a user.

In some embodiments, the party accessing the system may be a user of the system. These users can have various access levels and privileges to the system. In some embodiments, the users may be able to read data presented in the system. In some embodiments, users may be able to create profiles in the system. In still other embodiments, the user may be able to update existing information in the system. In some embodiments, a user may be able to do one or more of: create the data in the system; read the data in the system; and update the data in the system.

In some embodiments, there may be one or more membership levels in the system. These different membership levels may be accompanied by different access rights or authorizations. In some embodiments, these different access rights may be accompanied by different fees.

In some embodiments, there may be a system that receives user information and stores information related to the shipping and tracking of containers in real time. The system may include a computer having a processor, a memory device, and a communication interface for accessing the Internet. The computer system can receive data from one or more users via the communication interface. The data can be processed and collected and classified into an organized data structure in the memory device. The computer may have logic that enables the computer to convert the data from one or more users into an encrypted record. The computer may encrypt the data using various encryption methods to generate the encrypted shipping document. A series of data encryption keys may also be generated, where one data encryption key is provided for each attribute in the transport document. The relevant individual data encryption key can be encrypted by the user's public key based on the user's role of the relevant transporter. The user's public key is called a key encryption key. These encrypted data encryption keys and encrypted data encapsulations may be provided to each user through a blockchain node available to the system for each user. Nodes can be shared or dedicated to a carrier. A user can decrypt the encrypted data encryption keys using a private key, and then use the decrypted encryption keys to decrypt the relevant data in the node.

In some embodiments, there may be a method of protecting the data privacy of a transport document shared among a distributed group of users. The method includes receiving, via a communications network, the shipping document from a user, the user may have an assigned role, wherein the shipping document includes a plurality of data attributes. There may also be encryption of the plurality of data attributes into a similar number of encrypted data attributes via a first encryption logic that generates a data encryption key corresponding to each encrypted data attribute. The method may also involve organizing, via a programmed logic, the plurality of encrypted data attributes into a distributed data ledger containing at least one encrypted transport document from a user. The method further involves encrypting the encryption keys corresponding to the plurality of data attributes via a second encryption logic that can use one of the distributed data ledgers based on the user's assigned role or a lookup table of permissions provided by multiple users. The method may also have: distributing the encrypted data attributes, the encrypted data encryption keys to the blockchain nodes via the communication network in a more efficient manner, so that the entire solution is scalable . Each user has access to a node that provides access to one of these distributed data ledgers. Each user can decrypt only data related to their assigned role.

The first encryption and the second encryption can utilize various encryption techniques. User-assigned roles can be associated with a user access control policy.

The use of systems and/or methods can provide a combination of context sensitive data isolation, encryption and access control principles to achieve data privacy of a distributed ledger technology.

At least one aspect of the present invention is directed to a method for securely sharing data from multiple sources with different client terminals. At least one server with one or more processors can create an electronic file that defines a single transaction. The electronic document may have a plurality of data fields. Each of the plurality of data fields may be associated with one of the plurality of client terminals. The at least one server can identify a plurality of encryption keys for encrypting the corresponding plurality of data fields contained in the electronic document. The at least one server may distribute the plurality of encryption keys across the plurality of client terminals according to an access control principle. The access control policy may dictate each of the plurality of data fields based on a role of the corresponding client terminal in the single transaction for one of the plurality of client terminals access rights. The at least one server may provide each of the plurality of client terminals with at least one of the plurality of data fields in the electronic document via the plurality of encryption keys distributed according to the access control principle access to one.

In some embodiments, creating the electronic document may include receiving, from a first client terminal of the plurality of client terminals, updating one of the plurality of the data fields in the electronic document a first A request for an attribute of a data field. In some embodiments, creating the electronic file may include determining that the first client terminal has the ability to modify the first data based on a role of the first client terminal in the single transaction according to the access control principle Permissions for the field. In some embodiments, creating the electronic document may include permitting the client terminal to update the attribute of the first data field in the electronic document in response to determining that the first client terminal has the permission.

In some embodiments, the at least one server may update one of the plurality of the data fields in the electronic document in response to receiving an update from a first client terminal of the plurality of client terminals A request for an attribute of a first data field identifies a role of the first client terminal from a list of roles in the single transaction. In some embodiments, the at least one server may determine that the first client terminal lacks the ability to modify the first data field based on the identified role of the first client terminal according to the access control principle. permissions. In some embodiments, the at least one server may prevent the attribute of the data field in the electronic document from being updated by the first client terminal in response to determining that the first client terminal lacks the permission.

In some embodiments, identifying the plurality of encryption keys may include identifying a plurality of private encryption keys and a plurality of public encryption keys for the corresponding plurality of client terminals. In some embodiments, distributing the plurality of encryption keys may include providing a private encryption key of the plurality of private encryption keys to a corresponding one of the plurality of client terminals. In some embodiments, distributing the plurality of encryption keys may include providing one of the plurality of public encryption keys to at least one of the plurality of client terminals according to the access control principle By. At least one of the plurality of data fields in the electronic document can be accessed by at least two of the plurality of client terminals using at least one of the private encryption key and the public encryption key.

In some embodiments, the at least one server can be selected from the plurality of servers based on a first role of a first client terminal and a second role of a second client terminal according to the access control principle The client terminal identifies the first client terminal and the second client terminal. In some embodiments, the at least one server may use a public encryption key of the second client terminal to update the first client terminal in response to identifying the first client terminal and the second client terminal One of the client terminals is encrypted with a first encryption key. In some embodiments, distributing the plurality of encryption keys may include providing the first encryption key of the first client terminal encrypted with the public encryption key of the second client terminal to the The second client terminal.

In some embodiments, the at least one server can identify a plurality of hash values derived from corresponding plurality of attributes in the plurality of data fields of the electronic document. Each hash value of the plurality of hash values may ensure data integrity of one of the plurality of attributes. In some embodiments, the at least one server may use a first hash value of the plurality of hash values and the plurality of encryption keys for a first client terminal of the plurality of client terminals One of the first encryption keys produces a first signature. The first hash value may be derived from a first attribute of the plurality of attributes. The first encryption key may be for a first data field of the plurality of data fields corresponding to the first attribute. The first signature can ensure the data integrity of the first attribute and the first data field.

In some embodiments, the at least one server can be selected from the plurality of servers based on a first role of a first client terminal and a second role of a second client terminal according to the access control principle The client terminal identifies the first client terminal and the second client terminal. In some embodiments, providing access may include providing the second client terminal to the second client terminal via a hash value derived from an attribute of the data field and a signature of the first client terminal Access to one data field of the plurality of data fields of a client terminal. The second client terminal can obtain one encryption key among the plurality of encryption keys of the first client terminal using the hash value and the signature.

In some embodiments, the at least one server may determine whether the distribution of the plurality of encryption keys across one of the plurality of client terminals was successful. In some embodiments, the at least one server may provide an event notification to at least one of the plurality of client terminals based on a determination of whether the distribution of the plurality of encryption keys was successful.

In some embodiments, identifying the plurality of encryption keys may include aggregating a corresponding encryption key of one of the plurality of encryption keys from each of the plurality of client terminals. The corresponding encryption key can be generated by the client terminal to encrypt one of the plurality of data fields. In some embodiments, creating the electronic document may include creating the electronic document on a database of a transport document control center to coordinate communications among the plurality of client terminals, the plurality of data fields of the electronic document The locations correspond to the corresponding plurality of database items on the database.

In some embodiments, the single transaction may involve a physical item and may include a series of sub-transactions for the physical item. Each of the plurality of data fields can be mapped to one of the sub-transactions. In certain embodiments, each of the sub-transactions for the physical item may be handled by at least one service provider.

At least one aspect of the present invention is directed to a system for securely sharing data from multiple sources with different client terminals. The system can include at least one server having one or more processors. The at least one server can create an electronic file for defining a single transaction. The electronic document may have a plurality of data fields. Each of the plurality of data fields may be associated with one of the plurality of client terminals. The at least one server can identify a plurality of encryption keys for encrypting the corresponding plurality of data fields contained in the electronic document. The at least one server may distribute the plurality of encryption keys across the plurality of client terminals according to an access control principle. The access control policy may dictate each of the plurality of data fields based on a role of the corresponding client terminal in the single transaction for one of the plurality of client terminals access rights. The at least one server may provide each of the plurality of client terminals with at least one of the plurality of data fields in the electronic document via the plurality of encryption keys distributed according to the access control principle access to one.

In some embodiments, the at least one server can receive updates from a first client terminal of the plurality of client terminals to update one of the plurality of the data fields in the electronic document. A request for an attribute of a data field. In some embodiments, the at least one server may determine that the first client terminal has the ability to modify the first data based on a role of the first client terminal in the single transaction according to the access control principle Permissions for the field. In some embodiments, the at least one server may permit the client terminal to update the attribute of the first data field in the electronic document in response to determining that the first client terminal has the permission.

In some embodiments, the at least one server may update one of the plurality of the data fields in the electronic document in response to receiving an update from a first client terminal of the plurality of client terminals A request for an attribute of a first data field identifies a role of the first client terminal from a list of roles in the single transaction. In some embodiments, the at least one server may determine that the first client terminal lacks the ability to modify the first data field based on the identified role of the first client terminal according to the access control principle. permissions. In some embodiments, the at least one server may prevent the attribute of the data field in the electronic document from being updated by the first client terminal in response to determining that the first client terminal lacks the permission.

In some embodiments, the at least one server can identify a plurality of private encryption keys and a plurality of public encryption keys for the corresponding plurality of client terminals. In some embodiments, the at least one server may provide a private encryption key of the plurality of private encryption keys to a corresponding one of the plurality of client terminals. In some embodiments, the at least one server may provide one of the plurality of public encryption keys to at least one of the plurality of client terminals according to the access control principle. At least one of the plurality of data fields in the electronic document can be accessed by at least two of the plurality of client terminals using at least one of the private encryption key and the public encryption key.

In some embodiments, the at least one server can be selected from the plurality of servers based on a first role of a first client terminal and a second role of a second client terminal according to the access control principle The client terminal identifies the first client terminal and the second client terminal. In some embodiments, the at least one server may use a public encryption key of the second client terminal to update the first client terminal in response to identifying the first client terminal and the second client terminal One of the client terminals is encrypted with a first encryption key. In some embodiments, the at least one server may provide the first encryption key of the first client terminal encrypted with the public encryption key of the second client terminal to the second user terminal.

In some embodiments, the at least one server can identify a plurality of hash values derived from corresponding plurality of attributes in the plurality of data fields of the electronic document. Each hash value of the plurality of hash values may ensure data integrity of one of the plurality of attributes. In some embodiments, the at least one server may use a first hash value of the plurality of hash values and the plurality of encryption keys for a first client terminal of the plurality of client terminals One of the first encryption keys produces a first signature. The first hash value may be derived from a first attribute of the plurality of attributes. The first encryption key may be for a first data field of the plurality of data fields corresponding to the first attribute. The first signature can ensure the data integrity of the first attribute and the first data field.

In some embodiments, the at least one server can be selected from the plurality of servers based on a first role of a first client terminal and a second role of a second client terminal according to the access control principle The client terminal identifies the first client terminal and the second client terminal. In some embodiments, the at least one server may provide the second client terminal with the data via a hash value derived from an attribute of the data field and a signature of the first client terminal Access to one data field of the plurality of data fields of the first client terminal. The second client terminal can obtain one encryption key among the plurality of encryption keys of the first client terminal using the hash value and the signature.

In some embodiments, the at least one server may determine whether the distribution of the plurality of encryption keys across one of the plurality of client terminals was successful. In some embodiments, the at least one server may provide an event notification to at least one of the plurality of client terminals based on a determination of whether the distribution of the plurality of encryption keys was successful.

In some embodiments, the at least one server may aggregate one of the plurality of encryption keys corresponding to the encryption key from each of the plurality of client terminals. The corresponding encryption key can be generated by the client terminal to encrypt one of the plurality of data fields. In some embodiments, the at least one server can create the electronic document on a database of a transport document control center to coordinate communication among the plurality of client terminals, the plurality of data fields of the electronic document The locations correspond to the corresponding plurality of database items on the database.

In some embodiments, the single transaction may involve a physical item and may include a series of sub-transactions for the physical item. Each of the plurality of data fields can be mapped to one of the sub-transactions. In certain embodiments, each of the sub-transactions of the physical commodity may be handled by at least one service provider (eg, shipper, carrier, ship operator, terminal operator). A service provider may also be referred to as a facilitator or transaction member/user.

Alternative embodiments of systems and methods will be apparent to those skilled in the art based on a study of the present invention. Such alternative embodiments are intended to be equivalents for the purposes of the claims appended hereto.

Cross-references to related applications

This application claims priority to U.S. Provisional Application 62/919,097, filed on February 25, 2019, and entitled "Encrypted Distributed Ledger for Use with Freight Shipping Organizations, and methods of use", the contents of the U.S. Provisional Application is incorporated by reference in its entirety. This application is a continuation-in-part of US 16/501,399, entitled "Zero Trust Communication System for Freight Shipping Organizations, and Methods of Use," filed on April 5, 2019, which is incorporated by reference in its entirety. Incorporated herein.

The sharing of information by multiple parties can create synergies and efficiencies. However, information required or utilized when conducting a single transaction (eg, multi-level transaction, multi-party transaction, a sub-transaction series/sequence) may be confidential to one or more of the parties involved in the single transaction data sharing can be a problem. In the field of transporting goods, this problem can be particularly acute. Other businesses can also have this problem. A possible solution could be a system and procedure that utilizes encryption techniques to protect data privacy while allowing appropriate parties to share relevant data in a decentralized ledger system, as described herein. The systems and methods described can be useful in transporting goods and goods. The systems and methods described herein may also be applied in other industries.

The cargo tracking system and method described herein can help companies and individuals track the progress of cargo through the shipping process. This can be accomplished by having each user provide shipping documents to the system. The system may contain a lookup table that provides a list of roles and the rights of each role. When a user submits a shipping document to the system, the shipping document may contain the user's identification code, and a list of roles for the individual shipping party. The system can correlate the roles listed from the user of the shipping document with the rights of the roles in a lookup table. The system can process shipping documents, so users and associated shipping parties may be able to access the data after it has been encrypted. Each user in the system can have one or more defined roles. Access to each data attribute in a transport document can be defined by the user's role. A user can access only data related to the user according to the user's role in the access control policy.

The system can recognize a shipping document submitted by a user and can encrypt each data attribute of the shipping document. The first encryption process may create an individual encryption key for each data attribute.

As an example, a shipping document may have five headers and five data attributes. The first encryption program may encrypt the five data attributes without encrypting the five header fields. The distributed ledger may also have a header field corresponding to at least one of each encrypted data attribute. The header fields of the distributed ledger correspond to at least one of the header fields of the shipping document. In some embodiments, the header fields of the distributed ledger correspond to the header fields of the shipping document on a one-to-one basis. The distributed ledger header fields may not be encrypted, but the data attributes corresponding to each header field of the distributed ledger may be encrypted. A second level of encryption can be used to encrypt each of the encryption keys in the data attributes of the distributed ledger. This second level of encryption can be performed by using the public key of one or more users with known roles in the transport process. The second encryption process can identify the user's role in shipping by correlating the user's role from the shipping document with a look-up table. The user's public key can then be used to encrypt encryption keys corresponding to data attributes associated with the user based on the user's assigned role and access policy. Various attributes (encrypted data attributes, encrypted encryption keys based on different roles, hashes (generated from encrypted data attributes), and document originator's signature) can be placed into a permission-based blockchain decentralized ledger in the blockchain node. Certain users may have their own blockchain nodes. To improve scalability and performance when using the blockchain decentralized ledger, data can be placed in nodes that are users involved in the transport.

Each user in the system can have one or more assigned roles. Each shipping document role list may identify the roles of users who submitted the shipping document role lists, and the shipping document role lists may identify the roles of users that may be involved in the transport. In some embodiments, the persona list can track who created it, the user's persona and a list of corresponding users, and a locator key (creator's identifier and shipping document's subscription number).

The various embodiments set forth herein can be used with all types of shipping documents. A common transport document is a "reservation" - a precursor document that creates a bill of lading. Although many shipping documents may be used with the present system, many instances may use the terms "reservation" or "reservation data." These terms shall be considered identical to any shipping document or shipping document information, respectively.

In some embodiments, there may be a relationship between the various users that allows them to see each other's data attributes. In some embodiments, there may be business relationships built into lookup tables that allow a user to see data that is not part of their own business. A lookup table of access rights can be derived by each party identifying what rights it needs and what rights it desires, with the system controller being the final arbiter of rights each user has.

In some embodiments, the distributed ledger may represent a single shipping document. In some embodiments, there may be multiple shipping documents incorporated into a single decentralized ledger.

In certain embodiments, asymmetric cryptography may be used as part or all of the encryption methods described herein.

Schematic diagram of the overall procedure in a particular method.

A procedure for tracking the status of a shipment in a freight lane is shown in FIG. 1 . Shaded ovals show the various parties in a single shipping transaction and how they communicate with each other using EDI (Electronic Data Interchange). Examples of parties are shown as a shipper, forwarder, carrier, terminal, customs, port authority and consignee.

Brief description of the parties

Shipper - The company or person who transports the goods to the consignee.

Consignee - A person or company named in the contract of shipment to whom the goods have been transported or handed over to a caretaker.

Forwarder (or freight forwarder) – A person or business engaged in the business of assembling, collecting, consolidating, transporting and distributing less-than-carload or less-than-truckload cargo. And a person who acts as an agent in the transshipment of goods through customs (including full preparation of documents, arranging transportation, warehousing, delivery and export clearance).

Carrier - An individual or legal entity that operates to transport passengers or goods for rental.

Ship operator – any business unit responsible for the operating costs, maintenance and surplus of a ship. The operator may or may not be the owner of the ship. Costs include crew wages, port dues and hull insurance. Ocean carriers share the use of ships through alliances or ship sharing agreements, and one of the ship owners (ship operators) of one carrier may carry shipments booked through other carriers.

Terminal Operators – Marine Terminal Operators (MTOs) provide terminal berths, docks, warehouses or other marine terminal facilities for marine co-carriers who move goods in maritime foreign trade.

In addition to these parties to the transport of a cargo, there may also be other parties interested in the transport of a cargo, such as government agencies (customs, inspection bureaus), financial institutions, insurance companies, etc.

A shipper 102 may generate a product shipment and provide information to other parties through direct communication. These are from shipper 102 to forwarder 104, carrier 106, terminal 108, customs 110, port authority 112, consignee 114 and, if necessary, a financial institution 116 (such as a bank, lender, insurance company , bondholders, etc.) one-way communication. As can be seen in Figure 1, each communication with the other parties is a one-way communication with one of the parties, each party essentially sending to the other parties certain information related to a shipment, And then the receiving party sends a response to the original party. Each party to the proceedings may have developed its own proprietary technology for this form of communication. The communication protocols are not integrated to work together, so each receiving party will receive a message and then respond with its own protocol and wait for the other parties to respond. This procedure is inefficient and time consuming.

Each party in a contract of carriage may be assigned one or more roles in the carriage. Various roles are shown in Figure 2. The location of each assigned role is marked by a different shading in the figure. Figure 2 is merely illustrative. Many other character positions are possible and exist in actual transactions. A system for creating and shipping shipments worldwide can be seen in the illustration 200 shown in FIG. 2 . In some embodiments, a shipper 202 may initiate a shipping reservation by determining that merchandise will be picked up and shipped to a particular destination. The shipper 202 can create a booking request (a preliminary step in forming a commercial contract to send the cargo) and designate a port authority 204 with terminals A, B and C as shown. The shipper may also select a ship or vessel to carry the goods by a ship operator 206 . The shipper 202 may also designate a final consignee 208 for shipment. A route that a transport may take is also illustrated by way of example in FIG. 2 . If the path from the origin (the place of receipt) to the end (the final destination) is followed, it can be seen that there are many parties involved. Shipping merchandise within this route may involve a number of parties, all of which have their own modes of communication, as previously explained.

The above examples do not show all parties that can be involved in a shipment. A port authority 204 may have several agents working under its jurisdiction whenever cargo enters a port. There may be various inspectors (eg, for grain, livestock, fruit and vegetables), inspections for unauthorized dangerous goods, ITC inspections to certify any sanctioned material, immigration inspectors, etc. A terminal operator may be a private company with terminal facilities under its authority in several other ports. In some cases, a party may belong to a larger company where the company must communicate up or down the chain of subsidiaries of a parent organization.

Described herein are various embodiments of a system and method for creating a new type of reservation contract (a type of shipping document) that allows the relevant parties to the agreement to check by having a single point of contact And track the progress of shipments. This single point of contact provides up-to-date information that is available to all relevant parties and avoids restrictive communications that would have each party communicate with every other party one at a time or in a sequential manner. Each user can be continuously updated as the item moves through the various stages of transport. Such updates may include status of goods, liabilities, regulatory matters and other issues.

As used herein, the term "user" may refer to an individual or tissue. A user may be any person, party, organization, or program that has access to the system and interacts with the programs described herein. Any individual or entity that has access to a system as set forth herein can be considered a user. The present invention also utilizes a list detailing the specific rights, privileges and responsibilities of each user. In general, a user can represent a role in a transaction, although it is not necessary for each user to be a party to the transaction. The terms "user" and "party" are used interchangeably herein unless the context clearly dictates otherwise.

In some embodiments, a user can log into the system and then obtain key vault access and various assigned keys. The user may initiate a key vault process 300 (FIG. 3), to an initial login or start 302 of the system. The user logs into the system and the system can log into a key store and cause the key store to generate a key repository 304 for the user. A global user list (or global member list) of the system can record the basic information of users. This basic information may include the user's name, the user's role in any booking, contact information, and other information related to the user's role. The system may store 306 the mapping of the user's key vault in a key vault mapping database. Then, the user can log into the system to generate the public key and the private key. The private key may be stored 308 in the user's private key repository. The system may obtain the public key from a key repository and store 310 the public key in a public key repository. Once the two keys are secured in their respective repositories, the process can end 312. In certain embodiments, a user may have pre-configured access to a key repository and use a pre-existing key repository in conjunction with the system as set forth herein.

In some embodiments, a party can track one or more keys at a time. Key location 400 (FIG. 4) can be used so a party can have access to its own private key 404, while the system can use the party's public key 402. Each user may have a key repository with a private key 404 and a public key 402 . The public key can be stored in the system service provider network. The system can encrypt a data encryption key by using the public key of the user organization. This encryption can take place in the system service provider network. When the system decrypts the encrypted data encryption key (DEK), the system sends the encrypted DEK to the keystore network via a secure network connection 410. The keystore can then decrypt the encrypted DEK 406 using the user's private key 404 to generate a decrypted DEK in the keystore network. The key store can then send the decrypted DEK 408 back to the system again via a secure network connection 412. A user can use DEK 408 to decrypt encrypted data associated with that particular key.

In some embodiments, each data attribute encryption key may be encrypted using a separate public key or a separate encryption protocol, but the same public key is used to encrypt the data encryption key. In the event that a particular user may have a role that allows that user to see multiple data attributes in each subscription record, the above procedure may be repeated for each field the user accesses. The use of this encryption and decryption process occurs in the communication between the various systems and may be invisible to those accessing the database information.

In some embodiments, a user may gain access to the system through an authentication process 500 (FIG. 5). The user can access a client application 502 by providing his login name and password. Client application 502 can provide organizational authentication to authorized users and can send login requests to an authorization token generator 506 through a secure network connection 504 . The client application 502 may provide authentication information (eg, username and password and any other authentication information). For example, the authentication information can be an API subscription ID and secret (eg, password). The authorization token generator can receive the API subscription ID and secret from the client application and verify the information against the API subscription database. Once the items can be authenticated, the token generator 506 can generate a token that can be communicated back to the user. The user's client application 502 can then use the token to communicate with the subscription API 508 over the secure network connection 504. The user may gain access to the subscription API 508 to enter and/or access data.

In some embodiments, client application 502 may be a web-based portal and portion of authorization token generator 506 or subscription API 508 . In some embodiments, the client application 502 may be the client's own software, and the authorization token generator 506 and subscription API 508 may be debugged to communicate with the client software. In some embodiments, authorization token generator 506 and subscription API 508 may be the same application (not shown). In some embodiments, the authorization token may have a predetermined time limit on how long the client application can access the subscription API 508, or the client application 502 may have to make itself available for authorization at each stage of work Rod generator 506 authenticates. In some embodiments, a predetermined amount of time can be set as a "timeout" security protocol to automatically log out a user after a set period of inactivity.

In some embodiments, there may be three domains of the API manager, as shown in FIG. 6 . In some embodiments, a handshake of the API interface 600 is shown. The API interface 600 can use client applications 602 , API management tools 604 and a blockchain API 606 . A client application 602 may be an application created by a client (user) or an application specifically created to work with the API management tool 604 . The user can log into the client application 602 and can submit a request (eg, create a subscription request), and the client application 602 can send an authentication request 608 (in some embodiments, which can include the API subscription ID) and a secret) to the API management tool 604. Verification request 608 may result in a user authentication 616 result, or an error (not shown). If user authentication 616 is the result, API management tool 604 may then generate an access token and pass token 610 back to client application 602 . The client application 602 may then send the access token and subscription request payload 612 to the API management tool 604 . When the API management tool 604 receives the token and payload 612 request, the API management tool 604 may provide token authentication 618 . The token can then be authenticated, and the token can be resolved to an organization ID based on the token-to-organization mapping. The organization ID and payload request can then be sent 614 to the blockchain API 606 to write to the blockchain node.

The example embodiment shown in FIG. 6 has three domains. Client application 602 may exist in a network of client applications. API management tool 604 may reside in a network of API management tools, and blockchain API 606 may reside in a network of system service providers. However, in some embodiments, the API management tool network and the system service provider network may be combined into a single system network. In yet other embodiments, more than 3 domains may be used.

In some embodiments, there may be an API manager 700 as shown in FIG. 7 . API manager 700 may provide a user with access to the system of the present invention and authenticate the user to the system upon login. A user may begin at start block 702, where the user may access the system through an API manager 700 that authenticates a user, as described herein. The subscription ID can be assigned to the user by the system, or the user can select a subscription ID (eg, from a drop-down menu, or a set of system options) and the system records it. The subscription ID can be based on a subscription fee (payment based on a currency, a barter), or it can be free. Subscription IDs may be issued to regulators, payment customers, system administrators, or any other party requiring access to the systems described herein. Each user may also have a secret that can be sent to the system with a login request or with every communication with the system. Once the user has established a secret with the system, the secret can be stored in a database of API manager 700 or API manager 700 may access to check user secrets as needed. Additional steps may be taken, or alternative steps may be taken in place of the subscription ID and secret challenge, so that any form of acceptable security for authentication of a user may be used.

The system can check the authentication certificate against its own criteria to verify that the authentication is correct 706. If authentication fails, an error can be reported 714 and the process ends 716. When authentication is successful, a token can be sent 708 to the client application. The client application can then submit the token along with a payload request 710 to the API management tool. The API management tool can check the token to see if it is valid 712. If the scepter is not valid, an error response 714 may be returned. If the token is valid, the token can be resolved to an organization ID 718 based on the token and organization mapping. The organization ID and payload request can then be forwarded to the blockchain API and the process ends 716 .

The payload request may be the reservation request data for the reservation request API (or other shipping document API). When the token and organization ID are confirmed by the system, the data can be stored to the same database as the reservation reservation request is made. Data can be encrypted and stored in a blockchain database. As set forth herein, the data used for the subscription request may contain header fields. Each data attribute may have a corresponding header field. Data properties can be stored in the database with or without a corresponding header field. In situations where data can be stored without a header field, each data attribute can contain an indicator of the header field it came from, so when reading the data, it can be in the appropriate field Display the information appropriately. Similarly, header data can be useful when using encrypted data to construct relationships between parties, such as when making a bill of lading (B/L).

In some embodiments, an overview of a process for distributing encrypted data and encrypted data encryption keys is shown in FIG. 8 . The process may begin at start block 802 and the system may encrypt 804 the data and the data encryption key, as described herein. The system can then find, access or locate the ledgers 806 of the sender and various transporters by using their organization IDs. The system can check to see if the ledger for all shipping parties can be found. If a ledger is not found, the system can return an error 810 response and the process ends. If the ledgers for all transporters are found, the system can proceed to send the data and data encryption keys to the ledgers.

The system can then proceed to send the encrypted data and encrypted data keys, and can check 808 (receive verification) that the transmission was successful to various appropriate ledgers. If the transmission was successful, the process may continue to end block 812 .

In some embodiments, a user may obtain subscription information via an obtain subscription process 900, as shown in FIG. 9 . The program may start 902 by looking for one of the latest versions 904 of the system execution subscription. The system can find the latest version 904 of a subscription by a unique subscription ID in the shipping document database. Records can contain ledger names. The system can search for (subscribe to) the latest version by the unique subscription ID 904. In some embodiments, the system may not find the correct profile record. When this happens, the system can generate and return an error 918. If a data record is found, the system can check the organization's access policy and check the access policy definition 906 to see what data the organization's permissions may be. If the organization does not have an access policy assigned to its role, the system may return an error 918 and the process ends 920. If the access principles and definitions are properly identified, the system can collect encrypted subscription data and encrypted data encryption keys from the ledger of subscriptions 908. A subscription's ledger can be located by its ledger name. The system can perform a check related 910 step where the encrypted subscription data and the encrypted data encryption key can be checked to see if they are the same in the decentralized ledger. If not, an error 918 response may be returned and the process ends. If the data is indeed related in different distributed ledgers, the program can log into the key store 912, and the key store uses the sender's organization's private key to decrypt the data encryption key. If the keystore cannot decrypt the data, an error 918 response can be generated and the process ends. The system can then decrypt the data and key 914 and publish the decrypted information 916 to the user. The process may then proceed to end block 920 .

A sample subscription list 1000 is shown in FIG. 10 . Here, each reservation created by a shipper using the reservation API can be listed and categorized based on a variety of different search criteria. Subscription sample list 1000 may represent a database of subscription records, which may be encrypted and stored in a database, as set forth herein.

An example of one of the repositories can be seen in Table I here. database name Description of one of the data in the database ID repository A user list, user login credentials and user parameters Access Policy Repository Global member list, access policy document list, role list list and dynamic access policy list public key repository A list of the user's public keys key storage area A list of the user's private keys Shipping Document Database a list of shipping documents, such as reservation requests global user list A list of all users and roles of each member can be presented in various shipping documents Role List Principle Defines a list of users and roles with access rights.

FIG. 11 illustrates a retrieval subscription process 1100 that has been placed in the system. The process begins at start block 1102 and can continue with an attribute verification 1104 of whether a submitted request for a subscription contains a unique subscription ID and the sender's organization ID. In some embodiments, the system may use the subscription number, version, and organization ID of the subscription provider. The system can evaluate whether the request can have the required attributes (attribute validation 1104). If the request does not have the required attributes, an error response 1116 may be generated and the process ends 1118. If the request has the required attributes, the program can obtain subscription information from the shipping document database and decrypt 1106 the encrypted subscription information. In some embodiments, the database may be encrypted in a blockchain format and stored in a decentralized ledger or a hyperledger. The system can check to ensure that the desired subscription is properly retrieved and decrypted 1108. If not, the system may generate an error response 1116. If the subscription is retrieved and decrypted, the system can now perform a shipping role check 1110 and can determine for each shipping party whether its organization's organization ID can be the same as the sender's organization ID. If so, the system can collect the transport role of the transporter.

The system can perform a transport role check 1110 to verify that at least one transport role is collected, and then for those collected transport roles, the system can obtain attributes that can be allowed to be read by those roles. In some embodiments, the system checks to see each transporter role, and based on the transport role check 1110, identifies the attributes that the party may be allowed to view. In some embodiments, attributes that parties may not be allowed to view are removed in a filter attribute 1112 check. When 1114 is successful, a successful response code can be returned.

Any errors that may remain unresolved may cause the program to terminate at end 1116 step.

The creation of a subscription reservation is now shown in FIG. 12 . Once a subscription payload request is received from a user or organization, the process of making a subscription begins (start block 1202). The system may first check to see if the submitted request contains a reference subscription number and the user's organization ID 1204 (check attribute validation). If the user's organization ID and/or subscription number is not in the submitted request, the system may report an error 1234 and the process may end 1236. If the organization ID and subscription number are present, the system can find a role list 1206 for a subscription by locating the subkey. The locator subkey can be constructed by referring to the subscription number and the user's organization ID. If the list of roles is not found, the system may report an error 1234 and the process may end 1236. If there is a list of roles, the system can check 1208 whether the access policy for the subscription can be defined. If no access policy is defined, the system may return an error 1234 and the process may end 1236. If an access policy is defined, the system can check for each transporter whether the transporter's org ID can be the same as the sender's org ID. If one or more of the organization IDs can be the same, the system can collect the transport role 1210 of the transporter.

The system can then check to see if at least one transport role can be collected. If no characters are collected, an error 1234 may be returned and the process may end 1236. If at least one role can be identified, the system can check 1212 whether the collected shipping roles have access rights to create all submitted attributes of the subscription profile. If the character does not have access, an error 1234 may be returned and the process may end 1236. If the access rights are correct, the system can generate a unique subscription ID 1214 for one of the subscriptions. Once the subscription ID is created, the system can generate individual data encryption keys 1216 for each data attribute. These keys may be symmetric keys. After generating the encryption key, the system may encrypt 1218 each data attribute with its data encryption key. In some embodiments, there may be one data encryption key (a 1:1 relationship) for each encrypted data attribute. The system can then retrieve the transport role information for each transporter, and can also retrieve the access control policy 1220 for each transport role. If a transporter has an access control policy, the system can retrieve the public key 1222 from the public key repository. The system can retrieve the appropriate key for the specific organization ID associated with the party assigned to the role. For each transporter, for the data attributes that can be read, the system encrypts 1224 the corresponding data encryption key one by one with the transporter's public key. The system can then distribute the encrypted data and the encrypted data encryption keys to the appropriate organizations 1226. The system can verify that the data and keys were successfully distributed to all ledgers 1228 of the relevant transporter. In some embodiments, the ledger may return a response indicating whether the encrypted data was successfully distributed and the encrypted data key. If the system cannot verify the proper distribution, the system may generate an error code 1234 and the process may stop 1236. If the system does verify the encrypted data and the distribution of the encrypted data encryption keys, the system may save 1230 the name of the ledger, the unique subscription ID, and the subscription version number in the shipping document database. The system may then generate a success response code 1232 and the process may end 1236.

In some embodiments, a shipping document control hub 1302 of one of the systems 1300 can be seen in FIG. 13 . In some embodiments, the transport document control hub 1302 may have a series of user nodes (for illustration purposes and presented as an example, user node 1 1306, user node 2 1324, and user node N 1342) . Each user node can be connected to a corresponding blockchain logic (1 to N) and own a blockchain node (1 to N). Blockchain Logic 1 1320 and Blockchain Node 1 1322 may be part of Transport Document Control Hub 1302. The transport document control hub 1302 may also have an off-chain database 1304 .

Each user node can be assigned to one or more users. For example, a first user node 1306a may be assigned to a carrier organization, and a second user node 1306b may be assigned to another carrier organization. Each user (such as a ship operator, a terminal operator, a consignee, a shipper, etc.) may have a user node 1306a-1306n assigned to it. Although three nodes are presented in the present diagram, it should be understood that this diagram is illustrative only and is not intended to be limiting in any way. The number of nodes the system can have is unlimited, as specified by the "n" notation. Each blockchain logic in each node can also communicate with an off-chain database 1304. In some embodiments, user nodes 1306a-1306n may access blockchain logic 1320a-1320n to write encrypted data and an encrypted data encryption key (DEK) to one or more blockchain nodes 1322a to 1322n. Cryptographic access layers 1314a-1314n may communicate with blockchain logic 1320a-1320n through a network communication 1318a-1318n. Any data sent between cryptographic access layers 1314a-1314n and blockchain logic 1320a-1320n may be encrypted. The cryptographic access layers 1314a to 1314n may perform various decryption and encryption functions based on an access principle. Cryptographic access layers 1314a-1314n can generate symmetric data encryption keys (DEKs), encrypt data with the DEK, encrypt the DEK with the transporter's public key and access a key store 1312a-1312n to encrypt the DEK decrypt. API interfaces 1316a-1316n, password access layers 1314a-1314n, and key stores 1312a-1312n may exist in an isolated network or user nodes 1306a-1306n that may be inaccessible without permission. Client applications 1308a-1308n can connect to an API interface 1316a-1316n to write to, or obtain data from, a blockchain node 1322a-1322n. Client application 1308a-1308n may be a computer, a server, or any computing device with a processor that accesses a memory device and accesses a network connection to communicate with blockchain APIs 1316a-1316n. In some embodiments, the network connection may be secured. Blockchain APIs 1316a-1316n may pass a request from client applications 1308a-1308n to cryptographic access layers 1314a-1314n. Client applications 1308a-1308n may also have a client application database 1310a-1310n. The data in the client application databases 1310a-1310n may be in plain text. Client applications 1308a-1308n can be searched directly in client application databases 1310a-1310n. Users can access client applications 1308a-1308n and then user nodes 1306a-1306n and then blockchain logic 1320a-1320n through their own network connections 1318a-1318n.

The instructions provided for user node 1306 may operate in a similar or identical manner to the instructions provided for user node 1324 . In some embodiments, the illustrated blockchain node components may be a distributed ledger. In some embodiments, the blockchain node component may be a hyperledger.

In some embodiments, an access control policy may be used to determine shipping document distribution, as shown in FIG. 14 . In some embodiments, various parties may provide a shipping document from a user node to a shipping document control hub. For example, both an example carrier and an example shipper with user end nodes can communicate a shipping document to a shipping document control hub. Each user node may have or have access to an API interface, a password access layer, and a key storage area. In the example shown, the carrier may send a list of transport document roles to the transport document control hub, and the shipper may send the transport document to the transport document control hub. The list of transport document roles and transport documents can be encrypted.

The transport document hub may have an access control policy (access policy) with a static part and/or a dynamic part, as shown in FIG. 14 . The static part may contain a list of global members and a list of access policy documents. The global membership list can be used to determine the role assigned by one of the members. In some embodiments, a member may have multiple assigned roles. The access policy may also have a list of access policy documents. These generally refer to the types of documents that can be used between roles in a shipment of goods. Some examples include, but are not limited to; a bill of lading, a dock loading or unloading manifest, a reservation contract, a pre-booking contract, and the like. The access policy may have an access policy document corresponding to each transport document type. The relationship between the access policy document and the transport document type may be 1:1, or it may be 2+:1 or it may be 1:2+. These various relationships and lookup features may generally be static. In some embodiments, the relationship between the access policy document and the transport document type may be updated and/or revised.

In some embodiments, each of the manifests, data structures, databases, and principles may have a dynamic version and a static version. The static version can be the last saved version, and the archive of each saved version can exist in the blockchain. A dynamic version may exist as a user or system update or to make changes to any of the items stored in memory or in the blockchain. In some embodiments, the dynamic version may only exist in temporary memory. In some embodiments, the dynamic version may be written to persistent memory or the blockchain.

In some embodiments, there may be a dynamic part of the access policy. An access policy can have a list of one of the dynamic role lists. In some embodiments, the dynamic role list may have a locator subkey that can locate one of the access policies corresponding to the role list. In some embodiments, a locator key can locate a character manifest or a shipping document. The shipping document may or may not be part of the access policy. Role lists can be built from one or more shipping documents using dynamic shipping parties. A dynamic access policy list may be provided for each shipping document associated with one of a particular access policy. In some embodiments, a list of roles in dynamic operations can be generated and submitted with the shipping document, and the list of roles can be assigned to a dynamic version of the static access policy document (thereby creating a dynamic and static access policy document), and can assign dynamic access policies to that transport document. In some embodiments, there may be a dynamic access policy as long as a shipping document exists, and the dynamic access policy controls the distribution of a shipping document and all documents associated with that particular shipping number.

In some embodiments, a carrier sends a reservation request to the shipping document control hub. The shipper instance may be similar to the carrier instance, but the list of roles used for distribution of the shipper's shipping documents may be an existing list of roles in the shipping document control hub. When a carrier submits a list of transport documents and roles, the carrier may pre-create the list of existing roles in the transport document control hub. Requests can be sent to individual members based on a list of roles. The document control hub may notify each user of the subscription request (or other document). For example, a ship operator can be notified that his vessel will carry a designated container, a terminal operator can be notified that it will receive a ship carrying a container, and a consignee can be notified to pick up the container at an estimated delivery date. In some embodiments, the system may record that each user has been notified of their respective responsibilities in the reservation request and record that notification. In some embodiments, each user may provide a response (manually or automatically) to the subscription request receipt. The response document is returned to the shipping document control hub and routed to the carrier. The role list can be part of the dynamic access policy, and the dynamic access policy can be used to control the distribution and sharing of documents used for this transaction until the transaction is completed. In some embodiments, the system may only verify data delivery and does not require a response from the receiving party.

In some embodiments, the access policy may have a list of global members (users). The list of global members (users) can be a list of all users of the system and the roles that each user can assume in various transport transactions and documents. These roles may correspond to those used in common shipping documents (eg, shipper, carrier, ship operator, terminal operator, etc.). An access policy may also have a list of access policy documents, each for a type of transport document (eg, Dangerous Goods (DG) document, bill of lading, container entry event, container exit event, etc.). An access policy can also have a list of role lists, each role list associated with any shipping document with the same locator subkey (eg, carrier + booking (BKG) number). An access policy may also have a list of dynamic access policies, each dynamic access policy being associated with any transport document with the same locator subkey and transport document type. The dynamic access principle may define which particular party can create, update, read and/or receive the common transport document and can create, update and/or read at the attribute level. The dynamic access policy can be derived from a role list for a given locator subkey and/or an access policy file for a given common transport document type.

When a user logs in to the user node to access the transport document control center, the user can be identified by his login credentials. The user's client application can send a list of transport document roles to the transport document control center. The transport document user node can identify the role list type based on the transport document role list. The Transport Document Client may obtain any one or more of the following information from the Access Principles from the Transport Document Control Hub: - The role of the user from the global user list (or global membership list). - Access policy document for role list type - a common access policy document for each common transport document type, and - A list of dynamic access principles, wherein the dynamic access principles are specific to a transport document, and the dynamic access principles define the access rights of each role to a transport document. - Any other information linked to access policies, user IDs, or user roles.

The transport document user node may verify that the user's role is allowed to create (update) a transport document role list against the access policy document. The transport document user node can identify roles with the newly assigned value from the transport document role list and further verify whether the roles of the users can be assigned to their roles.

The list of authenticated transport document roles can be encrypted and submitted to the transport document control hub, and can be added to the access policy for a specific locator subkey.

In some embodiments, the client application may send a transport document to the transport document user node. The user node can identify the document type and locate the subkey according to the transport document. The transport document user node can obtain the following information from the access policy from the transport document control center:- -Dynamic access policy for transport documents (at the document hub, dynamic access control principles are derived from the role list of the given locator subkey and the access policy file for a given transport document type after the transport document user node requests) -Access policy document for transport document type - Any other information that the user has access to or has authority over.

The transport document user node can also identify the role played by the user according to the dynamic access principle. User nodes can verify that their roles can create (update) transport documents against the access policy document. User nodes can identify data attributes with newly assigned values from the transport document and further verify that their roles can create (update) those data attributes.

In some embodiments, the authenticated shipping document may be encrypted and submitted to the shipping document control hub.

For example, a carrier may submit an encrypted role list and an encrypted common shipping document to the shipping document control center. The carrier (or other user) may first send a list of roles to be identified by tying the list of roles to one of the shipping documents, a reservation number or other document ID. Alternatively, the shipping document may be sent with (or after the character manifest) and the shipping document may be associated with the character manifest by means of a locator subkey. The list of roles can be read, and the list of roles can contain a list of one of the roles that the carrier will notify. The role list may also have a digital signature of the originator (sender), allowing the role list to be associated with the originator. Shipping documents may contain information indicating the terms of the proposed contract (quantity, delivery, scheduling, etc.). These terms may be individually encrypted as data attributes. A role list can have the name of a specific carrier associated with it.

The role list can be copied from the shipping document and added to an access policy unique to the shipping document. The access policy may contain information about each shipping party that may be involved in the shipping document. The role list of the access policy provides the identifiers of the members who can receive the information originally provided in the shipping document. Each transporter on the role list can obtain from the transport document appropriate information for its particular role (function).

The data attributes of the transport document can be encrypted one by one by separate symmetric keys. Symmetric keys can be encrypted one by one with a public key corresponding to each transporter that can have a role in the transport document. The roles of each transporter can be defined by a list of roles. The symmetric key for the data attribute can then be split to each user (transporter) that needs or requests the data attribute, and the symmetric key for each data attribute can be sent to the appropriate transporter using the party's public key key encryption. The encrypted data attributes, the encrypted data encryption key, the hash of the encrypted data attributes, and the digital signature of the document originator can then be sent to the transporter.

In some embodiments, the transport document client may send the encrypted common transport document, the encrypted data encryption key (DEK), the hash of the encrypted data attributes, and the digital signature role list of the document originator to the transport document control center. The transport document control hub can use the transport document's locator subkey to find the list of roles in the access policy. Based on the role list, the shipping document control hub can look up the list of recipients. In some embodiments, the shipping document control hub may have access to decrypt the role list to obtain the recipient list. In some embodiments, the user node may provide the public keys of the transporters in the role list and the transport document control hub may look up the list of recipients based on the public keys. In some embodiments, the user node may provide the plain text of the recipient manifest along with the shipping document to the shipping document control hub. The recipient list may be the parties (users) in the role list. The shipping document control hub can then distribute the encrypted shipping document data attributes, the encrypted data encryption key, the hash of the encrypted data attributes, and the digital signature of the document originator to write to the corresponding blockchain nodes according to the recipient list. The Transport Document Control Hub can check whether documents, keys, hashes and signatures were successfully written to the blockchain nodes. If the document, key, hash and signature are successfully written, the transport document control hub may publish an event to the initiator's message broker hub notifying the initiator that the transaction was successful. The shipping document control center may also publish events with encrypted shipping documents, encrypted data encryption keys, and the digital signature of the document originator to the recipient list.

An access policy contains information about each transporter (user) that can be involved in a particular transport document. The role list of the access policy provides the identifier of the user who will receive the information originally provided in the shipping document. Each user on the role list can obtain the appropriate information for his role (function) from the transport document.

The data attributes of the transport document can be encrypted one by one with the help of a runtime-generated symmetric key called a data encryption key (DEK). The DEKs can be encrypted one by one with a public key corresponding to each user who can have a role in the transport document and can have access to the corresponding attributes. The role of each user can be defined by the role list. The access rights of each role to each attribute can be defined by access principles. The encrypted data attributes, the encrypted DEK, the hash of the encrypted data attributes, and the digital signature of the document originator can then be sent to the appropriate members.

In some embodiments, a user may submit a status update to the shipping document control hub. The status update provides information, such as receiving and unloading the container with the shipping document ID 12345, and someone may have to pick it up. Dock Status Update for Shipping Document 12345 Could not find any character list. So in addition to sending status updates to the transport document control hub, updates can also be buffered in the user nodes. The other party may then send a manifest of roles to the user node, which manifest may have the same shipping document ID (12345). Consumer nodes can continue to process dock status updates. User nodes can obtain the following information from the Access Principles from the Transport Document Control Hub: -Dynamic access policy for terminal status update (dynamic access control policy can be derived from the role list of a given locator subkey and the access policy file for a given shipping status update type) - Access policy document for transport status update type The user node can identify the role played by the user according to the dynamic access principle. User nodes can verify that their roles are allowed to create a shipping update state against an access policy file. User nodes can also verify that their roles can create their data attributes that transport update status. This verified shipping status update can be encrypted and submitted to the shipping document control hub.

In some embodiments, the user node may receive various documents from the transport document control hub based on the user's access policy: the dynamic access policy of the dock state (the dynamic access control policy may be derived from the role of a given locator subkey) List and access policy file export for a given shipping status update type), and an access policy file for the shipping status update type. The transport document user node can also identify the role played by the user according to the dynamic access principle. Transport document user nodes can verify that their roles are allowed to create transport update status against the access policy document. Transport document user nodes can also verify that their roles can create their data attributes for transport update status. After verification, this verified shipping status update can be encrypted. The encrypted shipping status update, the encrypted data encryption key, the hash of the encrypted data, and the user's digital signature may be submitted to the shipping document control center along with a list of recipients.

An example of one of the operation methods will now be described.

In one example of a shipping operation of the present invention, the following parties are involved:

Shipper: Factory A

Consignee: S-Mart

Carrier: XYZ

Route: China to USA

Goods: Toys

Container No.: 5

In this example, the shipping line is XYZ, and the shipping line is organizing the delivery of 5 toy containers from Factory A (located in China) to a port in the USA. The carrier generates one of the shipping documents for shipping.

Table II header field data attribute shipper Factory A Receiver S-Mart last terminal operator Long Beach, CA … … ship operator SS freighter carrier XYZ

The carrier is the party that organizes the transportation of the toy from China to the USA. The carrier then provides the above shipping order to the user node in plain text through a secure transmission. The user node then encrypts the data attribute while leaving the header field alone. Each data attribute is encrypted and has a separate data encryption key.

Table III header field data attribute shipper Encrypt ("Factory A", k1 key)* Receiver Encryption ("S-Mart", k2 key)* last pier Encrypt ("Long Beach, CA", k3 key)* ship operator Encrypt ("SS Shipper", k4 key)* carrier Encrypt ("XYZ", k5 key)* *Information provided in encrypted fields does not represent actual encrypted information. Text strings are descriptive only. "Encrypt("FactoryA", k1Key)" means that the literal value "FactoryA" is encrypted by "k1Key"

The encrypted data can be recorded in the blockchain nodes, and each data encryption key (k1 to k5 in this example) can be encrypted according to the public key of the user matching the assigned role and access policy. In this example, Shipper Factory A may have access to all data attributes. Factory A's public key can then be used to encrypt all keys (k1, k2, k3, k4 and k5). All shipping documents can be encrypted individually. The keys can also be encrypted individually (either serially or in parallel). The keys can be encrypted in a batch format as long as the individuality of each key can be protected (each encrypted key can be decrypted independently and used for access if the key cannot decrypt any other transport document the specific shipping document to which the key corresponds).

The right of each transport role to read, create or update the data attributes of the transport document may depend on the access rights defined by the system. In this example case, there may be a lookup table that provides one of the rules established by the system, as follows:

Table IV transport role D1 D2 D3 D4 D5 shipper R R R R R Receiver R R last terminal operator R R ship operator R R carrier CRU CRU CRU CRU CRU

Table IV illustrates the access principles for different transport roles (eg, shipper, consignee, terminal of last resort, vessel operator, carrier, etc.). D1 to D5 are data attributes encrypted by (k1 to k5). R means "read", "U" means "update" and "C" means "create". If the consignee has access to D1 and D5 ("read", "update" or "create"), then k1 and k5 will be encrypted by the consignee's public key.

[PC1] Shipper Factory A's public key can be used to encrypt all keys (k1, k2, k3, k4, and k5). The public key used by the terminal operator (Long Beach Terminal at the Port of USA) can be used to encrypt k2 and k3. The public key for the ship operator (the SS freighter of the transport) can be used to encrypt k2 and k4, and finally, the public key for carrier XYZ can be used to encrypt all keys (k1, k2, k3, k4) and k5) encryption. The ship operator does not need to know anything about the shipper. Information about the shipper may not be visible to the ship operator and the set of data attributes available to the ship operator may not contain keys for the shipper's data attributes.

Once encryption of the key is completed and/or stored, individual users can be notified that data is available. Each user using his own private key can decrypt his individual key and access the system to view the data in the decentralized ledger, while other users' information remains securely encrypted.

In a more general form, the procedure for generating the proper keys for accessing various data attributes with different owners may involve generating keys and making them associated with a user's assigned role and access. A procedure 1500 for principle matching, as shown in FIG. 15 . After start block 1502, the program may generate a data encryption key 1504 for each data attribute. In some embodiments, the keys may be symmetric keys. An encryption key can be formed for each material attribute. The system can retrieve the transport role 1506 for each transporter. As set forth herein, each party may have a transport role in the booking. The role can be any defined role in the system. Additional roles can be added to the system to accommodate additional parties whenever needed (each user may be a party to a single shipping transaction, but a user need not be a party to a single shipping transaction). In some embodiments, a single user may have one transport role. In some embodiments, a single user may have two or more transport roles. In some embodiments, a user can access the system without having an official transport role, as described herein. The program can retrieve the access control policy 1508 for each transport role. Access control principles provide information to inform programs what data attributes each transporter can access. The program may then provide the public key and access control principles 1510 for the transporter. Here, each transporter that can access the control principle may also have a public key stored in a public key repository. The program associates the role of the transporter with access control principles to see which data attributes the transporter has access to. The program can then retrieve the appropriate public key of the transporter. The program may then encrypt 1512 the corresponding data encryption key with the transporter's public key. Encryption of data encryption keys can be performed serially one after the other. In some embodiments, the encryption of the data encryption key may be performed in parallel. In yet other embodiments, the encryption of the data encryption key may be performed in one batch. Each data encryption key may be encrypted such that each key encryption key corresponds to one or more data encryption keys, and each one-to-many relationship between key encryption keys and encrypted data keys corresponds to a A single data attribute. It can be viewed as a one-to-many or one-to-one relationship (1:m and 1:1). Once the procedure is complete, the procedure may end 1514.

In some embodiments, a party may be added to a role list or access policy, but that party may not have an actual role in the transport. In some embodiments, a non-transport role party may be a financial institution. In some embodiments, the non-transport role party may be a regulatory or government agency. In certain embodiments, the non-transport role party may be an insurance company, a guarantor, a judicial authority, a trade regulator, a labor organization, or a document, access policy that may be directed to the system described herein or any other entity that accesses or checks data in at least one data field of another repository.

Figure 16 provides another example of a procedure for encrypting data attributes based on role and access control principles. In this example 1600, five roles are presented in the form of a shipper, consignee, terminal of last resort, ship operator and a carrier. In some embodiments, there may be one party per role. In some embodiments, there may be a party with more than one role. In yet other embodiments, two or more parties may share a single role. For the example depicted in Figure 16, there are five roles and one party per role.

In some embodiments, a data and key structure 1602 may contain five data attributes (D1-D5) as shown. Each data attribute may be individually encrypted 1606 (k1-k5) with a data encryption key. Each data attribute may also have a header and data attribute fields. As shown in sample access control principle 1604, each role (shipper, consignee, etc.) has access controls defined for the headers and a header (top row) corresponding to each data attribute (H1 → D1, H2 → D2, H3 → D3, H4 → D4 and H5 → D5). The intersection between the column (role) and the row (header) provides the access policy for the role (the party that matches the row to the left of the column). For example, the shipper has "R" access under the access control principle. The shipper can "read" the data attributes corresponding to D1 to D5. However, the shipper may not update or modify the data, nor may the shipper create any data. On the other hand, according to the sample access control principle of Figure 16, the carrier may have create (C), read (R) and update (U) authority. Other parties, such as the consignee, may only read the data for H1 and H5 corresponding to D1 and D5. Finally the terminal can only read the data for H2 and H3 corresponding to D2 and D3. The ship operator can only read the data for H2 and H4 corresponding to D2 and D4.

The data encryption key can then be encrypted by the public key for each party with a role match in the access control policy. In this example, the shipper has a public key (S _pub ) that can be used to encrypt each data encryption key k1-k5 individually, as shown in the Public Key Encryption of Data Encryption Keys 1608 table. The shipper column in the 1604 table means that the shipper will have access to read data attributes D1 through D5, but will not be able to create, delete or update those fields. The consignee has a public key used to encrypt the data encryption key (DEK) corresponding to H1 and H5 (which are the two data attributes that the consignee accesses according to the consignee's access control principles 1604) ( _Copub ). The recipient's public key is used to encrypt k1 and k5. The encrypted k1 and k5 may be referred to as a DEK, and the consignee may have DEKs for D1 and D5, which we abbreviate as k1 and k5. The consignee can receive k1 and k5 through its user node in the system. The consignee can then use k1 and k5 to access the data attributes corresponding to D1 and D5. The procedure may be the same for the terminal of last resort, the vessel operator and the carrier. Each party with a role can access its appropriate DEK through its user node in the system, and can then access the data attributes corresponding to the DEK.

17 illustrates an embodiment 1700 that includes a shipping document with a unique ID 1706 and a role list 1710. Access policy 1702 may be role-based. It can have two levels. A level may be a file object level for each role of transport file 1706 to create, update, tombstone, and read. It may also provide an attribute hierarchy that allows creation, updating and reading attributes of the transport document 1706. The role list access policy 1704 may be role based. It can also have two levels. A level may be used for each role of a role list 1710 to create, update, tombstone, read a role list object level. It may also have a role attribute hierarchy that allows creation, updating and reading of the role list 1710. In some embodiments, a shipping document 1706 may be assigned a list of roles. Role list 1710 plus shipping document access policy 1702 may provide privileges on shipping documents for each user who is a party. In some embodiments, each shipping document may have its own role list and its own access policy. Each user can have a defined role on a rolling list and access defined in an access policy. The intersection between each user's role and each user's access may define that user's privileges. A list of roles can be applied to many different shipping documents. For example, a shipping role list may apply to a DG document, a bill of lading, terminal loading or unloading events, or any other form of shipping document 1706. These various forms of shipping documents may also be referred to as document type 1714 and event type 1716. Document type 1714 and event type 1716 may define a group of supported types of shipping documents 1706. In some embodiments, shipping documents 1706 of document type 1714 are versioned. In some embodiments, the version number of a file may be incremented each time a file is edited or modified. It can be used to support multiple versions of the same original shipping document. Each shipping document 1706 may have a unique ID. There may also be many kinds of character lists 1710. Transport role list 1718, container role list 1720 are some of the possible types of role list 1710. Transport document 1706 and role manifest 1710 may use locator subkey 1708 and locator subkey 1712, respectively. In some embodiments, location subkey 1708, location subkey 1712 may not be encrypted. The locator subkey 1708, locator subkey 1712 are visible to the Transport Document Control Hub and can be used to support its (hub) functions. Locating the subkey may allow a key-based lookup (eg, shipping number) to identify the associated role list 1710 and associated shipping document 1706. The transport document 1706 can identify the access policy 1702 by its type.

18 illustrates some example role lists and role list principles. In some embodiments, a role list access policy locator subkey 1802 may provide example headers for "Character List Type" and "Location Subkey Field". Under "Role List Type" is "Transportation Role List" and under the Locator subkey field is the carrier and booking number. This illustration illustrates that the Locator subkey fields of the Shipping Role List are Carrier and Booking Number. A role list access policy instance 1804 may display a category of role list types in which a transport role list is provided. The roles are shown as: shipper, consignee, carrier, ship operator and terminal operator. In this example table, the shipping role list indicates that the carrier has the authority and system privilege to create a role list. In this instance, none of the other roles can create a role list. The next table shows a role attribute hierarchy instance 1806. Here, the "Character List Type" is displayed in the "Transport Role List" in the first row and the "Character Attributes" in the second row. The individual roles from the role list access policy instance 1804 are now listed in the role attribute row. The remainder of the table shows the "role" to "role attribute" access privileges used to create, read, or update (modify) a role attribute of a role manifest transport document. The bold lines show the second and third lines and indicate that the shipper can read all roles in the list of shipping roles, however the shipper cannot create or update any role attributes in the list of shipping roles. The role manifest instance has a role manifest locator subkey 1808 and a role manifest content 1810. The role list locator subkey 1808 illustrates a carrier XYZ and a reservation number 123456. The transport role list may include role list content 1810, which may illustrate the identifiers of each user in their role (for illustration purposes only, these identifiers are virtual).

Several example shipping documents 1900 are now shown that may illustrate business-related headers, but use dummy material for illustration purposes only, as shown in FIG. 19 . In some embodiments, there may be a shipping document (from a terminal operator) of a container outbound event 1902. The example table shows the event ID (the unique identifier for the shipping document), the carrier and reservation number (the carrier and reservation number may allow the location of the list of roles), and information about the intermodal container at the terminal. This information can be sent to the shipping document control hub and redistributed to other users identified on the role list, so each user can be notified simultaneously of this particular outbound event. A transport document access policy may have 3 parts - a "role list locator" key 1904, a "transport document access policy" 1906, and an "outbound event field level transport document access policy" 1910. The Role List Locator subkey 1904 (an instance of Figure 17, 1708) indicates that for an outbound event, the Transport Role List is applicable and the Carrier and Booking Number can be used to locate the Role List, and the Carrier and Booking Number can be used as Carrier XYZ and subscription number 12345 is retrieved from outbound instance 1902. Shipping Document Hierarchy Principle Instance 1906 indicates that for an outbound event, the five roles presented can read this transport document type "outbound event" transport document, but only the terminal operator (the originator of this event) role can create or update Shipping documents. In some embodiments, a role such as a terminal operator may also perform a logical deletion of shipping documents.

In some embodiments, the transport document schema instance 1908 may illustrate a field name ("Header Field") in the left row and the data attribute type in the right row. The sample data attributes can be of any length, and the string lengths shown are illustrative only. As illustrated in this instance 1908, the event ID is the unique ID for this shipping document type; and the carrier and booking number fields are the role manifest locator subkeys for this shipping document type. The shipping document principle field level instance 1910 provides an illustration of the shipping document type (in this example an outbound event) and a field row showing the various header fields from the schema instance 1908 and the outbound event instance 1902 . The list of fields in rows 3-7 (third-seventh) of the field level instance 1910 shows which role has what rights for each field. Data can be read by all roles of a single transaction, and updated (modified) by carriers and terminal operators. Only the terminal operator can create this type of transport document because the transport document outbound event originates from one of the terminal operator's assets.

In certain embodiments, the systems and methods described herein may be used with dangerous goods (DG), as seen in FIG. 20 . Dangerous goods may require a special shipping certificate, referred to herein as a Dangerous Goods Certificate (DG Cert). Dangerous goods in transported goods occur when the material being transported may be hazardous or in quantities that would be dangerous to those involved in the transport procedure. Examples of dangerous goods may include fuels, radioactive materials, corrosive chemicals and liquids, explosives, and the like. In some embodiments 2000 of an example, a shipping document of a DG cert instance 2002 form is shown. The header field represents the left row and provides the category of information. The data properties in the right row show the corresponding data for each category. The Role List Locator sub-information can represent the carrier and reservation number. Product descriptions can also be listed. The role list locator information can be used to access the DG cert role list instance, which can be composed of the transport document access policy role list locator subkey 2004, file level access policy 2006 and field level access policy 2008 . The Role List Locator Subkey 2004 indicates that for each outbound event, there may be a Shipping Role List, with a "Character List Type" and a carrier and booking number used as the "Location Subkey Fields". Document Level Access Principles 2006 illustrates a table showing access principles for the transport document type "DG Cert" at the document level. Exemplary parties associated with the transport of dangerous goods and their respective read (R), create (C), update (U) and delete (D) authorities are shown. The DG cert schema instance 2010 provides the header and data attribute types of the DG certificate (transport document) for the current instance. "Example of DG Cert's Transport Document Access Principle - Field Hierarchy (A field can refer to a data entry field in a document)" 2008 provides information on the type of transport document (DG Cert), from DG cert example 2002 and DG Fields obtained in the cert schema instance 2010 and showing the individual rights of each party (user).

In one example, an illustration of a logical system layout 2100 can be seen in FIG. 21 . In some embodiments, there may be a system for generating a shipping document. The system may have a transport document control center 2102 and a first user node 2104 . The transport document control center may have a computer including a logic, a memory and a communication device. A document control center-side message agent 2106 can operate through computer logic. The message broker 2106 can send and receive one or more event messages 2108, 2110. There may be an access policy repository 2112 that may be stored on memory. There may also be a public key repository 2114 and an ID repository 2116 on the memory. Memory can be one or more physical devices and it need not be physically contained within a computer. Physical memory may be distributed in a physical sense as long as the computer has access to the various databases described. The ID repository 2116 may have a list of one or more users, one or more user login credentials, and one or more user parameters. The memory may be a blockchain node for one or more of the access principles used to store encrypted transport documents. The first user node 2104 may have a computer having a logic, a memory and a communication device. Similar to a transport document control hub, client (user) nodes 2104, 2118 may have computer memory and may be more than one memory device that may be internal or external to the computer, as long as the computer can access the memory(s) device. A key storage area 2120, 2122 may be part of the user node, the key storage area may hold a login ID secret and a private key of the user. The key storage area may be accessible by a computer. The user nodes 2104, 2118 may also have an API interface with a cryptographic access layer for electronic communication with the key store and a user message agent 2124, 2126. The user node may have a portal for a user to access the transport document control hub, wherein the API interface may be implemented logically and communicate with the transport document control hub message broker.

In some embodiments, the communication between the user node and the transport document control hub may be handled by the message broker. The system may use a secure network communication between each node and a transport document control hub (hub). These message brokers can provide secure network communications for nodes and hubs to pass information to each other. The application programming interface (API) of the user node may be a computer-implemented program that provides an access layer for the cryptographic exchange between the key store and the message broker. The access layer can be implemented on a computer logic or processor. A client application may be any interface for a user to access the API interface and the message broker. The client application may be proprietary software or may be off-the-shelf software. Each node's message broker has access to the blockchain logic in the hub, and encrypted transport files can be stored in a blockchain format with one or more encrypted fields assigned to each node. Each memory element can have any number of blockchain databases, since there can be one blockchain database for each shipping document type.

In some embodiments, a sample flowchart 2200 of a role manifest submission can be seen in FIG. 22 . In some embodiments, when a role manifest is submitted, the role manifest may have an initial check attribute validation 2202. In this step, the program checks to see if the locator subkey (such as the subscription number and the sender's organization ID (SCAC code)) and the role list (the role list also contains the role list type) are available in the request. If so, the program can perform a role check 2206 to see if the sender's organization ID can be one of the parties in the role list. If so, the program checks to see if a role list access policy 2208 is defined. This step involves checking the role list access policy for that role list type. The program can then check an access check 2210 to look up the sender's organization's role from the ID repository and check if the sender's role has access (role list level and a data field in a role list, with (referred to herein as a "role list field level") to create a role list and create roles within the role list. If at any point the process fails to produce a useful result, the process may end and an error response code 2212 may be returned and then terminated (end 2234). If all steps are successful, the program can generate encryption keys 2214 for all roles in the role list. Using these encryption keys, the program can encrypt 2216 the list of roles. The program can generate the sender's signature 2218 by generating a hash from the encrypted role list and accessing the key store to sign the hash with the sender's private key. The program can obtain a public key 2220 for each party on the role list and encrypt 2222 the data encryption key using the party's public key according to each party's access control principles. The program can package the message by using the encrypted role list, the encrypted data encryption key (associated with the party's public key), the hash, and the sender's signature. The program can digitally sign messages with the user's private key to generate the user's signature. The message can be sent to the shipping document control hub 2223. The program may then distribute the data and encryption keys 2224 by finding the blockchain nodes of the parties and distributing the list of encrypted roles and encrypted data encryption keys to the respective blockchain nodes. The program can then check for distribution success 2226 by checking if the encrypted data was distributed successfully, the encrypted data encryption key, the hash, and the sender's signature. The program can then publish events with a success code 2232 to the message broker, or events with an error code to the message broker 2228.

In some embodiments, the client application may create a role list and communicate with the transport document control hub via the client-side message broker and user nodes. The cryptographic access layer in the user node can obtain the public key and access control principles from the hub. The access layer can then validate and enforce access control principles, encrypt a payload (role list) and place the message to the message broker. The Message Broker (on the client side) can communicate with the Message Broker of the Transport Document Control Hub, and the Message Broker on the Transport Document Control Hub side obtains the message to the program to distribute the encrypted data and the encrypted data key, and An event 2232 can then be published with a success code that can go to a client-side message broker. The client side can respond with a success message and acknowledge receipt, and can create a transaction completion response.

In some embodiments, there may be a procedure 2300 for reading a shipping document, as shown in FIG. 23 . The program may start with a given document ID (eg DG Cert ID) (in some embodiments, a version number), shipping number, sender's organization ID (eg SCAC (Standard Carrier Alphabet) code)) and a specific role list type. It proceeds to check attribute validation 2302. In this step, the program can check whether the locator subkey (shipping number, sender's organization ID), document ID, and role list type are valid. If so, the process obtains the encrypted role list and encrypted data encryption key 2304 from the sender's node using the role list's locator key and role list type (not shown). If the character list cannot be found, the process may return an error response code 2316 and may then proceed to end block 2322. If a list of roles can be found, the program can check the list of roles for dependencies 2310. The program can check to see if the role manifest data in all blockchain nodes match each other. If the role manifest data in any blockchain node does not match other blockchain nodes, the process may return an error response code 2316 and may then proceed to end block 2322. If the role list data is the same in all blockchain nodes, the program can access the key store 2312 to decrypt 2314 the data encryption key. If the data encryption key cannot be decrypted, the process may return an error response code 2316 and may then proceed to end block 2322. If the data encryption key can be decrypted, the program can use the data encryption key to decrypt 2318 the role list. The program may then return a success response code 2320, or alternatively, if the program fails, the program may return an error response code 2316. The process may then proceed to end block 2322.

A flowchart showing a shipping document creation 2400 is now shown in Figure 24. In some embodiments, the program can check for attribute verification 2402 by checking the locator subkey (eg, subscription number and sender's organization ID) and the content of the shipping document (eg, DG cert) and the shipping document type can be found in the request 2402 . The program can check to see if there can be an existing role list 2404 from one of the access policy repositories. This step may involve checking the access policy repository for applicable role list types, and then checking an existing role list for one of that role list type. A transport role check 2406 (or just a role check) can determine whether the sender's organization ID is one of the parties on the role list. The program can check to see if the access policy 2408 can be defined at the transport document level and at the transport document field level. The program can perform an access check 2410 to find the sender's organization's role in the ID repository, and can check that the sender's role has the correct access (transport document level and field level) to create that type of A shipping document (eg DG cert) and create data in it. The program can then generate a unique shipping document ID 2412 (eg, a DG cert ID) that can be unique throughout the system. The program can generate data encryption keys 2414 for all data attributes in the shipping document. The data attributes can then be encrypted 2416 in a transport document (eg, DG cert) using the data encryption key. The program may generate a hash for the encrypted data attribute and access the key store to generate the sender's signature 2418 by signing the hash with the sender's private key. The public key 2420 can then be obtained for each party identified in the role in the transport document. The data encryption key can be encrypted 2422 using the appropriate public key for each party identified in one of the roles in the transport document. The program may package 2424 the message with the encrypted data attributes, the encrypted data encryption key, the hash, and the sender's signature. The program may send 2426 a message to the shipping document control center. The Transport Document Control Hub may distribute encrypted data, keys, hashes, and sender's signatures by: locating the appropriate party's blockchain node; and The key (DEK), hash and sender's signature are distributed to the blockchain nodes. The program can check 2428 to see if the distribution was successful by causing each user node to respond with a success notification. Alternatively, the program may distribute the message and record the distribution as successful unless an error message is received from one or more recipients. A notification of a successful event may be posted to sender 2432. The role manifest recipient may receive a publish event 2430 with one of the encrypted shipping documents, encrypted DEK, hash, and sender's signature. The publication of events to either recipient may depend on whether the recipient agrees to update events for a particular shipping document type (eg "DG cert created"). The recipient user node may check integrity 2436 by computing the hash from the encrypted transport document; and by decrypting the sender's signature using the sender's public key to obtain the decrypted hash. The program can compare the decrypted hash with the hash from the encrypted shipping document. The recipient node can then access the key store to decrypt 2438 the encrypted data encryption key and decrypt 2440 the transport file with the data decryption key. The client application may receive the shipping document 2442 in plain text. The process may then proceed to end block 2448.

A flow diagram of a shipping document update 2500 is now shown in FIG. The process may continue from start block 2502 by verifying that the shipping document ID/locator subkey (eg, booking number and carrier's organization ID (SCAC code)) and updated shipping document (eg, DG Cert) are available in the request to check property 2504. The program may check 2506 for an existing shipping document. This can be determined from the blockchain ledger by searching for the shipping document ID and/or locating the subkey and shipping document type. A check can be made to see if an existing list of roles 2508 can be found. The program may find the role list from the access policy repository by searching by means of one or more locator subkeys and/or one or more role list types. A role check 2510 can be performed to determine whether the sender organization ID can be one of the parties on the role list. The program can check to see if an access policy 2512 is defined. The Program Accessibility Principle obtains shipping documents from a portion or the entire document by supplying a "Transport Document Type" (eg, Transport Document Type="DG Cert"). An access check 2514 may be performed to determine if the sender's role can have access (field level) to update data values in the shipping document. The program may merge the existing shipping document attributes with the encrypted data of the submitted data attributes (if available) 2516. The program can increment the version number of the shipping document by one 2518. The program may generate a data encryption key 2520 for the new data attribute 2522 in the submitted shipping document. For example, if there are 10 data fields and 3 data fields affect a user, only the three data fields affecting that user are changed, so only 3 data fields may require a new encryption key . The remaining 7 fields may not have a new key, and only the old information that already exists is left. The program may encrypt 2524 the attributes of the submitted data in the shipping document by using the data encryption key. The program can generate a hash for any newly encrypted data attributes (data fields) and access the key store to generate the sender's signature 2526 by signing the hash with the sender's private key. The program can obtain the public keys 2528 of the parties in the role list. The program may encrypt 2530 the updated data encryption key using each party's (user's) access control policy by using each party's public key. The program may package 2532 the message with the encrypted data attributes, the encrypted data encryption key, the hash, and the sender's signature. The program may send a message to the shipping document control hub 2532. The program may distribute encrypted data and keys by: locating the blockchain ledger of the parties; and distributing the encrypted transport document, encrypted data encryption key, hash, and sender's signature key to the appropriate blockchain ledger 2534. One of the checks 2536 for the successful distribution of the encrypted transport document, the encrypted data encryption key, the hash, and the sender's signature can be performed. A publish event 2550 with a success code to the sender may be performed in the event that a success code is sent to the sender's message broker. If saving to the transaction reference database is not done, the program may instead publish an event with an error code to be sent to the sender's message broker 2554. The program may publish an event to the intended recipient 2538 with an encrypted shipping document, encrypted data encryption key, and the sender's signature. The release event to the recipient depends on whether the organization agrees to a shipping document update event (eg "Updated DG Cert"). The event payload may contain an encrypted transport document, an encrypted DEK, and the sender's signature. The recipient user node may check integrity 2540 by computing the hash from the encrypted transport document; and by decrypting the sender's signature using the sender's public key to obtain the decrypted hash. The program can compare the decrypted hash with the hash from the encrypted shipping document. If the integrity check 2540 fails, the program may return an error response code to the recipient 2548. If the integrity check is successful, the recipient node can then access the key store to decrypt 2542 the data encryption key and decrypt 2544 the transport file with the data decryption key. The client application may receive the shipping document 2546 in plain text. The program may then proceed to end block 2556 .

An example procedure 2600 for reading a shipping document is now shown in FIG. 26 . The process begins at a start block 2602 and may continue to check if a shipping document version number can be supplied in the request, and to check the shipping document version number 2604 against a transaction reference database. The program may then perform an attribute verification 2606 to check if the shipping document ID and/or locator subkey (reservation number and sender's organization ID (SCAC code)) and shipping document type are in the request. The program can obtain the encrypted shipping document and encrypted data encryption key 2608 from the sender's blockchain node by the shipping document ID. (In some embodiments, there may be a correlation check (check correlation 2610) to see if the encrypted transport document and the encrypted data encryption key from the blockchain node are the same at the content level.)

The user node can access the key store 2612 to decrypt the data encryption key (DEK) and retrieve the data encryption key (DEK) 2614 using the sender's organization's private key. The user node can decrypt 2618 the encrypted transport file with the data encryption key and can send 2620 a success response code back to the client application. If the procedure fails at any point, the procedure can pass an error 2616 code back to the client application. The program can end 2622.

In some embodiments, in one or more of the steps when accessing the existing role list and/or the existing transport document, the data of the existing role list and/or the existing transport document may be checked by the user node or the transport document hub completeness. The integrity check procedure begins by calculating a hash from the encrypted shipping document (or role list) and comparing it to existing hashes in the existing shipping document (or role list). The sender's signature can be verified against its public key. If the existing hash matches the computed hash and successfully authenticates the sender's signature verification, it is a valid signature and maintains the integrity of the document.

Once a user has access to the subscription API, the user can populate a subscription configuration 2700 (instance). Subscription configuration 2700 may have a number of fields for data entry related to shipment of goods. Fields may include, but are not limited to, shipper, consignee, vessel operator, forwarder, carrier and booking party (which may be a user) identifiers. The reservation configuration 2700 may also have route information, container/goods information and other or miscellaneous information as desired. Users who create subscriptions can see all data properties in the subscription configuration. Additional information that a subscription user may enter into subscription configuration 2700 may include information that may be confidential to the user. When the subscription configuration 2700 is entered into the system, each field can be processed individually. For example, once a record is created, a shipper in booking configuration 2700 can view the record, but the shipper can only see information related to it (eg, the actual price of the shipping disposition). In another example, the consignee can see information related to it (eg, the location of the intermodal container returned). The subscription version number 2702 indicates the version the user is viewing. In general, users can see the latest version. In some cases, a user may search for records older than the most recent record.

A sample screenshot of a partial booking view 2800 as viewed by a vessel operator is now shown in Figure 28. The screenshot contains the carrier's identifier, but can hide the identifiers of the booker, shipper, forwarder and consignee. In addition, there may be information in the route information, part of the container/cargo information, or other information fields that remain hidden from the vessel operator's view. In this way, the user (subscription party) making the partial subscription view 2800 can populate all information related to each other party involved in the shipment of the goods. The shipping documents may contain information that each party relies on to use or conduct part of their transactions, but which conceals any information that the booking party does not want to share. The subscribing party can define what fields it wants others to see, who those other parties are, or the subscribing party can use a standardized set of protection fields. The system can determine which fields a user can see based on the access control principles of each user's role.

In some embodiments, a party in an access role policy who may not be a user of the system can still gain access to specific material in the system by having a right from a user in the access role policy and access to information. This non-user party may be a bank or other financial institution, a government entity (such as a port inspector) or other third party with an affiliated interest in the transportation transaction (such as an insurance company, customs agency, maintenance facility or any other party).

In some embodiments, a user may request a third party to access specific data within the system. Alternatively, the user may request to have specific information in the system that is authenticated to a third party non-user of the system. The user can submit a verification request to the system, and non-users can gain access to specific information in order to verify statements made by the user. Procedures can be done with or without direct action from the system, and allow confidentiality between users and third-party non-users.

An illustration of a logical relationship between the system, users and third party non-users can be seen in Figure 29. In some embodiments, a registered user 2902 and a user node 2908 can make requests to the file control center 2906 through the user node 2908 . In some embodiments, the user may communicate with a third party 2904, which may not have any access rights to the file control hub 2906 and is not a user of the system as described herein. For example, a message broker may be configured to send a message to a third party 2904 (a third party non-user), where the message includes encrypted data from the transport document control center. Encrypted data may be limited to data that a user 2902 (or a corresponding user node 2908) can access according to an access control policy and a list of user roles. The third party 2904 may be an organization or individual interested in the shipping activities of the user 2902, but not a party to the shipping agreement. The third party 2904 may be a bank or other lending institution, an insurance company, a broker, a maintenance facility, a government agency or government actor or any other party who may be interested in the transport agreement and needs access to documents Certain data or files on control hub 2906 or any of the controlled databases supported by the system as described herein.

Specifically, a user 2902 may communicate a document or information to a third party 2904 party for the purpose of obtaining something from the third party 2904. This from the third party 2904 may enable the user to participate in shipping agreements, or conduct business with other users of the system. Examples could be financing a shipping agreement, providing financial security for an aspect of the agreement, commodity or carrier insurance, inspection data to verify container contents upon arrival at a port, and so on.

To obtain assistance from the third party 2904, the user 2902 may submit to the third party 2904 all documents that the third party 2904 may request using an encrypted and secure user-to-third party communication 2912 agreement. User to third party communication 2912 may include encrypted data and data encryption keys delivered from user 2902 to third party 2904 so third party 2904 can view the data properly. In some embodiments, the third party 2904 may wish to verify the authenticity of the information provided by the user 2902. The third party 2904 can access a third party node 2910 to communicate with the document control hub 2906 and request verification of data received from the user 2902. The third party node 2910 may communicate with one of the authentication functions in the file control hub 2906. In some embodiments, the third party 2904 may send the encrypted data to the file control hub 2906 via the third party node 2910 and request verification of the encrypted data. In some embodiments, the third party 2904 may send the encrypted data and the encrypted data encryption key for decryption. The third party 2904 may send any additional material provided by the user 2902 for verification by the document control hub 2906. The file control hub 2906 can send the information required for verification back to the third party 2904 via the third party node 2910.

In some embodiments, the third party 2904 can send the encrypted data to the third party node 2910, the third party node 2910 can generate a hash of the encrypted data and can provide the hash of the encrypted data and compare it to the one recorded in the file Hash of shipping documents in control center 2906. Matching the hash may reveal that the data is authentic, although the document control hub 2906 may not actually release any data to the third party 2904. In some embodiments, authentication using key checking and hashing of encrypted keys or any other mechanism that exists now or is derived in the future may be permitted, which may be suitable for use by the file control hub 2906 and user 2902 systems. When the third party 2904 can confirm the authenticity of the data from the user, the third party 2904 can proceed with its internal operations to provide the user 2902 with whatever the user needs to continue his responsibilities in the shipping agreement.

In some embodiments, the relationship between the document control hub 3002 (DCH), users 3022, and third parties 3060 on the system side 3012 may be illustrated, as shown in FIG. 30 . DCH 3002 may have a shipping document database _3004a , and may have other databases, such as an access policy repository _3004b , a public key repository _3004c , an ID repository _3004d , or for the operation of the system of any other database _3004n . When user 3022 may need a bank loan, user 3022 may request specific information and documents from DCH 3002. The user's request may be authenticated against the ID repository and access policy repository or any other authentication method or requirement. The user can be identified in system 3012 or DCH 3002. The user may have one or more recipient repository encryptions 3006 _an for "data encryption keys" resident on the system side. Once the user request is authenticated, the DCH can extract the requested data from one or more databases and provide the information to the user 3022. The information can be bundled into a system-generated data package 3006 by means of the encrypted data encryption key, and then sent to the user 3022.

Data package 3006 may contain encrypted data and is sent with encrypted data encryption key 3026. The user may receive the data package 3006 from the DCH 3002 or the system 3012 via a secure communication link 3020. When the data is packaged in the user's control zone, the user-controlled data package 3024 can be modified, opened, or left alone. In some embodiments, the data package 3024 may contain more or less material. In some embodiments, the data encryption key 3026 may be encrypted using the user's public key. The data package 3024 and the data encryption key 3026 can be communicated to the user 3022.

On the user 3022 side, the encrypted data encryption key 3026 can be decrypted using the user private key 3028. The user can send the data package 3024 and the decrypted data encryption key 3026 to the third party 3060. The user can send the data package 3024 to the third party 3060 via a separate secure communication link 3064. Due to the encrypted nature of the data, in some embodiments, the user, DCH/system or third party may choose to use insecure communications.

Once the third party 3060 has the encrypted data in its control, the third party controlled data package 3062 and the decrypted data encryption key 3026 from the user 3022, the third party 3060 can access through the third party node (not shown) DCH 3002. The DCH 3002 can then use the DCH hosted verification function 3010 to verify the authenticity of the third party request using the encrypted data in the third party data package 3062. The third party 3060 can then receive confirmation that the information provided by the user 3022 can be authentic because the hash and other data encryption elements match the hash and other data encryption elements of the system 3012 and/or DCH 3002.

In some embodiments, a user may provide any amount of information to a third party as if it were also accessing it. In general, a user may only provide that information that may be relevant to third-party requests for information. For example, a third-party bank may request financial information, records of completed shipping agreements, and payments from parties downstream of the user. A history of an insured third party's request for transportation of a particular type of material, such as a hazmat, as well as a user's history as to how requests may be related to the number of accidents, the number of previous insurance claims, and so on. For example, a government agency may act as a third party and request information about the ultimate destination of a shipment, who an ultimate buyer may be, or whether the goods will or have passed through the territory of a particular country. Request types can be unlimited. The user can then issue a data request to the system. The system may generate data into data package 3006. Data package 3006 may contain encrypted data, a hash, a timestamp, and a signature of the sender. Depending on the sender (user) request, the data package 3006 may contain additional material or less material.

In some embodiments, the data package 3006 can be encrypted and sent to a user. In some embodiments, the user-owned data package 3024 may be identical in all respects to the data package 3006 assembled by the system. However, since the user is now in control of the data package 3024, the data package 3024 is distinguished from the data package generated by the system 3006. User 3022 can open data package 3024 and share it with a third party 3060. The user can share the data package in its entirety (without opening it) or can open it and re-encrypt it and send it to a third party. For example, the user 3022 can obtain the data package via a first user end node, and can send or distribute the data package to a third party (a third party non-user). When the third party receives the data package, the data package 3062 is now under the control of the third party. It can still be exactly the same as the data package 3006 originally sent by the system, or exactly the same as the user's data package 3024. A third party may attempt to verify the contents of the data package 3062. Third parties may use (or communicate via) a third party node to use or access the verification function 3010 in the DCH. For example, a third party can communicate with a verification function 3010 (also referred to as a verification function) in the DCH to verify an integrity of the data package. In some embodiments, a third-party node may invoke the verification function 3010 in the DCH, which may obtain encrypted data from the transport document database 3004a or any other database as needed. The verification function 3010 can then send the encrypted data to the third party node, so the third party can compare the encrypted data from the verification function 3010 with the encrypted data in the data package 3062 provided by the user 3022. In some embodiments, the third party may send the hash of the data package 3062 to the verification function 3010 hosted by the DCH, and if the hash used for the data package 3062 is the same as the hash used for the data package 3006, the third party may have the provided hash Proof that the information is correct and has not been changed from its source.

Example embodiments of third party functionality are now provided in FIGS. 31-35. In some embodiments, a first-hand shipper may obtain or require financial support from a bank (a non-party to a shipping transaction). In order for the bank to lend money to the forwarder, the bank will perform its normal due diligence to determine whether the forwarder is an acceptable risk and may repay any money loaned to it. For this example, the forwarder may submit a loan application 3102 to a bank or other lending institution, as shown in FIG. 31 . The bank experiences its own banking activity 3120 and the forwarder experiences its own forwarder activity 3118. In the process of applying for a loan, the forwarder will provide various documents and information to the bank. This can be considered an application verification 3104 step. The bank then goes through its own compliance checks 3106 to determine if the forwarder is a trusted party, and a good financial risk. If so, the bank may approve and issue the loan 3110 to the forwarder and provide payment 3108.

The forwarder may experience its activities and execute the shipping event 3112 that it was hired to do, provide shipping documents 3114 to interested parties, and then invoice 3116 the parties contracting for the shipping event. Then, the shipping event is completed, the contracting parties can pay the forwarder, and the forwarder can repay the loan.

In a procedure in which a forwarder wants to set up a loan account from a bank, the forwarder may be involved in a system that assists in providing data and documented verification using a trusted storage system. For example, the forwarder 3202 may use a secure communication 3204 system to communicate with a bank 3206 or other financial institution to set up an account 3200, as shown in FIG. The forwarder 3202 can send a loan account application and other supporting documents to the bank via secure communication 3204. These documents may contain historical information regarding past shipping transactions, security records, payment history, and more. Documents can be sent between forwarder 3202 and bank 3206 using secure communication 3204. Secure communication can mean encrypting messages and attachments. Secure communications 3204 may also involve secure systems, such as VPNs, encoded communication channels, and the like.

In this example, the bank 3206 can respond to the forwarder 3202 via the same secure communication 3204. In some embodiments, communications may be encrypted. Secure communication 3204 may contain history files and a loan application (load account application). Documents and account applications can be encrypted as indicated by a lock and key. In some embodiments, the encryption mechanism may be different between the forwarder and the DCH. Other parties, such as a carrier 3208 and a terminal 3212, may also use the same system 3210. In certain embodiments, carriers and terminals may be the source of shipping documents and shipping events. Since a forwarder may be involved in the shipment, the forwarder can obtain the documents and events and provide these documents and events to the bank for use in the loan account application.

Other users of system 3210 may be involved to provide additional documentation. For example, a carrier 3208 can verify that the forwarder 3202 is actually going to participate in a shipping transaction. The carrier 3208 can provide such details as to how much goods will be carried and to what destination. Forwarder 3202 can use this information to support how much money it needs to initiate its loan application.

The bank 3206 may request verification of the document and send an inquiry to the system 3210. The query can be encrypted and contain a hash. The hash can be identified and compared to the original data used to generate the hash. Then, if anything matches, the system 3210 can verify the data sent by the bank 3206.

In some embodiments, after the forwarder has set up a loan account, the forwarder may submit the financing application to the bank to borrow money, and the bank will perform its normal due diligence to determine whether the application is an acceptable risk, and possible repayment of any money lent to it. For this example, the forwarder may submit a loan application 3304 to a bank or other lending institution, as shown in FIG. 33 . The forwarder can collect the booking confirmation document from the carrier and the shipping event from the terminal as supporting documents for the loan application 3304. Completion of a shipping event, fulfillment of Project 3300, or fulfillment of a loan condition may generate an event that triggers repayment of the loan. For example, the arrival of a transport or carrier vehicle at a terminal 3312 and subsequent unloading of transported merchandise may trigger the sending of various documents 3314. The shipping event can be reported to the system 3310, which can then notify all relevant parties. The carrier 3308 may be notified that the vessel has arrived and has been unloaded. The forwarder 3302 may be notified that the goods have arrived at the destination port and that the event has triggered the payment of the loan to the bank within a fixed period of time. The bank may also receive verification that the Yunren 3302 loan is now due when the shipment has been completed. The system 3310 can have various triggers and alerts built into it, so at each stage of a shipment it can receive updates about shipping procedures and send alerts to all its relevant parties.

A sample invoice 3400 is now shown in FIG.

An example payment 3500 is now shown in FIG. 35 . In this example, the forwarder may select one or more financing options from the many lending institutions that the forwarder may have. Transactions may be handled by the system as long as the various parties are able to receive data from and transmit data to the system.

In certain embodiments, when a container is loaded on a terminal, a terminal operator may issue a terminal event notification that informs the carrier to track shipping milestones. Terminal event notification includes terminal location, event type, date, time, carrier and container number, etc. The carrier then finds the relevant parties for this container and notifies the parties through the encrypted decentralized ledger.

The use of separate encryption for each data attribute of a shipping document combined with a one-to-one relationship between encryption fields and encryption keys allows the creation of any number of operations participating in a common enterprise (such as intermodal container or item shipments) A single shipping document that lays out all aspects of an order of goods without revealing any confidential information to any other party involved in the order or to the public at large.

In certain embodiments, when a container is loaded on a terminal, a terminal operator may issue a terminal event notification that informs the carrier to track shipping milestones. The terminal event notification includes terminal location, event type, date, time, carrier and container number, etc. The carrier then finds the relevant parties for this container and notifies the parties through the encrypted decentralized ledger.

In some embodiments, a carrier may issue an invoice to a shipper and/or a consignee when a shipment is loaded. The shipper and/or consignee can then pay for the invoice. The carrier then issues an original bill of lading to the shipper. The consignee can pay the shipper for the goods. The shipper can then pass the original bill of lading to the consignee to obtain the goods. The carrier can verify that the consignee paid for the invoice (if any), the carrier verifies the original bill of lading from the consignee and other procedures for the release of goods. The carrier may use the encrypted distributed ledger to notify the shipper or consignee of the invoice and update the invoice after the shipper or consignee has paid.

Non-limiting aspects are now provided:

1. A method of protecting data privacy of a transport document shared among a distributed group of users, the method comprising:

receiving the shipping document via a communications network from a user, the user having an assigned role, wherein the high shipping document includes a plurality of data attributes;

encrypting the plurality of data attributes into a similar number of encrypted data attributes via a first encryption logic that generates a data encryption key corresponding to each encrypted data attribute;

organizing, via a programmed logic, the plurality of encrypted data attributes into a distributed data ledger containing at least one encrypted transport document from a user;

encrypting the encryption keys corresponding to the plurality of data attributes via a second encryption logic using one or more users for the distributed data ledger based on the user's assigned role A look-up table that provides permissions;

and

distributing the distributed data ledger to the distributed group of users via the communication network;

wherein each user accesses a node that provides access to the distributed data ledger; and

Each of these users can decrypt only the data related to their assigned role.

2. The method of aspect 1, wherein an access principle is used to determine the plurality of blockchain nodes for writing the encrypted data.

3. The method of aspect 2, wherein the user-assigned role is associated with a membership access control policy.

4. The method of aspect 1, wherein the assigned role further includes a relationship between transporters.

5. The method of aspect 1, wherein the distributed data ledger contains a plurality of encrypted shipping documents from one or more users.

6. The method of aspect 1, wherein the shipping document supplied by a user includes the user's assigned role.

7. The method of aspect 1, wherein the first or second encryption logic utilizes an asymmetric cryptographic algorithm.

8. The method of aspect 1, wherein the communication network further comprises a secure Internet access.

9. A communications system for providing real-time updates to parties in a transportation transaction on the progress of the transaction, the system comprising:

a portal for accessing the system via a secure Internet access;

a database, which stores system configuration information, public keys and reference information for transportation transactions (reservations);

a distributed ledger having a node for a user, the distributed ledger containing data related to the user in relation to the transportation transaction; and

a program that coordinates field-level encryption procedures and distributes encrypted results to the decentralized ledger;

wherein the user is a party to the transport transaction; and

Wherein the portal, the database and the distributed ledger are accessible through a cloud computing environment.

10. The communication system of aspect 9, wherein the portal is a client application.

11. The communication system of aspect 9, wherein the distributed ledger is a hyperledger.

Referring now to FIG. 36, shown is a flowchart of a method 3600 of securely sharing data from multiple sources with different client terminals. Method 3600 may be implemented or performed using any of the components set forth herein in conjunction with FIGS. 1-35 or 37 . In a brief overview, method 3600 can include establishing an electronic file of a transaction (3605). Method 3600 can include identifying an encryption key (3610). Method 3600 can include distributing encryption keys (3615). Method 3600 can include providing access (3620).

In further detail, method 3600 can include establishing an electronic file of the transaction (3605). A server (eg, a shipping document control hub) may identify, create or create the electronic document (sometimes referred to herein as a shipping document). The electronic document may define, contain or contain information for a single transaction through multiple client terminals (or entities). The single transaction may involve a physical item (eg, delivery from one point to another), and may contain a series of sub-transactions related to the physical item. Each sub-transaction of the physical commodity may be handled by at least one service provider (eg, agent, intermediary). The service provider is operable or associated with at least one of the client terminals involved in the transaction. One of the service providers may be the service provider that initiated the creation of the electronic document, with the remaining service providers accessing and/or facilitating the electronic document after the creation (eg, updating the electronic document, or adding information to to the electronic file).

The electronic document may contain a set of data fields. Each data field of the electronic file may relate to or map to one of the sub-transactions of a single transaction involving the physical commodity, or map to one of the sub-transactions of a single transaction involving the physical commodity. In the electronic document, each data field can be assigned an attribute or a value. The attribute of at least one of the data fields may be associated with one of the client terminals (eg, user nodes of the system 1300) involved in a single transaction (eg, by the client terminals). provided/facilitated and/or updated by one of the machines). The attribute of at least one of the data fields may come from and/or be updated by a client terminal operated by a first entity or a first service provider that originated or created the electronic document . These data fields may contain parameters describing the transaction, such as container size, event date, port of landing, description of goods, gross weight, vessel name and loan account, among others. In some embodiments, the electronic file may be maintained on a database (eg, file control center 3002). The database may be maintained or belong to a transport document control hub for coordinating communications among the client terminals. Each data field of the electronic document maintained on the database may correspond to a database entry on the database.

In some embodiments, in creating the electronic document, the server may receive a request to set, assign, or otherwise update an attribute of a data field in the electronic document. The request may come from one of the client terminals associated with the service provider that facilitated the electronic document following the initial setup by the first entity. The service provider associated with the request may relate to the first entity or any of the other service providers that contributed to the data fields of the electronic document or provided attributes for the data fields of the electronic document Lack of any (or limited) understanding or interaction. In this way, the data fields of the electronic document can be populated in a particular manner with information from various entities. Some or all service providers may be introduced or involved in a single transaction (e.g., sub-transaction or part) in a particular manner (e.g., as needed or close to the time at which a service provider's role in the transaction arises or at that time) rather than predetermined (eg, when creating an electronic file). Each part or sub-transaction of a transaction may be populated or serviced by one of the plurality of available service providers, which may be dynamically matched, populated and/or selected as the transaction develops and/or as needs/actions/sub-transactions arise . The service provider may have no knowledge of the transaction other than the role/service and/or the service provider(s) with which a service provider directly interfaces to perform the service provider's role/service in the transaction have limited knowledge of the transaction). The request identifies the data field in the electronic document to be updated and the new attribute to be set to the data field. The server can determine whether the client terminal has the authority to modify the data field according to an access control principle for a role of the client terminal. The access control principle can specify which data fields the client terminal (or the corresponding role) involved in the transaction has permission to access or modify. In order to determine whether the authority exists, the client terminal can identify a role of the client terminal in the transaction. The role can be identified from a list of roles in the sub-transaction series involved in the transaction.

When the role (or authorized/valid role) is not identified for the client terminal, the server may determine that the client terminal lacks the authority to modify the data field, and may maintain the attributes in the data field. Otherwise, when identifying a role, the server can identify the access control policy for the role. The server may determine whether the client terminal has authority based on the access control principle for the role identified by the client terminal. When the access control principle stipulates that the client terminal (or role) lacks the authority, the server may determine that the client terminal lacks the authority. The server may also prevent the requesting client terminal from updating the attributes of the data fields in the electronic document. Conversely, when the access control principle stipulates that the client terminal (or role) has the authority, the server may determine that the client terminal has the access authority. The server may allow the client terminal to update the attributes of the data fields in the electronic document. In some embodiments, the server may identify attributes and assign attributes to data fields upon request.

Method 3600 can include identifying an encryption key (3610). Each encryption key can be used to encrypt a corresponding data field in the electronic document. Each encryption key can also be associated with one of the client terminals that provide attributes to corresponding data fields in the electronic document. The encryption keys can be generated by the server or the corresponding client terminal. Encryption keys can be generated according to asymmetric cryptography, such as public key cryptography, Diffie-Hellman key exchange, elliptic curve functions, and an RSA cryptosystem, among others. In some embodiments, the identified encryption keys may include a set of private encryption keys and a set of public encryption keys for the corresponding client terminal. Each private encryption key may correspond to one of the data fields and may be associated with one of the client terminals providing attributes to the data fields. Each public encryption key may correspond to one of the data fields and may be associated with one of the client terminals that provided attributes to the data fields. In some embodiments, the server may retrieve, collect, or aggregate encryption keys (eg, public encryption keys) from client terminals involved in a single transaction. Each encryption key aggregated by the server may be generated by one of the client terminals that provide attributes to data fields in the electronic document. In some embodiments, a new encryption key may be identified for updating a data field using attributes from one of the client terminals.

Method 3600 can include distributing encryption keys (3615). The server may provide, deliver, and distribute encryption keys for electronic documents across client terminals involved in a single transaction according to access control principles. An access control policy may specify access rights (eg, decrypt, open, write, or edit) to each data field in an electronic document for a client terminal (or corresponding role). The access control policy may specify access rights based on a role of an individual client terminal. For each of the data fields in the electronic document, the access control policy may instruct at least two client terminals (or corresponding roles) to access the data field.

In a distribution, the server may provide a corresponding private encryption key to each of the client terminals involved in a single transaction. The private encryption key can be used to encrypt or decrypt data fields provided by the corresponding client terminal. In some embodiments, the server may identify two or more client terminals involved in a single transaction according to access control principles based on their respective roles. For example, a first role associated with a first client terminal and a second role associated with a second client terminal may be specified by access control principles as having access to data fields in the electronic file access to one of the positions. The server may encrypt an encryption key (eg, a private encryption key) of the first client terminal using another encryption key (eg, a public encryption key) of the second client terminal. During encryption, the server may provide the encryption key of the first client terminal to the second client terminal.

In addition, the server may provide a public encryption key to one or more of the client terminals according to the access control principle. For example, the access control policy may specify for one of the data fields that both client terminals have permission to access attributes in the data field. In this example, the server may provide the public encryption key to both client terminals. In this way, each of the data fields in the electronic document can be accessed by one or more of the client terminals using either the private encryption key or the public encryption key provided to the client terminal.

In some embodiments, the server may determine whether the distribution of the encryption key across one of the client terminals was successful. The server may transmit, send, or provide a message (eg, an event notification) to one or more of the client terminals based on the determination. When the distribution is determined to be successful, the server may issue or provide a success code to one of the client terminals (such as a client terminal that sends a request to update one of the data fields in the electronic file) or more. Conversely, when the distribution is determined to be unsuccessful, the server may issue or provide an error code to one or more of the client terminals.

In some embodiments, the server may identify a hash value derived from a corresponding attribute in one of the data fields in the electronic document. The hash value may be generated using a hash function such as a cyclic redundancy check, a checksum check code, a cryptographic hash function, and a message authentication code, among others. The hash value may be generated by a client terminal that provides the attribute to a data field in the electronic document. The hash value may be used to ensure the data integrity of attributes assigned to data fields in the electronic document. The server may also distribute hash values across client terminals according to access control principles.

In some embodiments, the server may receive or identify a signature for each of the client terminals involved in a single transaction. The signature may be generated by applying the encryption key corresponding to the client terminal to a hash value derived from an attribute of the data field provided by the free client terminal. The signature can be generated by a server or a client terminal that provides attributes. The signature can be used to ensure the data integrity of the attributes in the data fields in the electronic document.

Method 3600 can include providing access (3620). The server may provide each client terminal with access to one or more of the data fields in the electronic document using encryption keys distributed according to access control principles. In some embodiments, a server may input, provide, generate and/or maintain data fields or attributes of electronic documents. In some embodiments, the server may receive access to one or more of the electronic documents using an identifier (eg, a shipping document identifier or reservation number, carrier organization) from one of the client terminals One of the data fields is requested. The server can determine whether the electronic document referenced by the identifier exists on the database. When it is determined that the electronic document does not exist, the server may return an error message. Conversely, when it is determined that the electronic file exists, the server can continue to verify whether the client terminal accesses the data field. Each client terminal may be able to use a corresponding encryption key provided to the client terminal to access the data field to which the client terminal provides the attribute. Additionally, each client terminal may be able to access the data fields using a corresponding encryption key provided to the client terminal, as dictated by the access control principles.

In some embodiments, the server may provide access to one of the data fields in the electronic document to two or more client terminals identified according to access control principles based on roles. The hash value and signature of the data field in the electronic document may have been provided to each of the identified clients. A hash value can be derived from the attribute in the data field and a signature can be generated using the hash value of the client terminal providing the attribute and an encryption key (eg, the public encryption key). Through the hash value and signature, other client terminals can obtain the encryption key to access the attributes in the data field. Other client terminals may calculate the hash value based on the encrypted attribute, and decrypt the signature using the hash value to obtain the decrypted hash value. The client terminal can then compare the decrypted hash value to the hash value to determine integrity. When the hash values match, the client terminal can determine that the attribute has data integrity. Otherwise, when the hash values do not match, the client terminal may determine that the attribute lacks data integrity.

Referring now to FIG. 37, a computer 3700 may include one or more processors 3705, volatile memory 3710 (eg, random access memory (RAM)), non-volatile memory 3720 (eg, one or more hard drives) computer (HDD) or other magnetic or optical storage media, one or more solid-state disk drives (SSD) (such as a flash drive or other solid-state storage media), one or more hybrid magnetic and solid-state disk drives, and /or one or more virtual storage capacities (such as a cloud storage device or a combination of such physical storage capacities and virtual storage capacities or an array thereof), a user interface (UI) 3725, one or more communication interfaces 3715, and Communication bus 3730. The user interface 3725 may include a graphical user interface (GUI) 3750 (eg, a touch screen, a display, etc.) and one or more input/output (I/O) devices 3755 (eg, a mouse, a keyboard, etc.) , a microphone, one or more speakers, one or more cameras, one or more biometric scanners, one or more environmental sensors, one or more accelerometers, etc.). Non-volatile memory 3720 stores operating system 3735, one or more applications 3740, and data 3745 so that, for example, computer instructions for operating system 3735 and/or application 3740 are processed outside of volatile memory 3710 3705 executes. In some embodiments, volatile memory 3710 may include one or more types of RAM and/or a cache memory that may provide a faster response time than a main memory. Data may be entered using one of the input devices of GUI 3750 or received from I/O device 3755. The various elements of computer 3700 may communicate via one or more communication buses shown as communication bus 3730.

Computer 3700 as shown in FIG. 37 is shown (by way of example only) as clients, servers, intermediaries, and other networked devices, and may be used by any computing or processing environment and by virtue of being able to have functions as described herein And the operation is implemented by any type of machine or set of machines suitable for hardware and/or software. The processor 3705 may be implemented by one or more programmable processors to execute one or more executable instructions, such as a computer program, to perform the functions of the system. As used herein, the term "processor" describes circuitry that performs a function, an operation, or a sequence of operations. The function, operation or sequence of operations may be hard-coded into the circuitry or soft-coded by means of instructions stored in a memory device and executed by the circuitry. A "processor" may perform the function, operation or sequence of operations using digital values and/or using analog signals. In certain embodiments, the "processor" may be embodied in one or more application specific integrated circuits (ASICs), microprocessors, digital signal processors (DSPs), graphics processing units (GPUs), microcontrollers , Field Programmable Gate Arrays (FPGA), Programmable Logic Arrays (PLA), multi-core processors, or general-purpose computers with associated memory. The "processor" can be analog, digital or mixed signal. In some embodiments, the "processor" may be one or more physical processors or one or more "virtual" (eg, remotely located or "cloud") processors. A processor comprising multiple processor cores and/or multiple processors may provide functionality for parallel concurrent execution of several instructions on more than one data element or for parallel concurrent execution of one instruction on more than one data element sex.

Communication interface 3715 may include one or more interfaces to enable computer 3700 to access a computer network through various wired and/or wireless or cellular connections, such as a local area network (LAN), a wide area network (WAN), a personal area network (PAN) or the Internet.

Embodiments of the subject matter and operations described in this specification can be implemented in digital electronic circuits or in computer software, firmware, or hardware (including the structures disclosed in this specification and their structural equivalents), or in each of them In a combination of one or more of the items. Embodiments of the subject matter described in this specification can also be implemented as one or more computer programs, that is, encoded on one or more computer storage media for execution or use by data processing equipment, such as a processing circuit One or more computer program command modules to control the operation of data processing equipment. A controller or processing circuit (such as a CPU) may include any digital and/or analog circuit components configured to perform the functions set forth herein, such as a microprocessor, microcontroller, application specific integrated circuit, Programmatic logic, etc. Alternatively or additionally, the program instructions may be encoded on an artificially generated propagated signal (eg, a machine-generated electrical, optical or electromagnetic signal) generated to encode for transmission to suitable reception information for a data processing device to execute.

A computer storage medium may be or be included in: a computer readable storage device, a computer readable storage substrate, a random or serial access memory array or device, or any of these A combination of one or more. Furthermore, while a computer storage medium is not a broadcast signal, a computer storage medium can be a source or destination of computer program instructions encoded in an artificially generated broadcast signal. The computer storage medium can also be, or contained in, one or more separate components or media (eg, multiple CDs, disks, or other storage devices). Thus, the computer storage medium is both tangible and non-transitory.

The operations described in this specification can be implemented as operations performed by a data processing apparatus on data stored on one or more computer-readable storage devices or received from other sources. The terms "data processing equipment" or "computing device" include all kinds of equipment, devices and machines for processing data, including by way of example a programmable processor, a computer, a system-on-a-chip or any of the foregoing more than one or a combination. The apparatus may include special purpose logic circuitry, eg, an FPGA (field programmable gate array) or an ASIC (application specific integrated circuit). In addition to hardware, the device may also contain code that creates an execution environment for the computer program in question, for example, constituting processor firmware, a protocol stack, a database management system, an operating system, a cross-platform operation A time environment, a virtual machine, or a combination of one or more of the same. The device and execution environment can implement a variety of different computing model infrastructures, such as web services, distributed computing, and grid computing infrastructures.

A computer program (also known as a program, software, software application, descriptive language, or code) is written in any form of programming language, which may include compiled or interpreted language, declarative or procedural language, and may Deploy the computer program in any form, including as a stand-alone program or as a module, component, subroutine, object, or other unit suitable for use in a computing environment. A computer program may but need not correspond to a file in a file system. A program may be stored in part of a file that holds other programs or data (eg, one or more descriptive languages stored in a markup language file), in a single file dedicated to the program in question, or Stored in multiple coordinated files (eg, files that store portions of one or more modules, subprograms, or code). A computer program can be deployed to be executed on one computer or on multiple computers that are located at one site or distributed across multiple sites and interconnected by a communication network.

The procedures and logic flows set forth in this specification can be executed by one or more programmable processors executing one or more computer programs to perform actions by operating on input data and generating output. The programs and logic flows can also be executed by special purpose logic circuitry, such as an FPGA (field programmable gate array) or an ASIC (application specific integrated circuit), and devices can also be implemented as such special purpose logic electrical system.

Processors suitable for executing a computer program include, by way of example, both general-purpose and special-purpose microprocessors, and any one or more processors of any kind of digital computer. Generally, a processor will receive instructions and data from a ROM or a random access memory or both. The basic elements of a computer are a processor for performing actions according to instructions and one or more memory devices for storing instructions and data. Generally, a computer will also include or be operatively coupled to receive one or more mass storage devices (eg, magnetic disks, magneto-optical disks, or optical disks) for storing data from the one or more mass storage devices data or transmit data to or both receive and transmit data. However, a computer need not have such a device. Additionally, a computer can be embedded in another device, such as a mobile phone, a personal digital assistant (PDA), a mobile audio or video player, a game console, a global positioning system (GPS) receiver, or a Portable storage device (eg, a Universal Serial Bus (USB) flash drive) (to name a few). Devices suitable for storing computer program instructions and data include all forms of non-volatile memory, media, and memory devices, including by way of example: semiconductor memory devices (eg, EPROM, EEPROM, and flash memory devices); magnetic Disks (eg, internal hard disks or removable disks); magneto-optical disks; and CDROM and DVD-ROM disks. The processor and the memory may be supplemented by or incorporated in special purpose logic circuitry.

To provide interaction with a user, embodiments of the subject matter described in this specification can be implemented on a computer having: a display device such as a CRT (cathode ray tube) or LCD (liquid crystal display) a monitor, OLED (Organic Light Emitting Diode) monitor, or other form of display for displaying information to the user; and a keyboard; and/or a pointing device, such as a mouse or a trackball, the user Input may be provided to the computer via the pointing device. Other types of devices may also be used to provide interaction with a user; for example, feedback provided to the user may be any form of sensory feedback, such as visual feedback, auditory feedback, or tactile feedback; and User input can be received in any form, including sound, voice, or tactile input. In addition, a computer can interact with a user by sending files to and receiving files from a device used by the user; for example, by responding to a device from a user's client side The web browser receives the request and sends the web page to the web browser.

While this specification contains details of many specific embodiments, these details should not be construed as limitations on the scope of any embodiment or what may be claimed, but rather as descriptions of features specific to a particular embodiment. Certain features that are described in this specification in the context of separate embodiments can also be implemented in combination in a single embodiment. Conversely, various features that are described in the context of a single embodiment can also be implemented in multiple embodiments separately or in any suitable subcombination. Furthermore, although features may be stated above as functioning in a particular combination and even originally claimed as such, in certain instances one or more features from a claimed combination may be removed from that combination, and the claimed combination A claimed combination may be directed to a subcombination or a variation of a subcombination.

Similarly, although operations are depicted in the figures in a particular order, this should not be construed as requiring the particular order shown or in a sequential order to perform these operations or perform all illustrated operations to achieve Desirable result. In certain situations, multitasking and parallel processing may be advantageous. Furthermore, the separation of the various system components in the embodiments described above should not be construed as requiring such separation in all embodiments, and it should be understood that the described program components and systems may generally be integrated together in a single software product or packaged into multiple software products.

References to "or" may be construed as inclusive, such that any term stated using "or" may indicate a single, more than one, and any of all stated terms.

Accordingly, specific embodiments of the subject matter have been described. Other embodiments exist within the scope of the appended claims. In some cases, the actions recited in the claims can be performed in a different order and still achieve desirable results. Additionally, the processes depicted in the figures do not necessarily require the particular order shown, or sequential order, to achieve desirable results. In certain embodiments, multitasking and parallel processing may be advantageous.

While specific embodiments of the method and system have been described, it will now be apparent to those skilled in the art that other embodiments incorporating the concepts may be used. It should be understood that the systems set forth above may provide any or more of each of these components, and that these components may be provided on a single machine or, in some embodiments, in a distributed system on multiple machines. The systems and methods described above can be implemented as a method, apparatus, or article of manufacture using programming and/or engineering techniques to produce software, firmware, hardware, or any combination thereof. In addition, the systems and methods described above may be provided as embodied on or in one or more articles of manufacture or as one or more computer readable programs. The term "artifact" as used herein is intended to encompass code or logic accessible from and embedded in one or more computer-readable devices, firmware, programmable logic, Memory devices (eg, EEPROM, ROM, PROM, RAM, SRAM, etc.), hardware (eg, integrated circuit chips, field programmable gate arrays (FPGA), application-specific integrated circuits (ASIC), etc.), electronic Device, a computer-readable non-volatile storage unit (eg, CD-ROM, floppy disk, hard disk drive, etc.). The artifact may be accessed from a file server that provides access to computer-readable programs via a network transmission line, wireless transmission media, spatially propagated signals, radio waves, infrared signals, and the like. The article can be a flash memory card or a magnetic tape. An article of manufacture includes hardware logic and software or programmable code embodied in a computer-readable medium and executed by a processor. In general, a computer readable program can be implemented in any programming language (such as LISP, PERL, C, C++, C#, PROLOG) or in any byte-coded language (such as JAVA). Software programs can be stored as object code on or in one or more artifacts.

102: Shipper 104: Forwarder 106: Carrier 108: Terminal 110: Customs 112: Port Authority 114: Consignee 116: Financial Institution 200: Shipping Routes 202: Shipper 204: Port Authority 206: Vessel Operator 208 : Final Consignee 300: Key Repository Program 302: Start 304: Step 306: Step 308: Step 310: Step 312: End 400: Key Location 402: Public Key 404: Private Key 406: Encrypted Data Encryption Key 408: Decrypted Data Encryption Key/Data Encryption Key 410: Secure Network Connection 412: Secure Network Connection 500: Authentication Procedure 502: Client Application/User's Client Application 504: Security Network Connection 506: Authorization Token Generator/Token Generator 508: Booking API 600: API 602: Client Application 604: API Management Tool 606: Blockchain Application Design INTERFACE 608: Authenticate Request 610: Token 612: Reservation Request Payload/Payload 614: Send Organization ID and Payload Request to Blockchain Application Programming Interface 616: User Authentication 618: Provide Token Authentication 700 : API Manager 702: Start Block 706: Step 708: Step 710: Step 712: Step 714: Step 716: End 718: Step 800: Transport Document Data Distribution 802: Start Block 804: Step 806: Step 808: Step 810: Step 812: End Block 900: Shipping Document Creation Model/Get Booking Procedure 902: Start 904: Step 906: Step 908: Step 910: Step 912: Step 914: Step 916: Step 918: Step 920: End 1000: Sample Booking Order 1100: Retrieve Shipping Documents/Fetch Booking Procedure 1102: Start Block 1104: Attribute Validation 1106: Obtain Booking Information from Shipping Document Database and Decrypt Encrypted Booking Information 1108: Ensure that the desired booking is properly retrieved and Decryption of Desired Subscription 1110: Transport Role Check 1112: Filter Properties 1114: Success 1116: Error Response 1118: End 1200: Create Transport File 1202: Start Block 1204: Check Properties Validation 1206: Find a role list for subscription by locating subkey 1208: Check if the access policy for the booking can be defined 1210: Collect the transport roles of the transporter 1212: Check if the collected transport roles have access to create all submitted attributes of the booking data 1214: Generate a unique booking identifier for the booking 1216: Generate individual data encryption keys for each data attribute 1218: Encrypt each data attribute 1220: Retrieve access control policy for each transport role 1222: Retrieve public key from public key repository 1224: Use The public key of the transporter will correspond to Data encryption keys are encrypted one by one 1226: Distribute encrypted data and encrypted data encryption keys to appropriate organizations 1228: Verify successful distribution of data and keys to all ledgers of the relevant transporter 1230: Distribute the ledger The name, unique subscription ID and subscription version number are stored in the transport document database 1232: A successful response code is generated 1234: An error is returned 1236: End 1300: System 1302: Transport document control center 1304: Off-chain database 1306a: First User Node/User Node 1306b: User Node 1306n: User Nodes 1308a-1308n: Client Application 1310a-1310n: Client Application Database 1312a-1312n: Key Store 1314a-1314n: Password Access Layer 1316a-1316n: API/Blockchain API 1318a-1318n: Network Communication/Network Connectivity 1320a-1320n: Blockchain Logic 1322a-1322n: Blockchain Node 1400: Access Principle 1500: Procedure 1502: Start Block 1504: Step 1506: Step 1508: Step 1510: Step 1512: Step 1514: End 1600: Roles and Access Control Principles 1602: Data and Key Structures 1604: Sample Access Control Principles/Receive Shipper's Access Control Principle 1606: Encrypt each data attribute individually by means of a Data Encryption Key 1608: Public Key Encryption of Data Encryption Key 1700: Component Relationship Example/Example 1702: Access Principle/Transport Document Access Principle 1704: Role List Access Principle 1706: Unique ID/Transport Document 1708: Locate Subkey 1710: Role List 1712: Locate Subkey 1714: File Type 1716: Event Type 1718: Transport Role List 1720: Container Role List 1800: Role List and Access Control Principle 1802: Role List Access Principle Locating Subkey 1804: Role List Access Principle Instance 1806: Role Attribute Hierarchy Instance 1808: Role List Locating Subkey 1810: Role List Contents 1900 : Transportation Documents/Transportation Documents and Access Control Principles 1902: Container Departure Events/Exit Instances/Exit Event Instances 1904: Role List Positioning Subkeys 1906: Transport Document Access Principles/Transport Document Hierarchy Principles Examples 1908: Transport Document Architecture Examples /Examples/Architecture Example 1910: Transport Document Access Principles at the Outbound Event Field Level/Transport Document Principles Field Hierarchy Instances/Field Level Instances 2000: Example Transport Document Principles 2002: Dangerous Goods Document Instance 2004: Role List Locator Key 2006: Document Level Access Principles 2008: Field Level Access Principles/Field Level 2010: Dangerous Goods Credential Architecture Examples 2100: Logical System Layout/System Layout 2102: Transport Document Control Hub 2104: First User Node/Client Node/User Node 2106: Document Control Hub Side Message Broker/Message Broker 2108: Event Message 2110: Event Message 2112: Access Principle 2114: Public Key Repository 2116: ID Repository 2118: Client Node/User Node 2124: User Information Broker 2126: User Information Broker 2200: Sample Flowchart/Role List Submission Detailed Procedure 2202: Initial Check Attribute Verification 2206: Role Check 2208: Define Role List Access Policy 2210: Access Rights Check 2212: Return an Error Response Code 2214: Generate Encryption Key 2216: Encrypt the Role List 2218: Generated by signing the hash with the sender's private key Sender's signature 2220: Obtain public key 2222: Encrypt data encryption key 2223: Send message to transport document control center 2224: Distribute data and encryption key 2226: Check distribution successful 2228: Will have an error code Event Post to Message Broker 2232: Post an event with a success code that can go to the client side Message Broker 2234: End 2300: Role List Read Detailed Process/A Procedure for Reading a Shipping Document 2302: Check Attribute Verification 2304: Obtain Encrypted Role List and Encrypted Data Encryption Key 2310: Check Correlation of Role List 2312: Access Key Storage Area 2314: Decrypt Data Encryption Key 2316: Return an Error Response Code 2318: Decrypt the list of roles 2320: Return a success response code 2322: End block 2402: Check attribute validation 2404: Check if there is an existing list of roles from one of the access policy repositories 2406: Transport role check 2408: Check if it can be transported Access policy defined at document level and transport document field level 2410: Access right check 2412: Generate a unique transport document identifier that can be unique throughout the system 2414: Generate data encryption key 2416: Encrypt data attributes 2418: Generate a hash on encrypted data attributes and access the key store to sign the hash with the sender's private key to generate the sender's signature 2420: Obtain the public key 2422: Encrypt the data encryption key 2424: Package 2426 message with encrypted data attributes, encrypted data encryption key, hash and sender's signature: send message to transport document control hub 2428: made by having each user node with a success notification Respond to see if distribution was successful 2430: Receive one with encrypted shipping document, encrypted DEK, hash and sender's signature Publish Event 2432: Publish a successful event notification to sender 2436: Check integrity 2438: Decrypt encrypted data encryption key 2440: Decrypt shipping document 2442: Client application can receive shipping in plain text File 2448: End Block 2502: Start Block 2504: Check Attributes 2506: Check an Existing Transport Document 2508: Found Existing Role List 2510: Role Check 2512: Define Access Policy 2514: Access Rights Check 2516: Merge Existing Transport Document Attributes 2518: Increment shipping document version number by one 2520: Generate data encryption key 2522: New data attributes in submitted shipping document Data Attribute Encryption 2526: Generate a hash for any newly encrypted data attributes (data fields) and access keystore to generate sender's signature by signing the hash with sender's private key 2528: Get role Public keys of parties in list 2530: Encrypt updated data encryption key 2532: Pack message with encrypted data attributes, encrypted data encryption key, hash and sender's signature 2534: Pack encrypted data Encrypted Transport Document, Encrypted Data Encryption Key, Hash and Sender's Signature Key Distributed to Appropriate Blockchain Ledger 2536: Is the implementation successful in distributing Encrypted Transport Document, Encrypted Data Encryption Key, Hash and Send 2538: Post an event with an encrypted shipping document, encrypted data encryption key and sender's signature to intended recipient 2540: Check integrity 2542: Decrypt data encryption key 2544 : Decrypt shipping document 2546: Receive shipping document in plain text 2548: Return error response code to receiver 2550: Execute a message with success code to sender in case a success code is sent to sender's message broker A publish event 2554: publish an event with an error code to be sent to the sender's message broker 2556: end block 2600: an example procedure for reading a shipping document 2602: start block 2604: contrast a Transaction Reference Checks the Transport Document Version Number 2606: Attribute Verification 2608: Obtains Encrypted Transport Document and Encrypted Data Encryption Key 2610: Checks Dependencies 2612: Accesses Key Store 2614: Retrieves Data Encryption Key 2616 :Error 2618:Decrypt encrypted shipping document 2620:Return a successful response code to client application 2622:End 2700:Subscription configuration 2702:Subscription version number 2800:Partial subscription view 2900:Possible activity 2902:Registered use User/User 2904: Third Party 2906: File Control Hub 2908: User Node 2910: Third Party Node 3002: File Control Hub 3004a: Transport Document Database 3004b: Access Policy Repository 3004c: Public Key Repository 3004d: Identity Repository 3004n: Database 3006a: Recipient Repository Encrypted 3006b: Recipient Repository Encrypted 3006n: Recipient Repository Encrypted 3010 : Authentication function hosted by the file control center/Authentication function 3020: Secure communication link 3022: User 3024: User-controlled data encapsulation/Data encapsulation 3026: Data encryption key/encrypted data encryption key/decrypted data encryption Key 3028: User Private Key 3060: Third Party 3062: Third Party Controlled Data Encapsulation/Third Party Data Encapsulation/Data Encapsulation 3064: Separate Secure Communication Link 3102: Loan Application 3104: Application Authentication 3106: Compliance Inspection 3108: Payment 3110: Approved and Disbursed Loan 3112: Shipping Event 3114: Shipping Documents 3116: Invoicing 3118: Forwarder Going Through Its Own Forwarder Activity 3120: Bank Going Through Its Own Banking Activity 3200: Account 3202: Agency Carrier 3204: Secure Communications 3206: Bank 3208: Carrier 3210: System 3212: Terminal 3300: Project 3302: Forwarder 3304: Loan Application 3308: Carrier 3310: System 3312: Terminal 3314: Document 3400: Sample Invoice 3500: Exemplary Payment 3600: Method 3605: Step 3610: Step 3615: Step 3620: Step 3700: Computer 3705: Processor 3710: Volatile Memory 3715: Communication Interface 3720: Non-volatile Memory 3725: User Interface 3730: Communication Bus 3735: Operating System 3740: Applications 3745: Data 3750: Graphical User Interface 3755: Input/Output Devices

To easily identify the discussion of any particular element or act, one or the most significant digits of an element symbol refers to the figure number in which that element is first introduced.

Figure 1 illustrates a communication system.

FIG. 2 illustrates an example transportation route 200 according to an embodiment.

FIG. 3 illustrates a key vault procedure 300 according to an embodiment.

FIG. 4 illustrates an asymmetric key location 400 according to an embodiment.

FIG. 5 illustrates an authentication procedure 500 according to an embodiment.

FIG. 6 illustrates an API interface 600 according to an embodiment.

FIG. 7 illustrates an API manager 700 according to an embodiment.

FIG. 8 illustrates a shipping document data distribution 800 according to an embodiment.

FIG. 9 illustrates a shipping document creation model 900 according to an embodiment.

FIG. 10 illustrates a sample subscription list 1000 according to an embodiment.

11 illustrates retrieving a shipping document 1100 according to one of the embodiments.

FIG. 12 illustrates the creation of a shipping document 1200 according to one of the embodiments.

FIG. 13 illustrates an example system 1300 according to an embodiment.

FIG. 14 illustrates an example access principle 1400 according to an embodiment.

FIG. 15 illustrates generating keys and matching those keys and a user's assigned role to an access policy 1500, according to one embodiment.

16 illustrates a process for encrypting data attributes based on role and access control principles 1600, according to one embodiment.

FIG. 17 illustrates a component relationship instance 1700 according to one embodiment.

18 illustrates an example role list and access control principle 1800 according to one embodiment.

FIG. 19 illustrates an example transport document and access control principle 1900 according to one embodiment.

FIG. 20 illustrates an example shipping document principle 2000 according to one embodiment.

Figure 21 illustrates a system layout (logic) 2100 according to one embodiment.

FIG. 22 illustrates a detailed process 2200 of a role manifest submission according to one embodiment.

FIG. 23 illustrates a role manifest read detailed process 2300 according to one embodiment.

Figure 24 illustrates a shipping document creation 2400 according to one embodiment.

FIG. 25 illustrates a shipping document update 2500 according to one embodiment.

FIG. 26 illustrates a transport document reading 2600 according to one embodiment.

Figure 27 illustrates a subscription configuration 2700 according to an embodiment.

FIG. 28 illustrates a partial subscription view 2800 according to an embodiment.

29 illustrates a possible activity 2900 with respect to a third party non-user, according to an embodiment.

Figure 30 illustrates a user providing information from the system to a third party, according to one embodiment.

Figure 31 illustrates a possible loan application process according to an embodiment.

32 illustrates a documented exchange to support the establishment of a loan account, according to one embodiment.

33 illustrates a documented exchange to support applying for financing, according to one embodiment.

34 illustrates an example invoice according to an embodiment.

35 illustrates an example payment option according to an embodiment.

36 is a flow diagram of a method for securely sharing data from multiple sources with different client terminals, according to an embodiment.

37 is a block diagram of an embodiment of a computing device.

102: Shipper

104: Forwarder

106: Carrier

108: Pier

110: Customs

112: Port Authority

114: Consignee

116: Financial Institutions

Claims (20)

A method of generating a key for accessing a plurality of data attributes with different owners as part of a zero-trust communication system, wherein the plurality of data attributes are maintained on a server A portion of a common shipping document for one of the above goods, the method comprising: generating, by at least one processor, a data encryption key for a data attribute of the plurality of data attributes; storing, by the at least one processor, a data encryption key Retrieve a transport role for a transporter; retrieve an access control principle corresponding to the transport role from the memory by the at least one processor; retrieve using the access control principle one or more public keys at the transporter; and encrypting, by the at least one processor, the data encryption key using the one or more public keys of the transporter to create a data encryption key for the plurality of data attributes One of the data attributes is encrypted with the data encryption key. The method of claim 1, wherein the transporter has two or more transport roles. The method of claim 1, wherein the access control principle defines which of the plurality of data attributes the transporter accesses. The method of claim 1, wherein the public key is retrieved from a public key repository (repository). The method of claim 1, wherein the access control principle includes information about which of the plurality of data attributes each transporter can access. The method of claim 1, wherein the common shipping document is an electronic document. The method of claim 1, wherein the shared shipping document is a booking. The method of claim 1, wherein the access control policy is dynamically updatable. The method of claim 1, further comprising: distributing the encrypted data encryption key and an encrypted version of the data attribute to the transporter according to the transport role of the transporter. The method of claim 1, wherein the shipping party further comprises a government agency, a financial institution, or a trade organization interested in the common shipping document for the goods. A method of securely sharing data from multiple sources with different client terminals, the method comprising: establishing, by at least one server having one or more processors, a plurality of data attributes defining a plurality of transport parties A shipping document having a plurality of data fields, each of the plurality of data fields is associated with a plurality of usages each corresponding to one of the plurality of shipping parties one of the client terminals; encrypting the at least one data field from the plurality of data fields contained in the shipping document by the at least one server identifying at least one encryption key to form an encrypted data field ; distribute the at least one encryption key to at least one of the plurality of client terminals by the at least one server according to an access control principle according to a corresponding transporter's A transport role specifies access rights for a corresponding client terminal of the plurality of client terminals to one or more of the plurality of data fields; and by the at least one server according to the access The control principle distributes the encrypted data field in the transport document to at least one of the plurality of client terminals along with the at least one encryption key. The method of claim 11, wherein creating the shipping document further comprises: receiving a request from a first client terminal of the plurality of client terminals to update one of the plurality of data fields in the shipping document an attribute of a data field; determine that the first client terminal has the authority to modify the first data field based on a role of the first client terminal in the subscription according to the access control principle; and respond After determining that the first client terminal has the authority, the client terminal is permitted to update the attribute of the first data field in the common transport document. The method of claim 11, wherein identifying the at least one encryption key further comprises identifying a private encryption key and a public encryption key for the plurality of client terminals; and wherein distributing the encryption key further comprises: providing the The private encryption key is sent to one of the plurality of client terminals corresponding to the client terminal terminal; and provide the public encryption key to at least one of the plurality of client terminals according to the access principle, at least one of the plurality of data fields in the electronic file can be accessed by the plurality of users At least two of the end terminals are accessed using the private key and the public key. The method of claim 11, further comprising: identifying, by the at least one server, a plurality of hash values derived from a corresponding plurality of attributes in the plurality of data fields of the electronic document, the plurality of hash values each of the hash values ensures data integrity of one of the plurality of attributes; and using the plurality of client terminals by the at least one server for a first client terminal of the plurality of client terminals a first hash value in the hash value and a first encryption key in the plurality of encryption keys to generate a first signature, the first hash value is derived from a first attribute in the plurality of attributes, The first encryption key is for a first data field corresponding to the first attribute among the plurality of data fields, and the first signature ensures that the data of the first attribute and the first data field are complete sex. The method of claim 11, further comprising: determining, by the at least one server, at least one of the plurality of encryption keys and at least one of the encrypted data fields across the plurality of client terminals whether the distribution was successful; and providing an event notification to at least one of the plurality of client terminals by the at least one server based on a determination of whether the distribution of the encryption key and the encrypted data field was successful . The method of claim 11, wherein the transport of goods is an intermodal container. A system for securely sharing data from multiple sources with different client terminals, comprising: at least one server having one or more processors configured to: create one for defining an item for One of the at least one parameter of the transport is a common transport document, the shared transport document includes a series of data entries for the plurality of transporters, the shared transport document has a plurality of data fields, each of the plurality of data fields relating to one of the plurality of client terminals each corresponding to one of the plurality of transporters; identifying a plurality of encryption keys to encrypt the corresponding plurality of data fields contained in the common transport document; according to a an access control policy that distributes the plurality of encryption keys across the plurality of client terminals, the access control policy being specified for one of the plurality of client terminals according to a transport role of a corresponding transporter in the subscription corresponding client terminal access rights to one or more of the plurality of data fields; and providing each of the plurality of client terminals via the plurality of encryption keys distributed according to the access control principle access to at least one of the plurality of data fields in the electronic document. The system of claim 17, wherein the at least one server is further configured to: receive a request from a first client terminal of the plurality of client terminals to update An attribute of a first data field of the plurality of data fields in the common transport document; determining the first user based on a role of the first client terminal in the individual subscription according to the access control principle The client terminal has the authority to modify the first data field; and in response to determining that the first client terminal has the authority, allowing the client terminal to update the attribute of the first data field in the electronic document . The system of claim 17, wherein the at least one server is further configured to: identify a plurality of hash values derived from corresponding plurality of attributes in the plurality of data fields of the common transport document, the plurality of hash values each hash value in ensures the data integrity of one of the plurality of attributes; and using a first hash value of the plurality of hash values for a first client terminal set of the plurality of client terminal sets and a first encryption key of the plurality of encryption keys generates a first signature, the first hash value is derived from a first attribute of the plurality of attributes, wherein the first encryption key is for One of the plurality of data fields corresponds to a first data field of the first attribute, and the first signature ensures the data integrity of the first attribute and the first data field. The system of claim 17, wherein the transportation of goods is an intermodal container.

Images