TW202040568A - 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 of cargo 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.

The use of containers to transport goods over long distances is a standard form of transportation. Intermodal containers are used to transport goods by cars, trains and ships. The units are stackable and designed to move from one form of transport to another without opening the container. It may involve the delivery of one or more containers. One of the transportation is a transport carrier's promise to use intermodal containers or deliver goods as project goods (collectively called "goods" or "goods"). In order to successfully complete a transportation, relevant information needs to be shared among the different parties involved in the transportation. These parties include, but are not limited to, the transportation carrier, the ship operator in the transportation process, the port/terminal, the government agency, and the transportation party in the transportation (including the shipper, the consignee, and sometimes the forwarder and Notifying party). Other parties may also be involved in a cargo transportation.

In this article, a system and method for using a communication system involving zero trust is described. The communication system can be designed to work with users, who can be direct competitors or auxiliary competitors with each other, but sometimes it is desirable or necessary to work in the same space in order to achieve their business goals.

Companies involved in the loading, unloading and movement of shipping containers (sometimes called intermodal containers) use inter-enterprise (B2B) communications, electronic data interchange (EDI), and application programming interface (API) calls to communicate with each other. These communication channels are peer-to-peer, requiring one party to communicate with another party. The individual-to-individual nature of this communication generally does not allow multiple parties to "keep in circulation" at the same time. There are also changes in the agreements adopted by different parties on how they handle communications, so communications can be delayed or subject to corporate principles that reduce the timeliness of such communications. The geographical distribution of the parties in the moving cargo causes communication delays. Goods can originate in Asia and go to locations in America, Europe or Africa. The convenient time to try one party’s communication may be after the other party’s business hours, causing further delays.

Organizations that directly compete with each other can sometimes share resources to fulfill their corporate responsibilities. For example, two or more transportation companies share their ships to transport goods, making it possible to achieve better service coverage and economies of scale. Another example is where multiple shippers using the same forwarder can share a single intermodal container to avoid each having to pay and transport separate partially filled intermodal containers. When the company can coordinate its activities, achieve other economic and better service performance. However, coordination usually requires the disclosure of confidential information, which companies are reluctant to do. There are also legal requirements prohibiting the sharing of specific types of data with specific 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 system in the market. Therefore, parties that compete with each other or need to use each other's services will not share their confidential information.

The methods of handling intermodal containers and tracking their locations tend to focus on the contents of the containers, or to track them in small locations rather than in a global sense. Therefore, there is still a need for a communication 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 their tasks. Information, while keeping any other information confidential from the source (of the information). There is a further need for a system that can reduce the time required to track goods anywhere in the path of the transportation process and provide timely updates of the locations of both intermodal containers and project goods.

It is further necessary to provide all parties involved in the transportation, delivery loading and unloading of intermodal containers and project goods with timely status and transportation updates of one of these transportations, while protecting the privacy of data and commercial confidentiality. These and other goals can be met by the following disclosures.

Describe a system for generating a transport document. The system may have a transportation document control center and one or more user nodes. The transportation document control center may have a computer with a logic, a memory and a communication device. The hub may also have a message agent capable of sending and receiving event messages. There may be an access policy repository storing one of the global member 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 that has one or more users, one or more user login credentials, and a list of one or more user parameters. There may also be a blockchain database that includes one or more blockchain nodes that store the encrypted transport document, the encrypted data encryption key, and the signature of the document originator. These user nodes may have a computer, a message broker, a key storage area for decrypting transportation documents, an API interface with a cryptographic layer for encrypting transportation documents, and access to the transportation One or more of the portals of one of the document control centers. The API interface can be executed on the logic of the user's computer and communicate with the information agent of the transportation document control center.

It also describes an independent user node for use in generating a single shared transportation document transaction. The user node may have a computer with a logic for executing program instructions, a memory device, a user interface, and a communication device for accessing a transportation document control center. The user node may have a message agent capable of sending and receiving event messages. An API interface may have a password access layer, and the API interface coordinates the correspondence between the shared transportation document transaction and the transportation document control center. The user node may also have a blockchain database stored on the memory device. The memory device can be regional, remote, cloud-based, or removable. The blockchain database may have transportation documents related to the user's role in a single shared transportation document transaction.

It also describes an independent transportation document control hub for coordinating the communication between a first user node and a second user node in the distribution of a shared transportation (electronic) document. The shared transport document may have an encrypted data attribute, an encrypted data encryption key, and/or a digital signature of a document originator. The transportation document control center can use a computer with a 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 can use a routing logic to route a common transportation document received from the first user node to the second user node. The second user node may be one of the transport parties of the transport document provided by the first user node. There may be a distributed ledger stored on the memory. The distributed ledger can be used to store encrypted shared transportation documents (or select the data attributes of a shared transportation document) a blockchain database. It is also possible to store the encrypted data encryption key and a hash of the encrypted shared transport document and the digital signature of the originator of the shared transport document.

There is also a way to generate a common transport document. The method may involve: generating a shared transport document and encrypting the shared transport document through the password access layer in the API interface; the encrypted shared transport document, the encrypted data encryption key and the digital signature of the document originator Submit to a transportation document control center (hub); identify one or more users, and each user can have at least one assigned role according to an access control principle; the encrypted shared transportation document, the encrypted The data encryption key and the digital signature of the initiator of the document are forwarded to the one or more users, where the one or more users can be based on the one or more users as provided by the access control policy. Assign roles to fulfill one of the roles of the encrypted transport file.

There may also be a method for identifying user access rights to the shared transport document. The method may involve receiving a transport document to be shared by at least one user, the document having an initiator, a role list and an identification code. Then identify the initiator, determine the role of the initiator based on a global user list (or global member list), verify the role list of the shared transport document, and use the data encryption key to use 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 to at least one authenticated user.

It also explains additional aspects.

The cargo tracking system and method described in this article can help companies and individuals track the progress of cargo containers such as intermodal containers through transportation procedures. This can be achieved by assigning a role to each party when each party provides shipping documents to the system. The system can organize the transport documents and encrypt the transport documents according to a logical scheme. The transportation documents may undergo a process in which the encrypted transportation documents can be shared with other parties that are logically related to each other (for example, when they are all associated with a common carrier or agent). The data corresponding to the transported goods can be updated at various times and events during the transport of the goods from the starting point to the destination point. Each update generates new encrypted shipping documents, which can be shared with all parties that share a logical, business, or financial relationship.

The transportation document that represents the freight may contain information about the transportation of the goods, such as what kind of product can be transported, how much its weight and whether it requires any special handling (just to name a few). The transportation document may also contain information about the parties involved (such as shippers, consignees, transportation carriers) and transportation route information. In addition, the transportation file may include one or more event records that occurred during storage and transportation that are meaningful to its state. In short, the shipping document can cover various other details that can be related to any shipping. The access policy of the transportation document may also contain information about who can play a transportation role. A transport file 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 transportation document may be a virtual document of a cargo transportation. In some embodiments, the shipping document may contain information about a user.

In some embodiments, the party accessing the system may be the 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 the data presented in the system. In some embodiments, the user may be able to create data in the system. In still other embodiments, the user may be able to update the existing information in the system. In some embodiments, the user may be able to perform one or more of the following operations: 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 can be accompanied by different access rights or authorizations. In some embodiments, the 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 container transportation and tracking in real time. The system may include a computer with 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 as an organized data structure in the memory device. The computer may have a logic that enables the computer to transform the data from one or more users into an encrypted record. The computer can use various encryption methods to encrypt the data to generate the encrypted transport file. A series of data encryption keys can also be generated, wherein a 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 role of the user of the relevant shipping party. The public key of the user is called the key encryption key. These encrypted data encryption keys and encrypted data encapsulation can be provided to these users through a blockchain node that can be used by the system for each user. Nodes can be shared or dedicated to a transporter. A user can use a private key to decrypt the encrypted data encryption key, and then use the decrypted encryption key to decrypt the relevant data in the node.

In some embodiments, there may be a method to protect the privacy of the data of a transport document shared in a distributed user group. The method includes receiving the transportation document from a user via a communication network. The user may have an assigned role, wherein the transportation document includes a plurality of data attributes. There may also be a first encryption logic to encrypt the plurality of data attributes into a similar number of encrypted data attributes, and the first encryption logic generates a data encryption key corresponding to each encrypted data attribute. The method may also involve organizing the plurality of encrypted data attributes into a distributed data ledger through a programmed logic, the 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 through a second encryption logic. The second encryption logic can be one of the distributed data ledgers based on the assigned role of the user Or a lookup table of permissions provided by multiple users. The method may also have: distribute the encrypted data attributes and the encrypted data encryption key to the blockchain nodes via the communication network in a more efficient manner, so that the entire solution can be scalable . Each user can access a node that can provide access to one of the distributed data ledgers. Each user can decrypt only the data related to the assigned role.

Various encryption techniques can be used for the first encryption and the second encryption. The role assigned by the user can be associated with a user access control policy.

The use of the system and/or method can provide a combination of content context sensitive data isolation, encryption, and access control principles to achieve data privacy in a distributed ledger technology.

The at least one aspect of the present invention system for securely shared with a different one of the plurality of client terminals from a source of data method. At least one server with one or more processors can create an electronic file for defining a single transaction. The electronic file may have a plurality of data fields. Each of the plurality of data fields can be associated with one of the plurality of client terminals. The at least one server can identify a plurality of encryption keys to encrypt the corresponding plurality of data fields included in the electronic document. The at least one server can distribute the plurality of encryption keys across the plurality of client terminals according to an access control principle. The access control principle may be based on one of the plurality of client terminals corresponding to a role of the client terminal in the single transaction and stipulate that the corresponding client terminal corresponds to each of the plurality of data fields The access rights. The at least one server can provide at least one of the plurality of data fields in the electronic document to each of the plurality of client terminals via the plurality of encryption keys distributed according to the access control principle Access to one.

In some embodiments, creating the electronic file may include receiving and updating one of the plurality of data fields in the electronic file from a first one of the plurality of client terminals. A request for an attribute of the 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 The permissions of 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 authority.

In some embodiments, the at least one server may respond to the first client terminal receiving update from one of the plurality of client terminals in the plurality of data fields in the electronic document A request for an attribute of a first data field identifies a role of the first client terminal from a role list 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 recognized role of the first client terminal according to the access control principle Permissions. In some embodiments, the at least one server may prevent the first client terminal from updating the attribute of the data field in the electronic document in response to determining that the first client terminal lacks the authority.

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 one 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 file 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 may be 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 recognizes the first client terminal and the second client terminal. In some embodiments, the at least one server may respond to identifying the first client terminal and the second client terminal by using one of the second client terminal's public encryption key to make the first Encryption with a first encryption key of one of the client terminals. 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 multiple hash values derived from corresponding multiple attributes in the multiple data fields of the electronic document. Each of the plurality of hash values can ensure the data integrity of one of the plurality of attributes. In some embodiments, the at least one server may use one of the plurality of hash values and the plurality of encryption keys for one of the plurality of client terminal sets, the first client terminal set One of the first encryption keys generates a first signature. The first hash value can be derived from the first attribute of one of the plurality of attributes. The first encryption key may be for a first data field corresponding to the first attribute among the plurality of data fields. 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 may be 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 recognizes the first client terminal and the second client terminal. In some embodiments, providing access may include providing the second client terminal with a hash value derived from an attribute of the data field and a signature of the first client terminal. Access to one of the plurality of data fields of a client terminal. The second client terminal can use the hash value and the signature to obtain one of the encryption keys of the first client terminal.

In some embodiments, the at least one server can determine whether the distribution of the plurality of encryption keys across one of the plurality of client terminals is 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 is successful.

In some embodiments, identifying the plurality of encryption keys may include aggregating 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, creating the electronic document may include creating the electronic document on a database of a transportation document control center to coordinate communications among the plurality of client terminals, the plurality of data fields of the electronic document The bits correspond to the corresponding plural database items on the database.

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

The aspect of the present invention is a system for at least a plurality of common data from one source of system security with different client terminals. The system may include at least one server with one or more processors. The at least one server can create an electronic file for defining a single transaction. The electronic file may have a plurality of data fields. Each of the plurality of data fields can be associated with one of the plurality of client terminals. The at least one server can identify a plurality of encryption keys to encrypt the corresponding plurality of data fields included in the electronic document. The at least one server can distribute the plurality of encryption keys across the plurality of client terminals according to an access control principle. The access control principle may be based on one of the plurality of client terminals corresponding to a role of the client terminal in the single transaction and stipulate that the corresponding client terminal corresponds to each of the plurality of data fields The access rights. The at least one server can provide at least one of the plurality of data fields in the electronic document to each of the plurality of client terminals 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 and update one of the plurality of data fields in the electronic document from one of the plurality of client terminals. A request for an attribute of the 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 The permissions of 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 authority.

In some embodiments, the at least one server may respond to the first client terminal receiving update from one of the plurality of client terminals in the plurality of data fields in the electronic document A request for an attribute of a first data field identifies a role of the first client terminal from a role list 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 recognized role of the first client terminal according to the access control principle Permissions. In some embodiments, the at least one server may prevent the first client terminal from updating the attribute of the data field in the electronic document in response to determining that the first client terminal lacks the authority.

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 can provide one 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 can 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 file 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 may be 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 recognizes the first client terminal and the second client terminal. In some embodiments, the at least one server may respond to identifying the first client terminal and the second client terminal by using one of the second client terminal's public encryption key to make the first Encryption with a first encryption key of one of the client terminals. 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 End terminal.

In some embodiments, the at least one server can identify multiple hash values derived from corresponding multiple attributes in the multiple data fields of the electronic document. Each of the plurality of hash values can ensure the data integrity of one of the plurality of attributes. In some embodiments, the at least one server may use one of the plurality of hash values and the plurality of encryption keys for one of the plurality of client terminal sets, the first client terminal set One of the first encryption keys generates a first signature. The first hash value can be derived from the first attribute of one of the plurality of attributes. The first encryption key may be for a first data field corresponding to the first attribute among the plurality of data fields. 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 may be 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 recognizes the first client terminal and the second client terminal. In some embodiments, the at least one server may provide the second client terminal with a hash value derived from an attribute of the data field and a signature of the first client terminal. Access to one of the plurality of data fields of the first client terminal. The second client terminal can use the hash value and the signature to obtain one of the encryption keys of the first client terminal.

In some embodiments, the at least one server can determine whether the distribution of the plurality of encryption keys across one of the plurality of client terminals is 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 is successful.

In some embodiments, the at least one server can aggregate the encryption key corresponding to 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, the at least one server may create the electronic document on a database of a transportation document control center to coordinate communication among the plurality of client terminals, and the plurality of data fields of the electronic document The bits correspond to the corresponding plural database items on the database.

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

Those familiar with the art can understand alternative embodiments of the system and method based on the research of the present invention. For the purpose of the scope of patent application appended herein, these alternative embodiments are intended as equivalent content.

Cross reference of related applications

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

The sharing of data by multiple parties can produce synergy and efficiency. However, when conducting a single transaction (for example, a multi-level transaction, a multi-party transaction, a sub-transaction series/sequence), the information required or used may be confidential to one or more of the parties involved in the single transaction At times, data sharing can be a problem. In the field of transportation of goods, this problem can be particularly severe. Other businesses may also have this problem. One possible solution may be a system and procedure that uses encryption technology to protect the privacy of data while allowing appropriate parties to share relevant data in a distributed ledger system, as described in this article. The described system and method can be useful in transporting goods and cargo. The systems and methods described in this article can also be applied to other industries.

The cargo tracking system and method described in this article can help companies and individuals track the progress of cargo in the transportation process. This can be achieved by allowing each user to provide transportation documents to the system. The system may contain a look-up table that provides a list of roles and the rights of each role. When a user submits a transportation document to the system, the transportation document may contain the user's identification code and a list of roles of individual transportation parties. The system can correlate the listed roles of the users from the transport document with the rights of the roles in a lookup table. The system can process shipping documents, so users and related shipping parties can access the data after encrypting the data. Each user in the system can have one or more defined roles. The access to each data attribute in a transport document can be defined by the user's role. A user can only access data related to it according to the user's role in the access control policy.

The system can recognize a transport document submitted by a user and can encrypt each data attribute of the transport document. The first encryption procedure can create a unique encryption key for each data attribute.

As an example, a transportation document may have five headers and five data attributes. The first encryption procedure can 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 the attributes of each encrypted data. The header field of the distributed ledger corresponds to at least one of the header fields of the transportation document. In some embodiments, the header field of the distributed ledger corresponds to the header field of the shipping document on a one-to-one basis. The header field of the distributed ledger may not be encrypted, but the data attributes corresponding to each header field of the distributed ledger can 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. The second level of encryption can be performed by using the public key of one or more users with known roles in the transportation process. The second encryption process can identify the user's role in the transportation by correlating the user role from the transportation document with the lookup table. Then, the user's public key can be used to encrypt the encryption key corresponding to the data attribute of the user based on the role assigned by the user and the access policy. Various attributes (encrypted data attributes, encrypted encryption keys based on different roles, hashes (generated by encrypted data attributes), and signature of the file originator) can be placed in a permission-based blockchain distributed ledger In the blockchain node. Some users may have their own blockchain nodes. In order to improve scalability and performance when using blockchain distributed ledger, data can be placed in nodes belonging to users involved in transportation.

Each user in the system can have one or more assigned roles. The role list of each transportation document can identify the role of the user who submitted the role list of the transportation document, and the role list of the transportation document can identify the role of the user that can be involved in the transportation. In some embodiments, the role list can track who created it, the user's role and a list of corresponding users, and a location subkey (identification code of the creator and reservation number of the transportation document).

The various embodiments described herein can be used with all types of shipping documents. A common transport document is a "reservation"-creating a precursor document of a bill of lading. Although many shipping documents can be used with the system of the present invention, many examples can use the term "reservation" or "reservation information." These terms should be regarded as the same as any transport documents or transport documents, respectively.

In some embodiments, each user may have a relationship that allows them to see each other's data attributes. In some embodiments, there may be a business relationship constructed into a lookup table that allows a user to see data that is not part of his own business. A look-up table of access rights can be derived by identifying the rights needed by each party and the rights they expect. The system controller is the ultimate arbiter of the 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 distributed ledger.

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

A schematic diagram of the overall procedure in a specific method.

Shown in Figure 1 is a procedure for tracking the status of a transport in a freight lane. The shaded ellipse shows the parties in a single transportation 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 that transports the goods to the consignee.

Consignee-a person or company designated in the freight contract to transport or hand over the goods to the caregiver.

Forwarder (or cargo forwarder)-A person or enterprise engaged in the business of assembling, collecting, consolidating, transporting and distributing less-than-carload (less-than-carload or less-than-truckload) cargo. And one of the agents in the transshipment of goods through customs (including adequate preparation of documents, arranging transportation, warehousing, delivery and export clearance).

Carrier-an entity or legal entity that operates to transport passengers or goods for rent.

Ship operator-any business unit responsible for the operating costs, maintenance and surplus of ships. The operator may or may not be the owner of the ship. The cost includes crew wages, port fees 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 can carry the transportation booked through other carriers.

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

In addition to these parties in a cargo transportation, there may also be other parties interested in a cargo transportation, such as government agencies (customs, inspection bureau), financial institutions, insurance companies, and so on.

A shipper 102 can 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, every communication with other parties is a one-way communication with one of each party, and each party basically sends certain information related to a transportation to the other parties. And then the receiving party sends a response to the original party. Each party in the program may have developed its own proprietary technology for this form of communication. The communication protocol is not integrated to work together, so each receiving party will receive a message, and then respond with its own agreement and wait for 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 transportation. Various roles are shown in Figure 2. The position of each assigned role is marked by a different shade in the figure. Figure 2 is only illustrative. Many other character positions are possible and exist in actual transactions. It can be seen in the illustration 200 shown in FIG. 2 that a system for booking and shipping freight is created worldwide. In some embodiments, a shipper 202 may initiate a transportation reservation by determining that the merchandise will be collected and sent to a specific destination. The shipper 202 can create a reservation request (a preparatory step of forming a commercial contract to send the goods), and designate a port authority 204 with a terminal A, B, and C as shown. The shipper may also choose a ship or ship to carry the goods by a ship operator 206. The shipper 202 may also designate a final consignee 208 for transportation. Also illustrated in Figure 2 by way of examples illustrate the possible routes of a transportation. If you follow the path from the starting point (receiving place) to the ending point (final destination), it can be seen that many parties are involved. Transporting goods within this route may involve many parties, all of which have their own communication mode, as explained earlier.

The above examples do not show all the parties involved in a transportation. Whenever cargo enters a port, a port authority 204 may have several agents working under its jurisdiction. There may be various inspectors (for example, for food, livestock, fruits and vegetables), inspections of unauthorized dangerous goods, ITC inspections to prove any sanctioned materials, immigration inspectors, etc. The terminal operator can be a private company and has 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 along a chain of subsidiaries of a parent organization.

In this article, various embodiments of a system and method for creating a new type of booking contract (a type of transportation document) are described. The new type of booking contract allows the relevant parties of the agreement to be checked by a single point of contact And track the progress of the shipment. This single point of contact provides up-to-date information that is available to all relevant parties and avoids restricted communications that allow each party to communicate with each other party one at a time or in a sequential manner. Each user can be continuously updated as the goods move through each stage of delivery. These updates may include the status of the goods, debts, regulatory issues and other issues.

As used herein, the term "user" can refer to a body or tissue. A user can be any person, party, organization, or program that can access the system and interact with the procedures described in this article. Any individual or entity that can access the system as described herein can be considered a user. The present invention also utilizes lists detailing the specific rights, privileges and responsibilities of each user. Generally speaking, a user can represent a role in a transaction, although it is not necessary to make each user a party to the transaction. The terms "user" and "party" can be used interchangeably in this article, unless the context clearly indicates otherwise.

In some embodiments, a user can log on to the system and then obtain a key storage inventory and various assigned keys. The user can start a key storage library program 300 (FIG. 3) to an initial login or start 302 of the system. The user logs on to the system and the system can log in to a key storage area, and the key storage area generates a key repository 304 for the user. A global user list (or global member list) of the system can record basic information of users. The basic information may include the user's name, the user's role in any reservation, contact information, and other information related to the user's role. The system can store the mapping of the user key repository in a key repository mapping database 306. Then, the user can log in to the system to generate a public key and a private key. The private key can be stored in the user's private key repository 308. The system can obtain the public key from the key repository, and store the public key in a public key repository 310. Once the two keys are protected in their respective databases, the procedure can end 312. In some embodiments, users may have pre-configured access to a key repository and use a pre-existing key repository in conjunction with the system as described herein.

In some embodiments, a party can track one or more keys at a time. The key location 400 (FIG. 4) can be used, so a party can have the right to use its own private key 404, and the system can use the party's public key 402. Each user can have a key repository, and the key repository has 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 occur in the system service provider network. When the system decrypts the encrypted data encryption key (DEK), the system sends the encrypted DEK to the key storage area network via a secure network connection 410. The key storage area can then use the user's private key 404 to decrypt the encrypted DEK 406 to generate a decrypted DEK in the key storage area network. The key storage area can then again send the decrypted DEK 408 back to the system via a secure network connection 412. The user can use DEK 408 to decrypt the encrypted data related to the specific key.

In some embodiments, each data attribute encryption key can 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 case that a specific user can have a role that allows the user to see multiple data attributes in each reservation record, the above procedure can be repeated for each field accessed by the user. The use of this encryption and decryption process occurs in the communication between the various systems, and may be invisible to those who access the database information.

In some embodiments, a user can 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. The client application 502 can provide organization authentication to authorized users and can send a login request to an authorization token generator 506 via a secure network connection 504. The client application 502 can provide authentication information (for example, user name and password and any other authentication information). For example, the authentication information may be an API subscription ID and secret (for example, 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 these items can be authenticated, the token generator 506 can generate a token that can be returned to the user. The user's client application 502 can then use the token to communicate with the reservation API 508 via the secure network connection 504. The user can gain access to the booking API 508 to enter and/or access data.

In some embodiments, the client application 502 can be a web-based portal and part of the authorization token generator 506 or the subscription API 508. In some embodiments, the client application 502 can be the client's own software, and the authorization token generator 506 and the subscription API 508 can be debugged to communicate with the client software. In some embodiments, the authorization token generator 506 and the 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 reservation API 508, or the client application 502 may have to authorize itself at each work stage The 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 management program, as shown in FIG. 6. In some embodiments, the handshake of the API interface 600 is shown. The API interface 600 can use a client application 602, an API management tool 604, and a blockchain API 606. A client application 602 may be an application created by the client (user) or an application specifically created to work with the API management tool 604. The user can log in to the client application 602 and submit a request (for example, create a reservation request), and the client application 602 can send a verification request 608 (in some embodiments, it may include an API subscription ID And a secret) sent to the API management tool 604. The verification request 608 can generate a user authentication 616 result, or an error (not shown). If the user authentication 616 is the result, the API management tool 604 can then generate an access token and return the token 610 to the client application 602. The client application 602 can then send the access token and the subscription request payload 612 to the API management tool 604. When the API management tool 604 receives a token and payload 612 request, the API management tool 604 can provide token authentication 618. Then, the token can be authenticated, and the token can be resolved into an organization ID based on the mapping between the token and the organization. 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 Figure 6 has three domains. The client application 602 may exist in the client application network. The API management tool 604 may reside in the API management tool network, and the blockchain API 606 may reside in the system service provider network. However, in some embodiments, the API management tool network and the system service provider network can be combined into a single system network. In still other embodiments, more than 3 domains may be used.

In some embodiments, there may be an API management program 700, as shown in FIG. 7. The API management program 700 can provide a user with access to the system of the present invention, and authenticate the user to the system when logging in. A user can start at start block 702, where the user can access the system through an API management program 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 (for example, a pull-down menu, or a set of system options) and the system records it. The subscription ID can be based on a subscription fee (based on a currency payment, a barter exchange), or it can be free. The subscription ID can be issued to regulatory agencies, payment customers, system administrators, or any other parties that need access to the system described in this article. Each user can also have a secret that can be sent to the system with the login request or with each communication with the system. Once the user establishes a secret with the system, the secret can be stored in the API management program 700 or the API management program 700 can be accessed as needed to check user secrets in a database. Additional steps can be taken, or alternative steps can replace subscription IDs and secret challenges, so that any form of acceptable security for a user’s authentication can be used.

The system can check the authentication certificate against its own criteria to verify that the authentication is correct 706. If the authentication fails, an error 714 can be reported and the procedure ends 716. When the 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 token is not valid, an error response 714 can be returned. If the token is valid, the token can be resolved to the organization ID 718 based on the mapping between the token and the organization. The organization ID and payload request can then be forwarded to the blockchain API and the procedure ends 716.

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

In some embodiments, an overview of a process for distributing encrypted data and encrypted data encryption keys is shown in FIG. 8. The process can start at the start block 802, and the system can encrypt 804 the data and the data encryption key, as described in this article. The system can then find, access, or locate the ledger 806 of the sender and various shipping parties by using its organization ID. The system can check to see if the ledger of 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 ledger of all shipping parties is found, the system can continue to send the data and data encryption key to the ledger.

The system can then continue to send the encrypted data and the encrypted data key, and can check to various appropriate ledgers for sending success 808 (reception verification). If the transmission is successful, the procedure can continue to end block 812.

In some embodiments, a user can obtain reservation information through an obtain reservation procedure 900, as shown in FIG. 9. The program can start 902 by searching for one of the latest versions 904 of the system execution. The system can find the latest version 904 of a reservation by using a unique reservation ID in the transportation document database. The record can contain the name of the ledger. The system can search for the latest version (of the reservation) by the unique reservation ID 904. In some embodiments, the system may not find the correct data record. When this happens, the system can generate and return an error 918. If the 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 authority can belong to. 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 the encrypted reservation data and the encrypted data encryption key from the ledger of the reservation 908. The booked ledger can be located by its ledger name. The system can perform a check related 910 step, in which the encrypted reservation data and the encrypted data encryption key can be checked to see if they are the same in the distributed ledger. If not, an error 918 response can be returned and the procedure ends. If the data is indeed related in different distributed ledgers, the program can log in to the key storage area 912, and the key storage area uses the private key of the sender organization to decrypt the data encryption key. If the key storage area cannot decrypt the data, an error 918 response may 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 can then proceed to end block 920.

A sample reservation list 1000 is shown in FIG. Here, each booking created by a shipper using the booking API can be listed and classified based on various search criteria. The reservation sample list 1000 may represent a reservation record database, and the reservation records may be encrypted and stored in a database, as described herein.

Here you can see a database of examples in Table I below. Database name Explain 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 and dynamic access policy list Public key repository One of the user's public keys Key store A list of the user's private keys Transport Document Database A list of shipping documents, such as a reservation request Global user list A list of all users and one of the roles of each member can be presented in various transportation documents Role list principle Define a list of users and roles with access rights.

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

The system can perform a transportation role check 1110 to verify that at least one transportation role is collected, and then for the collected transportation roles, the system can obtain attributes that can 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 parties can be allowed to view. In some embodiments, attributes that the party may not be allowed to view are removed in a filter attribute 1112 check. When 1114 is successful, a success response code can be returned.

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

The creation of a reservation reservation is now shown in Figure 12. Once the reservation payload request is received from a user or organization, the reservation process begins (start block 1202). The system can first check to see if the submitted request contains a reference booking number and the user's organization ID 1204 (check attribute verification). If the user's organization ID and/or reservation number are not in the submitted request, the system can report an error 1234 and the process can end 1236. If there is an organization ID and a reservation number, the system can find a role list 1206 of the reservation by locating the child key. The locator key can be constructed by referring to the reservation number and the user's organization ID. If the role list is not found, the system can report an error 1234 and the procedure can end 1236. If there is a role list, the system can check whether the reserved access policy can be defined 1208. If the access policy is not defined, the system can return an error 1234 and the program can end 1236. If the access principle is defined, the system can check whether the organization ID of the carrier can be the same as the organization ID of the sender for each carrier. If one or more organization IDs can be the same, the system can collect the transportation role 1210 of the transportation party.

The system can then check to see if at least one transportation role can be collected. If the role is not collected, an error 1234 can be returned and the process can end 1236. If at least one role can be identified, the system can check whether the collected transportation roles have access rights to create all the submitted attributes 1212 of the booking data. If the role does not have access rights, an error 1234 can be returned and the process can end 1236. If the access right is correct, the system can generate a unique reservation ID 1214 for one of the reservations. Once the reservation ID is created, the system can generate individual data encryption keys 1216 for each data attribute. These keys can be symmetric keys. After generating the encryption key, the system can encrypt 1218 each data attribute with its data encryption key. In some embodiments, there may be a data encryption key (a 1:1 relationship) for each data attribute that is encrypted. The system can then retrieve the transportation role information of each transportation party, and also retrieve the access control policy 1220 of each transportation role. If a transporter has an access control principle, 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 keys one by one with the transporter's public key. The system can then distribute the encrypted data and the encrypted data encryption key to the appropriate organization 1226. The system can verify that the data and keys are successfully distributed to all ledgers 1228 of the relevant shipping party. In some embodiments, the ledger may return a response indicating whether the encrypted data and the encrypted data key were successfully distributed. If the system cannot verify the proper distribution, the system can generate an error code 1234 and the program can stop 1236. If the system does verify the encrypted data and the distribution of the encrypted data encryption key, the system can store the name of the ledger, the unique reservation ID, and the reservation version number in the transport document database 1230. The system can then generate a success response code 1232 and the process can end 1236.

In some embodiments, one of the systems 1300 transport document control hub 1302 can be seen in FIG. 13. In some embodiments, the transportation 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 has a blockchain node (1 to N). Block chain logic 1 1320 and block chain node 1 1322 can be part of the transportation document control center 1302. The transportation document control center 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 can be assigned to a carrier organization, and a second user node 1306b can be assigned to another carrier organization. Each user (such as a ship operator, a terminal operator, a consignee, a shipper, etc.) can assign a user node 1306a to 1306n to it. Although three nodes are presented in the diagram of the present invention, it should be understood that this diagram is merely illustrative and is not intended to be limited in any way. The number of nodes that the system can have is unlimited, as specified by the "n" symbol. Each blockchain logic in each node can also communicate with an off-chain database 1304. In some embodiments, user nodes 1306a to 1306n can access the blockchain logic 1320a to 1320n to write encrypted data and an encrypted data encryption key (DEK) to one or more blockchain nodes 1322a To 1322n. The cryptographic access layers 1314a-1314n can communicate with the blockchain logic 1320a-1320n through a network communication 1318a-1318n. Any data sent between the password access layers 1314a-1314n and the blockchain logic 1320a-1320n can be encrypted. The cryptographic access layers 1314a to 1314n can perform various decryption and encryption functions based on an access principle. The cryptographic access layers 1314a to 1314n can generate symmetric data encryption keys (DEK), encrypt data by DEK, encrypt DEK by the public key of the transporter, and access a key storage area 1312a to 1312n to store the DEK Decrypt. API interfaces 1316a to 1316n, password access layers 1314a to 1314n, and key storage areas 1312a to 1312n may exist in an isolated network or user node 1306a to 1306n that may be inaccessible without permission. The client applications 1308a to 1308n can be connected to an API interface 1316a to 1316n to write to a blockchain node 1322a to 1322n, or obtain data from the blockchain node 1322a to 1322n. The client application programs 1308a to 1308n may be a computer, a server, or any computing device with a processor, which accesses a memory device and accesses a network connection to communicate with the blockchain API 1316a to 1316n. In some embodiments, the network connection can be secure. The blockchain APIs 1316a to 1316n can pass a request from the client applications 1308a to 1308n to the password access layers 1314a to 1314n. The client applications 1308a to 1308n may also have a client application database 1310a to 1310n. The data in the client application database 1310a to 1310n may be in plain text form. The client application programs 1308a to 1308n can be searched directly in the client application database 1310a to 1310n. Users can access client applications 1308a to 1308n and then user nodes 1306a to 1306n and then blockchain logic 1320a to 1320n through their own network connections 1318a to 1318n.

The explanation provided for the user node 1306 can be operated in a similar or identical manner to the explanation provided for the user node 1324. In some embodiments, the block chain node component described may be a distributed ledger. In some embodiments, the blockchain node component can be a super ledger.

In some embodiments, an access control principle can be used to determine the distribution of transport documents, as shown in FIG. 14. In some embodiments, each party can provide a transportation document from a user node to a transportation document control center. For example, both have an instance carrier and an instance shipper that both have user-end nodes to transmit a transportation document to a transportation document control center. Each user node can have or can access an API interface, a password access layer, and a key storage area. In the example shown, the carrier can send the transport document role list to the transport document control center, and the shipper can send the transport document to the transport document control center. The transport document role list and transport documents can be encrypted.

The transportation document hub may have an access control principle (access principle) that has a static part and/or a dynamic part, as shown in FIG. 14. The static part may include a list of global members and a list of access policy documents. The global member 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 cargo transportation. Some examples include, but are not limited to; a bill of lading, a terminal loading or unloading manifest, a booking contract, a pre-booking contract, and so on. The access policy may have an access policy file corresponding to each transport file type. The relationship between the access policy document and the transport document type can be 1:1, or it can be 2+:1, or it can be 1:2+. These various relationships and search characteristics can generally be static. In some embodiments, the relationship between the access policy document and the transport document type can be updated and/or modified.

In some embodiments, each of the list, data structure, database, and policy 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 can exist as a user or system update or change any of the items stored in the memory or stored in the blockchain. In some embodiments, the dynamic version may only exist in temporary memory. In some embodiments, the dynamic version can be written to persistent memory or the blockchain.

In some embodiments, there may be a dynamic part of the access principle. The access policy may have a list of dynamic role lists. In some embodiments, the dynamic role list may have a locator key corresponding to one of the locatable access principles. In some embodiments, a locator key can locate a role list or a transport document. The transport document may or may not be part of the access policy. The dynamic carrier can be used to construct a list of roles from one or more shipping documents. The dynamic access policy list can provide each transport document with one related to a specific access policy. In some embodiments, a list of roles in dynamic operations can be generated and submitted together with the transport document. The list of roles can be assigned to a dynamic version of the static access policy document (to create a dynamic and static access Policy document), and the dynamic access policy can be assigned to that transportation document. In some embodiments, there may be a dynamic access principle, as long as there is a transportation document, and the dynamic access principle controls the distribution of the transportation document and all documents related to that specific transportation number.

In some embodiments, a carrier sends a reservation request to the transportation document control center. The shipper instance may be similar to the carrier instance, but the list of roles used for the distribution of the shipper's transportation documents may be a list of existing roles in the transportation document control center. When the carrier submits the transportation document and the list of roles, the carrier can pre-create the existing role list in the transportation document control center. The request can be sent to each member based on the list of roles. The document control center can notify each user of the reservation request (or other documents). For example, a ship operator can be notified that its ship will deliver a designated container, a terminal operator can be notified that it will receive a ship carrying containers, 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 the notification. In some embodiments, each user may provide a response (either manually or automatically) to the receipt of the reservation request. The response document is returned to the transportation document control center 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 the 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 global member (user) list can be a list of all users of the system and one of the roles that each user can use in various transportation transactions and documents. These roles may correspond to their roles (for example, shipper, carrier, ship operator, terminal operator, etc.) used in shared transportation documents. The access policy may also have a list of access policy documents, and each access policy document is applicable to a transport document type (such as dangerous goods (DG) certificates, bills of lading, container entry events, container exit events, etc.). The access policy can also have a list of role lists, and each role list is related to any transport document with the same location subkey (for example, carrier + booking (BKG) number). The access policy may also have a list of dynamic access policies, and each dynamic access policy is related to any transport document with the same location subkey and transport document type. The dynamic access principle can define which specific party can create, update, read, and/or receive the shared transportation document and can create, update, and/or read the attribute level. The dynamic access policy can be derived from a role list of a given locator key and/or an access policy file of a given shared transport file type.

When a user logs in to the user node to access the transportation document control center, the user can be identified by his login authentication. The user's client application can send a transport document role list to the transport document control center. The transport document user node can identify the role list type according to the transport document role list. The transport document client can obtain any one or more of the following information from the access policy from the transport document control center: -The role of the user from the global user list (or global member list). -Access policy document of role list type -One shared access policy document for each shared transport document type, and -A list of dynamic access policies, where the dynamic access policy is unique to a transport document, and the dynamic access policy defines the access rights of each role to a transport document. -Any other information linked to the access policy, user ID or user role.

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

The verified transport document role list can be encrypted and submitted to the transport document control center, and it can be added to the access policy of a specific location subkey.

In some embodiments, the client application can send a transportation document to the transportation document user node. The user node can identify the document type and locate the sub-key according to the transportation document. The transport document user node can obtain the following information from the access policy from the transport document control center:- -Dynamic access policy of transportation document (at the document center, after the request of the transportation document user node, the role list of the given location subkey and the access policy document of the given transportation document type are derived from the dynamic access control principle) -Access policy documents for transport document types -Any other information that the user can access or have authority to.

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

In some embodiments, the verified shipping document may be encrypted and submitted to the shipping document control center.

For example, a carrier may submit an encrypted role list and an encrypted shared transportation document to the transportation document control center. The carrier (or other user) can first send the role list to bind the role list to one of the transportation documents' reservation number or other document ID for identification. Another option is that the transport file can be sent along with the role list (or after the role list), and the transport file can be related to the role list with the help of a locator key. The role list can be read, and the role list can include a list of one of the roles that the carrier will notify. The role list may also have a digital signature of the initiator (sender), thereby allowing the role list to be related to the initiator. The transport document may contain information (quantity, delivery, schedule, etc.) indicating the terms of the proposed contract. These terms can be individually encrypted as data attributes. The role list can be associated with the name of a specific shipping party.

You can copy the role list from the transport document and add the role list to one of the access policies unique to the transport 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 can provide the identification codes of the members who can receive the information originally provided in the shipping document. Each transporter on the role list can obtain appropriate information for its specific role (function) from the transport document.

The data attributes of the transport document can be encrypted one by one by separating the symmetric key. The symmetric keys can be encrypted one by one with the help of the public key corresponding to each transport party that can have a role in the transport document. The role of each shipping party can be defined by the role list. Then the symmetric key of the data attribute can be divided to each user (transporter) who needs or request the data attribute, and the public key of the party can be used to transfer the symmetric key of each data attribute to the appropriate transporter Key encryption. The encrypted data attribute, the encrypted data encryption key, the hash of the encrypted data attribute, and the digital signature of the file originator can then be sent to the carrier.

In some embodiments, the transport document client can send the encrypted shared 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 Hub. The transportation document control center can use the locator key of the transportation document to find the role list in the access policy. Based on the role list, the transportation document control center can find the recipient list. In some embodiments, the transportation document control center may have access rights to decrypt the role list to obtain the recipient list. In some embodiments, the user node can provide the public key of the transporter in the role list and the transport document control center can look up the recipient list based on the public key. In some embodiments, the user node can provide the plain text of the recipient list together with the transportation document to the transportation document control center. The recipient list can be the parties (users) in the role list. The transportation document control center can then distribute the encrypted transportation document data attributes, the encrypted data encryption key, the hash of the encrypted data attributes, and the digital signature of the document initiator to write to the corresponding blockchain node according to the recipient list. The transportation document control center can check whether the documents, keys, hashes, and signatures are successfully written to the blockchain node. If the file, key, hash, and signature are successfully written, the transportation document control center can post an event that notifies the initiator that the transaction is successful to the initiator's message broker center. The transportation document control center can also publish events with the encrypted transportation document, the encrypted data encryption key and the digital signature of the document initiator to the recipient list.

The access policy contains information about each shipping party (user) that can be involved in a specific shipping document. The role list of the access policy can provide the identification code of the user who will receive the data originally provided in the shipping document. Each user on the role list can obtain 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 symmetric key generated at runtime called a data encryption key (DEK). The DEK can be encrypted one by one by means of a public key corresponding to each user who can have a role in the transport document and can have access to the corresponding attribute. 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 the access policy. The encrypted data attributes, the encrypted DEK, the hash of the encrypted data attributes, and the digital signature of the file originator can then be sent to the appropriate members.

In some embodiments, a user can submit a status update to the transportation document control center. This status update provides information, such as receiving and unloading a container with the shipping document identification code 12345, and someone may have to pick it up. No role list can be found in the dock status update of transport document 12345. Therefore, in addition to sending the status update to the transportation document control center, the update can also be buffered in the user node. The other party can then send the role list to the user node, and this role list can have the same transport document ID (12345). The user node can continue to process terminal status updates. The user node can obtain the following information from the access policy from the transportation document control center: -Dynamic access policy for terminal status update (Dynamic access control policy can be derived from the role list of a given locator key and the access policy file for a given type of transportation status update) -Access policy document for the update type of transportation status The user node can identify the role played by the user based on the dynamic access principle. The user nodes can verify whether their roles are allowed to create a transportation update status against the access policy document. The user nodes can also verify whether their roles can create their data attributes of the transportation update status. This verified shipping status update can be encrypted and submitted to the shipping document control center.

In some embodiments, the user node can receive various documents from the transportation document control center based on the user's access policy: the dynamic access policy of the terminal status (the dynamic access control principle can be assigned to the role of the subkey List and export the access policy file of the given transportation status update type), and the access policy file of the transportation status update type. The transport document user node can also identify the role played by the user based on the dynamic access principle. The transportation document user node can verify whether their roles are allowed to create a transportation update status against the access policy document. The transportation document user nodes can also verify whether their roles can create their data attributes of the transportation update status. After verification, the verified transport state can be updated and encrypted. The encrypted transportation status update, the encrypted data encryption key, the hash of the encrypted data, and the user's digital signature can be submitted to the transportation document control center together with a recipient list.

Now an example method of operation set forth.

In an example of a transportation 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 Number: 5

In this example, the transportation route is XYZ, and the transportation route 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 transport documents for transportation.

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 toys from China to the USA. The carrier then provides the above transportation order to the user node in plain text through a secure transmission. The user node then encrypts the data attributes while leaving a header field separately. Each data attribute is encrypted and has a separate data encryption key.

Table III Header field Data attribute Shipper Encryption ("Factory A", k1 key)* Receiver Encryption ("S-Mart", k2 key)* Last pier Encryption ("Long Beach, CA", k3 key)* Ship operator Encryption ("SS Shipper", k4 key)* Carrier Encryption ("XYZ", k5 key)* *The information provided in the encrypted field does not represent the actual encrypted information. The text string is only illustrative. "Encryption ("Factory A", k1 key)" means that the text value "Factory A" is encrypted by "k1 key"

The encrypted data can be recorded in the blockchain node, 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 the access policy. In this example, shipper factory A may have access to all data attributes. The public key of factory A can then be used to encrypt all keys (k1, k2, k3, k4, and k5). All transport files can be encrypted separately. It is also possible to encrypt the keys individually (serially or in parallel). The key 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 when the key cannot decrypt any other transport documents The specific transport document corresponding to the key).

The right of each transportation role to read, create or update the data attributes of the transportation document can depend on the access rights defined by the system. In this example situation, 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 transportation roles (such as shipper, consignee, final terminal, ship operator, carrier, etc.). D1 to D5 are data attributes encrypted by (k1 to k5). R is "read", "U" is "update" and "C" is "create". If the consignee has access to D1 and D5 ("read", "update" or "create"), k1 and k5 will be encrypted with the consignee's public key.

[PC1] The public key of Shipper Factory A can be used to encrypt all keys (k1, k2, k3, k4 and k5). The public key used by the terminal operator (the Long Beach terminal in the port of USA) can be used to encrypt k2 and k3. The public key used for the ship operator (the SS freight forwarder of transportation) can be used to encrypt k2 and k4, and finally, the public key used for the carrier XYZ can be used to encrypt all keys (k1, k2, k3, k4) And k5) encryption. The ship operator does not need to know any information about the shipper. The information about the shipper may be invisible to the ship operator and can be used for the ship operator's data attribute key set may not include the key for the shipper’s data attribute.

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

In a more general form, the process for generating appropriate keys for accessing various data attributes with different owners may involve generating keys and making them match the assigned roles and access of a user One program 1500 of principle matching is shown in FIG. 15. After the start block 1502, the program can generate a data encryption key 1504 for each data attribute. In some embodiments, the keys can be symmetric keys. An encryption key can be formed for each data attribute. The system can capture the transportation role 1506 of each transportation party. As explained in this article, each party can have a transportation 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 can be a party to a single transportation transaction, but a user does not have to be a party to a single transportation transaction). In some embodiments, a single user may have a transportation role. In some embodiments, a single user may have two or more transportation roles. In some embodiments, a user can access the system without having a formal transportation role, as described in this article. The program can capture access control principles 1508 for each transport role. Access control policies can provide information to inform the process of what data attributes each transporter can access. The program can then provide public keys and access control principles 1510 for the transporter. Here, each transportation party with access control principle can also have a public key stored in a public key repository. The program correlates the role of the transporter with the access control policy to see which data attributes the transporter can access. The program can then retrieve the appropriate public key of the shipping party. The program can then encrypt 1512 the corresponding data encryption key with the public key of the transporter. The data encryption key can be encrypted one by one in a serial manner. In some embodiments, data encryption key encryption can be performed in parallel. In still other embodiments, the data encryption key can be encrypted in one batch. Each data encryption key can be encrypted so that each key encryption key corresponds to one or more data encryption keys, and each one-to-many relationship between the key encryption key and the encrypted data key corresponds to a Single profile attribute. It can be viewed as a one-to-many or one-to-one relationship (1:m and 1:1). Once the program is completed, the program can end 1514.

In some embodiments, a party may be added to the role list or access policy, but the other party may not have an actual role in the transportation. In some embodiments, a non-transportation party may be a financial institution. In some embodiments, the non-transportation party may be a regulatory or government agency. In some embodiments, the non-transport role party may be an insurance company, a guarantor, a judicial authority, a trade supervisor, a labor organization, or may be directed to one of the documents and access principles of the system described in this article. Or any other entity that accesses or checks data in at least one data field of other databases.

Figure 16 provides another example of a procedure for encrypting data attributes based on roles and access control principles. In this example 1600, five roles are presented in the form of a shipper, a consignee, a terminal, a ship operator, and a carrier. In some embodiments, there may be one party per role. In some embodiments, there may be one party with more than one role. In still other embodiments, two or more parties may share a single role. For the example shown 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 to D5) as shown. Each data attribute can be individually encrypted 1606 (k1 to k5) with a data encryption key. Each data attribute can also have a header and data attribute field. As shown in the sample access control principle 1604, each role (shipper, consignee, etc.) has access control defined for the header 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 access principles for the role (the party on the left row of the matching column). For example, according to the access control principle, the shipper has "R" access. The shipper can "read" the data attributes corresponding to D1 to D5. However, the shipper cannot update or modify the information, and the shipper cannot create any information. On the other hand, according to the sample access control principle in Fig. 16, the carrier can have the authority to create (C), read (R) and update (U). Other parties (such as the consignee) can only read the data for H1 and H5 corresponding to D1 and D5. Finally, the terminal can only read 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 used for each party that has a role match in the access control policy. In this example, the shipper has a public key (S _pub ) that can be used to individually encrypt each data encryption key k1 to k5, as shown in the public key encryption 1608 table of data encryption key. The shipper column in the 1604 table means that the shipper will access to read the data attributes D1 to D5, but will not be able to create, delete or update these 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 accessed by the consignee according to the consignee’s access control principle 1604) (Co _pub ). The public key of the consignee is used to encrypt k1 and k5. The encrypted k1 and k5 can be called a DEK, and the consignee can have DEK 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 can be the same for the final terminal, ship operator and 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.

FIG. 17 illustrates an embodiment 1700 that includes a transport document with a unique ID 1706 and a role list 1710. The access principle 1702 may be role-based. It can have two levels. A level can be used to create, update, logically delete, and read a file object level for each role of the transport file 1706. It can also provide an attribute level that permits the creation, update, and reading of the transport file 1706. The role list access principle 1704 may be role-based. It can also have two levels. One level can be used for each role creation, update, logical deletion, and reading of a role list object level in a role list 1710. It may also have a role attribute level of the allowed role list 1710 to create, update, and read. In some embodiments, a transport document 1706 can be assigned a role list. The role list 1710 plus the transportation document access policy 1702 can provide each user who is a party to the transportation document privileges. In some embodiments, each transport document may have its own role list and its own access policy. Each user can have a defined role in the scrolling list and access defined in one of the access policies. The intersection between the role of each user and the access of each user can define the privileges of that user. A list of roles can be applied to many different shipping documents. For example, a transport role list can be applied to a DG voucher, a bill of lading, a terminal loading or unloading event, or any other form of transport document 1706. These different forms of transportation documents can also be referred to as document type 1714 and event type 1716. The document type 1714 and the event type 1716 can define a group of supported types of transportation documents 1706. In some embodiments, the shipping document 1706 of the document type 1714 is versioned. In some embodiments, each time a file is edited or modified, the version number of a file may increase incrementally. It can be used to support multiple versions of the same original shipping document. Each shipping document 1706 can have a unique ID. There may also be many types of character lists 1710. The transport role list 1718 and the container role list 1720 are some of the possible types of role list 1710. The transportation file 1706 and the role list 1710 can use the location sub-key 1708 and the location sub-key 1712 respectively. In some embodiments, the positioning sub-key 1708 and the positioning sub-key 1712 may not be encrypted. The positioning sub-key 1708 and the positioning sub-key 1712 can be visible to the transportation document control center and can be used to support its (central) function. The locator key can allow a key-based lookup (such as a shipping number) to identify the related role list 1710 and related shipping documents 1706. The transport document 1706 can recognize the access principle 1702 by its type.

Figure 18 illustrates some example role lists and role list principles. In some embodiments, a role list access policy locating sub-key 1802 can provide example headers of "role list type" and "locating sub-key field". Below the "Role List Type" is the "Transport Role List" and the carrier and booking number are below the locating subkey field. This illustration shows that the locator key field of the transport role list is the carrier and reservation number. A role list access principle instance 1804 can display the types 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 transport role list indicates that the carrier has the authority and system privileges to create a role list. In this example, none of the other roles can create a role list. The next table shows an example of a role attribute hierarchy 1806. Here, the "role list type" is displayed in the "transport role list" in the first row and the "role attribute" in the second row. Now list individual roles from the role list access policy instance 1804 in the role attribute row. The remaining part of the table shows the "role" to "role attribute" access privileges for creating, reading or updating (modifying) a role attribute of a role list transport file. The thick frame shows the second and third lines, and indicates that the shipper can read all the roles in the transportation role list, but the shipper cannot create or update any role attributes in the transportation role list. The role list example has the role list locating subkey 1808 and the role list content 1810. The role list locator subkey 1808 illustrates a carrier XYZ and a reservation number 123456. The transport role list may include the role list content 1810, and the role list content 1810 may illustrate the identification codes of each user in their roles (for illustration purposes only, these identification codes are virtual).

Several example shipping documents 1900 are now shown. The documents may illustrate business-related headers, but only use virtual data for illustration purposes, as shown in FIG. 19. In some embodiments, there may be a transport document (from a terminal operator) of a container exit event 1902. The example table displays the event ID (the unique identifier of the transport document), the carrier and the reservation number (the positioning of the list of allowed roles for the carrier and the reservation number), and information about the intermodal container at the terminal. This information can be sent to the transportation document control center and redistributed to other users identified on the role list, so this specific exit event can be notified to each user at the same time. The transportation document access policy can have three parts-"role list locator" key 1904, "transport document access policy" 1906, and "departure event field-level transportation document access policy" 1910. Role list location subkey 1904 (an example in Figure 17, 1708) indicates: 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 the carrier XYZ And the reservation number 12345 is extracted from the outbound instance 1902. Transport document hierarchy principle example 1906 indicates: for an outbound event, the five roles displayed can read the transport document type "Outbound Event" transport documents, but only the role of the terminal operator (the initiator of this event) can be created or updated Transport documents. In some embodiments, a role such as a terminal operator can also perform a logical deletion of transport files.

In some embodiments, the transport document architecture instance 1908 can illustrate the name of a field in the left row ("header field") and the data attribute type in the right row. The sample data attributes can be of any length, and the length of the displayed string is only illustrative. As illustrated in this example 1908, the event ID is the unique ID of this transportation document type; and the carrier and booking number fields are the role list positioning subkeys of this transportation document type. The transportation document principle field level example 1910 provides a graphical description of the transportation document type (in this example, an outbound event) and a column row, which displays various header fields from the architecture example 1908 and the outbound event example 1902 . The column list in the 3rd to 7th (third to seventh) rows of the column level instance 1910 shows which role has what rights for each column. All roles of a single transaction can read the data, and the carrier and terminal operator can update (modify) the data. Since the outbound event of transportation documents originates from one of the assets of the terminal operator, only the terminal operator can create this type of transportation document.

In some embodiments, the systems and methods described herein can be used with dangerous goods (DG), as seen in Figure 20. Dangerous goods may require a special transport certificate, which is referred to herein as a dangerous goods certificate (DG Cert). Dangerous goods in the transported goods appear when the transported materials can be dangerous or have a quantity that can cause danger to them involved in the transport procedure. Examples of dangerous goods may include fuels, radioactive materials, corrosive chemicals and liquids, explosives, and so on. In some embodiments 2000, a DG cert instance 2002 is shown as a transport document. The header field represents the left row and provides information categories. The data attributes in the right row show the corresponding data for each category. The role list locator sub-information can indicate the carrier and reservation number. Can also list the product description. The role list location sub-information can be used to access the DG cert role list instance. The DG cert role list instance can be composed of the transport document access policy role list location subkey 2004, the document level access policy 2006 and the field level access policy 2008 . Role list locating sub-key 2004 instruction: For each outbound event, there can be a transport role list, "role list type" and a carrier and reservation number are used as "locating sub-key fields". Document Level Access Principle 2006 illustrates a table showing the access principles of the transport document type "DG Cert" at the document level. Show the instance parties associated with the transportation of dangerous goods and their respective read (R), create (C), update (U) and delete (D) authorities. The DG cert framework instance 2010 provides the header and data attribute type of the DG certificate (transportation document) for the current instance. "Example of DG Cert's Transportation Document Access Principle-Field Level (a field can refer to a data entry field in a document)" 2008 provides information about the type of transportation document (DG Cert), from the DG cert instance 2002 and DG The fields obtained in the cert framework instance 2010, and display the individual rights of each party (user).

In an example, an illustration of one of the logic 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 transportation document control hub 2102 and a first user node 2104. The transportation document control center may have a computer including a logic, a memory and a communication device. A document control central side message agent 2106 can be operated by 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 can be stored on the memory. There may also be a public key repository 2114 and an ID repository 2116 on the memory. The memory can be one or more physical devices and it does not need to be physically contained in the computer. As long as the computer can access the various databases described, physical memory can be distributed in a physical sense. The ID repository 2116 may have one or more users, one or more user login credentials, and a list of one or more user parameters. The memory can be a blockchain node used to store one or more of the access principles of the encrypted transport document. The first user node 2104 may have a computer with a logic, a memory and a communication device. Similar to the transportation document control center, the client (user) nodes 2104, 2118 can have computer memory and can be more than one memory device that can be inside or outside the computer, as long as the computer can access the memory (etc.) Device. A key storage area 2120, 2122 can be a part of the user node, and the key storage area can store a login ID secret and a user's private key. The key storage area can be accessed 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 storage area and a user message broker 2124, 2126. The user node may have an portal site for a user to access the transportation document control center, where the API interface can be executed logically and communicate with the transportation document control center message agent.

In some embodiments, the communication between the user node and the transportation document control center can be handled by the message broker. The system can use a secure network communication between each node and the transportation document control center (central). These message brokers can provide secure network communications for nodes and hubs to transfer information to each other. The application programming interface (API) of the user node can be a computer-implemented program that provides an access layer for the password exchange between the key storage area and the message broker. The access layer can be implemented on a computer logic or processor. The client application can be any interface for a user to access the API interface and the message broker. The client application can be proprietary software or can be ready-made software. The message agent of each node can access the blockchain logic in the hub, and the encrypted transport file 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, because there can be one blockchain database for each transport document type.

In some embodiments, a sample flowchart 2200 of a role list submission can be seen in FIG. 22. In some embodiments, when a role list is submitted, the role list may have an initial check attribute verification 2202. In this step, the program checks whether the location subkey (such as the reservation number and the sender's organization ID (SCAC code)) and the role list (the role list also includes the role list type) can be included 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 the role list access policy 2208 is defined. This step involves checking the role list access policy of that role list type. The program can then check an access right check 2210 to find the role of the sender’s organization using the ID repository and check whether the sender’s role has access rights (the role list level and a data field in a role list, there is In this article, it is called a "role list field level") to create a role list and create the roles in the role list. If at any point the procedure fails to produce a useful result, the procedure can end and an error response code 2212 can be returned and then terminated (end 2234). If all the steps are successful, the process can generate encryption keys 2214 for all roles in the role list. Using these encryption keys, the program can encrypt 2216 the role list. The process can generate a hash by encrypting the role list and access the key storage area to sign the hash with the sender's private key to generate the sender's signature 2218. The program can obtain the public key 2220 for each party on the role list, and encrypt the data encryption key 2222 with the party's public key according to the access control principle of each party. The process can package the message by using the encrypted role list, the encrypted data encryption key (associated with the public key of the party), hash and the sender's signature. The program can use the user's private key to digitally sign the message to generate the user's signature. The message can be sent to the transportation document control center 2223. The process can then distribute the data and encryption key 2224 by finding the blockchain node of the party and distributing the encrypted role list and the encrypted data encryption key to each blockchain node. The program can then check for successful distribution by checking whether the encrypted data, encrypted data encryption key, hash, and sender's signature were successfully distributed 2226. The program can then publish events with a success code of 2232 to the message broker, or publish events with an error code to the message broker 2228.

In some embodiments, the client application can create a role list and communicate with the transportation document control center via the client-side message broker and user nodes. The password access layer in the user node can obtain the public key and access control principles from the hub. The access layer can then verify and enforce access control principles, encrypt a payload (role list) and place the message to the message broker. The message agent (on the client side) can communicate with the message agent of the transportation document control center, and the message agent on the transportation document control center side obtains the message to the program to distribute the encrypted data and the encrypted data key, and Then an event 2232 with a success code that can go to one of the message agents on the client side can be issued. The client side can respond to the success message and confirm receipt, and can create a transaction completion response.

In some embodiments, there may be a program 2300 for reading a transport file, as shown in FIG. 23. The program can start with a given document ID (such as DG Cert ID) (in some embodiments, a version number can be given), shipping number, sender’s organization ID (such as SCAC (Standard Carrier Letter) Code)) and a specific role list type begins. It continues to check the attribute verification 2302. In this step, the program can check whether the location subkey (transportation number, sender's organization ID), document ID, and role list type are valid. If so, the program uses the locator key of the role list and the role list type (not shown) to obtain the encrypted role list and the encrypted data encryption key 2304 from the sender's node. If the role list cannot be found, the process can return an error response code 2316 and can then proceed to the end block 2322. If the role list can be found, the program can check the relevance of the role list 2310. The program can check to see if the role list data in all blockchain nodes match each other. If the role list data in any blockchain node does not match with other blockchain nodes, the procedure may return an error response code 2316 and then proceed to the end block 2322. If the role list data is the same in all blockchain nodes, the program can access the key storage area 2312 to decrypt 2314 the data encryption key. If the data encryption key cannot be decrypted, the process can return an error response code 2316 and can then proceed to the 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 can then return a success response code 2320, or alternatively, if the program fails, the program can return an error response code 2316. The process can then proceed to end block 2322.

Now a flow chart is shown in FIG. 24, which shows a shipping document creation 2400. In some embodiments, the program can check whether the locator subkey (such as the reservation number and the sender’s organization ID) and the content of the transport document (such as DG cert) and the type of the transport document can be checked in the request to verify the attribute 2402 . The program can check whether there can be an existing role list 2404 from one of the access policy repository. This step may involve checking whether the access policy repository has an applicable role list type, and then checking an existing role list of 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 the transport document field level. The program can perform an access right check 2410 to find the role of the sender’s organization in the ID repository, and can check whether the sender’s role has the correct access rights (transport file level and field level) to create that type of A transport document (such as DG cert), and create information in it. The program can then generate a unique transport document ID 2412 (eg, DG cert ID) that can be unique throughout the system. The program can generate a data encryption key 2414 for all data attributes in the transport document. The data encryption key can then be used to encrypt 2416 the data attributes in the transport file (eg DG cert). The program can generate a hash about an attribute of the encrypted data and access the key storage area to generate the sender's signature 2418 by signing the hash with the sender's private key. Then, a public key 2420 can be obtained for each party identified in the role in the transport document. The data encryption key can be encrypted 2422 with an appropriate public key for each party identified by a role in the transport document. The program can package 2424 messages with encrypted data attributes, encrypted data encryption keys, hashes, and sender's signature. The program can send 2426 messages to the transportation document control center. The transportation document control center can distribute encrypted data, keys, hashes, and the sender’s signature in the following ways: find the blockchain node of the appropriate party; and encrypt the encrypted transportation document and encrypted data. The key (DEK), hash and sender's signature are distributed to the blockchain nodes. The program can check to see if the distribution is successful 2428 by making each user node respond with a success notification. Alternatively, the program can distribute the message and record the distribution as successful unless an error message is received from one or more recipients. A successful event notification can be posted to the sender 2432. The role list recipient can receive one of the publishing events 2430 with the encrypted transport file, the encrypted DEK, the hash, and the sender's signature. The release of the event to any recipient may depend on whether the recipient agrees to the update event of a specific transport document type (for example, "created DG cert"). The recipient user node can check the integrity 2436 by calculating the hash from the encrypted transport document; and decrypting the sender's signature by using the sender's public key to obtain the decrypted hash. The program can compare the decrypted hash with the hash from the encrypted transport document. The recipient node can then access the key storage area to decrypt 2438 the encrypted data encryption key and decrypt 2440 the transport document with the data decryption key. The client application can receive the shipping document 2442 in plain text. The process can then proceed to end block 2448.

2500 now shows a flow chart of a transportation update file in Figure 25. The process can continue from start block 2502 by verifying whether the shipping document ID/location subkey (such as the booking number and the carrier’s organization ID (SCAC code)) and the updated shipping document (such as DG Cert) can be included in the request Come to check attribute 2504. The program can check an existing shipping document 2506. This can be determined from the blockchain ledger by searching for the shipping document ID and/or locating the sub-key and the shipping document type. A check can be made to see if the list of existing roles 2508 can be found. The process can find the role list from the access policy repository by searching with one or more locating subkeys and/or one or more role list types. A role check 2510 can be performed to determine whether the sender's organization ID can be one of the parties on the role list. The program can check to see if the access policy 2512 is defined. The principle of program accessibility is to obtain transportation documents from part or the entire document by supplying "transport document type" (for example, transportation document type="DG Cert"). An access right check 2514 can be performed to determine whether the role of the sender has access right (field level) to update the data value in the transportation document. The program can merge the encrypted data (if available) 2516 of the attributes of the existing transport document and the attributes of the submitted data. The program can increase the version number of the transport document by 2518. The program can generate a data encryption key 2520 for the new data attribute 2522 in the submitted transportation document. For example, if there are 10 data fields and 3 data fields affect a user, only the three data fields that affect the user are changed, so only 3 data fields may require a new encryption key . The remaining 7 fields do not have the new key, and only the existing old information is left. The program can encrypt 2524 the attributes of the submitted data in the transport document by using the data encryption key. The program can generate a hash about any newly encrypted data attribute (data field), and access the key storage area to generate the sender's signature 2526 by signing the hash with the sender's private key. The program can obtain the public key 2528 of the party in the role list. The program can encrypt 2530 the updated data encryption key by using the public key of each party and the access control principle of each party (user). The program can package 2532 messages with encrypted data attributes, encrypted data encryption keys, hashes, and sender's signature. The program can send messages to the transportation document control center 2532. The program can distribute the encrypted data and keys by the following methods: find the blockchain ledger of the party; and distribute the encrypted transport document, encrypted data encryption key, hash and sender's signature key To the appropriate blockchain ledger 2534. It can perform a check 2536 whether the encrypted transport file, encrypted data encryption key, hash, and sender's signature are successfully distributed. In the case where a success code is sent to the message agent of the sender, a publishing event 2550 with a success code to the sender can be executed. If it has not been saved to the transaction reference database, the program can alternatively post an event with an error code to be sent to the message broker 2554 of the sender. The program can publish an event with an encrypted transport file, encrypted data encryption key and sender's signature to the intended recipient 2538. The release event to the recipient depends on whether the organization agrees to the shipping document update event (for example, "Updated DG Cert"). The event payload may contain an encrypted transport file, an encrypted DEK, and the sender's signature. The recipient user node can check the integrity 2540 by calculating the hash from the encrypted transport document; and decrypting the sender's signature by using the sender's public key to obtain the decrypted hash. The program can compare the decrypted hash with the hash from the encrypted transport document. If the integrity check 2540 fails, the program can send an error response code back to the recipient 2548. If the integrity check is successful, the recipient node can then access the key storage area to decrypt 2542 the data encryption key, and decrypt the transport document 2544 with the data decryption key. The client application can receive the transportation document 2546 in plain text. The program can then proceed to end block 2556 .

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

The user node can access the key storage area 2612 to decrypt the data encryption key (DEK) and retrieve the data encryption key (DEK) 2614 using the private key of the sender’s organization. The user node can decrypt 2618 the encrypted transport document with the data encryption key and can send a successful response code back 2620 to the client application. If the procedure fails at any point, the procedure can return an error 2616 code 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 transportation document, the user node or the transportation document hub can check the existing role list and/or the existing transportation document data Completeness. The integrity check process starts by calculating the hash based on the encrypted shipping document (or role list) and comparing it with the existing hash 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 calculated hash and the sender's signature verification is successfully verified, it is a valid signature and the integrity of the file is maintained.

Once a user has access to the reservation API, the user can populate a reservation configuration 2700 (example). The reservation configuration 2700 may have multiple fields for data input related to cargo transportation. The field may include, but is not limited to, the identification code of the shipper, consignee, ship operator, forwarder, carrier and booking party (which may be the user). The reservation configuration 2700 can also have route information, container/goods information and other or miscellaneous information as needed. The user who created the reservation can see all the data attributes in the reservation configuration. The additional information that the reservation user may enter into the reservation configuration 2700 may include information that may be confidential to the user. When the reservation configuration 2700 is entered into the system, each field can be processed separately. For example, once a record is created, the shipper in the reservation configuration 2700 can view the record, but the shipper can only see the information related to it (for example, the actual price of the transportation disposal). In another example, the consignee can see information related to it (for example, the location of the air intermodal container returned). The subscription version number 2702 indicates the version that the user is viewing. Generally speaking, users can see the latest version. In some cases, a user can search for records older than the most recent record.

Now as in Figure 28 shows a view of one of the local operator of the ship's 2800 book view a sample screenshot. The screenshot contains the identification code of the carrier, but it can hide the identification code of the booking party, shipper, forwarder and consignee. In addition, there may be information in the route information, part of the container/goods information, or other information fields that are kept hidden from the ship operator's view. In this way, the user (reserving party) making the partial booking view 2800 can fill in all the information related to each other party involved in the transportation of the goods. Transport documents may contain information that each party uses or relies on as part of its transaction, and which makes the booking party not want to share any information hidden. The reservation party can define what fields it wants others to see, who their other parties are, or the reservation party can use a set of standardized protection fields. The system can determine which fields a user can see based on the access control policy of each user's role.

In some embodiments, a party in the access role policy that may not be a user of the system can still obtain access to specific materials in the system by having a permission from one of the users in the access role policy And information access. 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 a subsidiary interest in transportation transactions (such as an insurance company, customs agent, maintenance equipment Or any other party).

In some embodiments, a user can request a third party to access specific data in the system. Another option is that the user can request 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 to verify the statement made by the user. The process can be completed with or without direct actions from the system, and allows confidentiality between users and third-party non-users.

It can be seen in FIG. 29 illustrates a relation of the system, users and non-users of third-party logic. In some embodiments, a registered user 2902 and a user node 2908 can make a request to the document control center 2906 through the user node 2908. In some embodiments, the user can communicate with a third party 2904, and the third party 2904 may not have any access rights to the file control hub 2906, nor is it a user of the system as described herein. For example, a message agent can be configured to send a message to a third party 2904 (a third party non-user), where the message includes encrypted data from the transportation document control center. The encrypted data can be limited to data that a user 2902 (or a corresponding user node 2908) can access according to an access control principle and a user role list. The third party 2904 may be an organization or individual interested in the transportation activities of the user 2902, but is not a party to the transportation agreement. The third party 2904 may be a bank or other lending institution, an insurance company, a broker, a maintenance equipment, a government agency or government actor, or any other party that may be interested in the transportation agreement, and requires access to documents Certain data or files on any of the control hub 2906 or the controlled database supported by the system as described herein.

Specifically, for the purpose of obtaining something from the third party 2904, the user 2902 may communicate documents or information to the third party 2904 parties. This item from a third party 2904 allows users to participate in transportation agreements or conduct business with other users of the system. Examples may be the provision of funds for the transportation agreement, the provision of financial guarantees for one aspect of the agreement, the insurance of commodities or carriers, the inspection of data to verify the contents of the container upon arrival at a port, and so on.

In order to obtain the assistance of the third party 2904, the user 2902 can submit all the documents that the third party 2904 can request to the third party 2904 using the encrypted and secure user-to-third party communication 2912 protocol. The user-to-third party communication 2912 may include the encrypted data and the data encryption key delivered from the user 2902 to the third party 2904, so the third party 2904 can view the data appropriately. 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 the data received from the user 2902. The third-party node 2910 can communicate with one of the verification functions in the file control hub 2906. In some embodiments, the third party 2904 may send the encrypted data to the file control center 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 can send any additional materials provided by the user 2902 to be verified by the document control hub 2906. The document 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, and 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 with that recorded in the file A jumble of shipping documents in the control center 2906. The matching hash may reveal that the information is true, although the document control center 2906 may not actually release any information to the third party 2904. In some embodiments, it may allow the use of key checking for verification and hashing of encrypted keys or any other mechanisms that exist or are derived in the future, which may be suitable for use by the document control center 2906 and the user 2902 system. When the third party 2904 can confirm the authenticity of the data from the user, the third party 2904 can continue its internal operations to provide the user 2902 with anything that the user needs to continue his duties in the transportation agreement.

In some embodiments, the relationship between the document control hub 3002 (DCH) on the system side 3012, the user 3022, and the third party 3060 can be illustrated, as shown in FIG. 30. The DCH 3002 can have a transport document database 3004 _a , and can have other databases, such as an access policy repository 3004 _b , a public key repository 3004 _c , an ID repository 3004 _d or for system operation 3004 _n of any other database. When the user 3022 may need a bank loan, the user 3022 may request specific information and documents from the DCH 3002. It can be compared with ID repository and access policy repository or any other authentication method or request to authenticate the user. The user can be identified in the system 3012 or DCH 3002. The user can have one or more receiver library encryption 3006 _an about the "data encryption key" 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 data package 3006 generated by the system with the help of the encrypted data encryption key, and then the information can be sent to the user 3022.

The data package 3006 may contain encrypted data and the data package 3006 can be sent together with the encrypted data encryption key 3026. The user can 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 materials. In some embodiments, the user's public key may be used to encrypt the data encryption key 3026. The data package 3024 and the data encryption key 3026 can be communicated to the user 3022.

On the user 3022 side, the user private key 3028 can be used to decrypt the encrypted data encryption key 3026. The user can send the data package 3024 and the decrypted data encryption key 3026 to a third party 3060. The user can send the data package 3024 to a 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 communication.

Once the third party 3060 has the encrypted data under 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 a third party node (not shown) DCH 3002. The DCH 3002 can then use the verification function 3010 hosted by the DCH 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 is authentic, due to the hash and other data encryption element matching system 3012 and/or the hash and other data encryption elements of the DCH 3002.

In some embodiments, a user can provide any amount of information to a third party as if it had also accessed it. Generally speaking, a user can only provide that information that is relevant to a third-party request for information. For example, a third-party bank may request financial information, records of completed transportation agreements, and payments from parties downstream from the user. An insurance third party may request the history of the transportation of a particular type of material (such as a dangerous goods), and the history of the user regarding the number of accidents, the number of previous insurance claims, etc. may be related to the request. For example, a government agency can act as a third party and request information about the final destination of a transportation, who the final purchaser can be, or whether the goods will or have passed through the territory of a particular country. The request type can be unlimited. The user can then issue a data request to the system. The system can generate data into the data package 3006. The data package 3006 may contain encrypted data, a hash, a time stamp, and a signature of the sender. Depending on the sender (user) request, the data package 3006 may contain additional materials or less materials.

In some embodiments, the data package 3006 can be encrypted and sent to a user. In some embodiments, the data package 3024 owned by the user may be identical in all aspects to the data package 3006 assembled by the system. However, since the user is currently in control of the data package 3024, the data package 3024 is distinguished from the data package generated by the system 3006. The user 3022 can open the 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, re-encrypt it and send it to a third party. For example, the user 3022 can obtain the data package through a first client 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 data package 3024 of the user. The third party can try to verify the contents of the data package 3062. A third party can use a third party node (or communicate via the 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 the integrity of a data package. In some embodiments, the third-party node may call the verification function 3010 in the DCH, and the DCH may obtain the encrypted data from the transportation document database 3004a or any other database as needed. The verification function 3010 can then send the encrypted data to a 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, a third party can 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 can have the provided Proof that the information is correct and has not been changed from its source.

Exemplary embodiments of third-party functions are now provided in FIGS. 31 to 35. In some embodiments, the first-generation carrier can obtain or need financial support from a bank (a non-party to a transportation 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 activities 3120, and the carrier experiences its own carrier activities 3118. In the process of applying for a loan, the forwarder will provide various documents and information to the bank. This can be regarded as the application verification step 3104. The bank then undergoes its own compliance check 3106 to determine whether the forwarder is a trusted party and a good financial risk. If so, the bank can approve and issue a loan 3110 to the forwarder and provide payment 3108.

The forwarder may experience its activities and perform the transportation event 3112 that it hires to perform, provide the transportation document 3114 to the interested party, and then issue an invoice 3116 for the party signing the contract for the transportation event. Then, after the transportation event is completed, the party signing the contract can pay the forwarder, and the forwarder can repay the loan.

In the procedure in which the forwarder wants to set up a loan account from a bank, the forwarder may involve a system that assists in the use of trusted storage systems to provide data and document verification. For example, the forwarder 3202 can use a secure communication 3204 system to communicate with a bank 3206 or other financial institutions to set up an account 3200, as shown in FIG. 32. The forwarder 3202 can send a loan account application and other supporting documents to the bank via secure communication 3204. These files may contain historical information about past transportation transactions, security records, payment history, etc. The secure communication 3204 can be used to send documents between the forwarder 3202 and the bank 3206. Secure communication can mean encrypting messages and attachments. The secure communication 3204 may also involve security systems, such as VPN, coded communication channels, and so on.

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

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

The bank 3206 can 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 information sent by the bank 3206.

In some embodiments, after the carrier has set up a loan account, the carrier can 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 acceptable Risks, and any money that may be repaid to them. For this example, the forwarder can submit a loan application 3304 to a bank or other lending institution, as shown in FIG. 33. The forwarder can collect the booking confirmation documents from the carrier and the transportation events from the terminal as supporting documents for the loan application 3304. The completion of the transportation event, the fulfillment of Project 3300 or the loan conditions can generate an event that triggers the payment of the loan. For example, the arrival of one of the transport or carrier vehicles at a terminal 3312 and the subsequent unloading of transported goods can trigger the sending of various documents 3314. The transportation event can be reported to the system 3310, and the system can then notify all relevant parties. The carrier 3308 may be notified that the ship has arrived and has been unloaded. The forwarder 3302 can be notified that the goods have arrived at the destination port and the event has been triggered to pay the loan to the bank within a fixed period of time. Banks can also receive verification that the transporter 3302 loan is now due in the transport era. The system 3310 can have various triggers and alarms built into it. Therefore, at each stage of a transportation, it can receive updates on transportation procedures and send alarms to all its related parties.

Now a sample invoice 3400 is shown in Figure 34.

An example payment of 3500 is now shown in Figure 35. In this example, the forwarder can select one or more financing options from many lending institutions that the forwarder may have. The transaction can be handled by the system, as long as each party can receive data from the system and transmit the data to the system.

In some embodiments, when a container is loaded on a terminal, the terminal operator can issue a terminal event notification that informs the carrier to track the transportation milestone. The terminal event notification contains the terminal location, event type, date, time, carrier and container number, etc. Then, the carrier finds the relevant party of this container and informs the party through the encrypted distributed ledger.

The use of independent encryption for each data attribute of a transportation document and the one-to-one relationship between the encryption field and the encryption key allow the creation of any number of businesses involved in a common enterprise (such as intermodal container or project cargo transportation) A single transportation document that arranges all aspects of a goods reservation without revealing any confidential information to any other party participating in the reservation or most of the public.

In some embodiments, when a container is loaded on a terminal, the terminal operator can issue a terminal event notification that informs the carrier to track the transportation milestone. The terminal event notification contains the terminal location, event type, date, time, carrier and container number, etc. Then, the carrier finds the relevant party of this container and informs the party through the encrypted distributed ledger.

In some embodiments, a carrier may issue an invoice to a shipper and/or a consignee when loading a shipment. The shipper and/or consignee can then pay for the invoice. Then, the carrier sends 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 whether the consignee paid for the invoice (if any), and the carrier can verify the original bill of lading and other goods release procedures from the consignee. The carrier can 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.

Now provide non-restrictive aspects:

1. A method for protecting the privacy of the data of a transport document shared in a distributed user group, the method includes:

Receiving the transportation document from a user via a communication network, the user has an assigned role, and the high transportation document includes a plurality of data attributes;

Encrypting the plurality of data attributes into a similar number of encrypted data attributes through a first encryption logic, and the first encryption logic generates a data encryption key corresponding to each encrypted data attribute;

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

Encrypt the encryption keys corresponding to the plurality of data attributes through a second encryption logic, the second encryption logic uses the assigned role based on the user for one or more users of the distributed data ledger Provide a lookup table of permissions;

and

Distribute the distributed data ledger to the distributed user group via the communication network;

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

Each user can decrypt only the data related to the assigned role.

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

3. The method as in aspect 2, wherein the role assigned by the user is associated with a member access control policy.

4. The method as in aspect 1, wherein the assigned role further includes a relationship between transport parties.

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

6. The method as in aspect 1, wherein the transportation document provided by a user contains the assigned role of the user.

7. The method as in aspect 1, wherein the first or second encryption logic uses an asymmetric cryptographic algorithm.

8. The method as in aspect 1, wherein the communication network further includes a secure Internet access.

9. A communication system for providing real-time updated information on the progress of the transaction to a party in a transportation transaction, the system including:

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

1. A database, which stores system configuration information, public keys and reference information of transportation transactions (reservations);

A distributed ledger with a node for a user, the distributed ledger containing data related to the user related to the transportation transaction; and

A program that coordinates the field-level encryption process and distributes the encrypted results to the distributed ledger;

Where the user is a party to the transportation transaction; and

The portal, the database, and the distributed ledger can be accessed through a cloud computing environment.

10. Such as the communication system of aspect 9, where the portal is a client application.

11. Such as the communication system of aspect 9, wherein the distributed ledger is a super ledger.

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

In further detail, the method 3600 may include creating an electronic file of the transaction (3605). A server (for example, a transportation document control center) can identify, create, or create the electronic document (sometimes referred to herein as a transportation document). The electronic document may define, contain, or contain information about a single transaction conducted through multiple client terminals (or entities). The single transaction may involve a physical commodity (for example, delivery from one point to another), and may include a series of sub-transactions related to the physical commodity. Each sub-transaction of the physical commodity can be handled by at least one service provider (for example, an agency, an intermediary agency). The service provider may operate at least one of the client terminals involved in the transaction or be 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, wherein the remaining service providers access and/or facilitate the electronic document after the creation (for example, update the electronic document, or add information To the electronic file).

The electronic file may contain a set of data fields. Each data field of the electronic file may be related to or mapped to one of the child transactions of a single transaction involving the physical commodity. In the electronic document, an attribute or a value can be assigned to each data field. The attribute of at least one of the data fields may be associated with one of the client terminals (for example, the user node of the system 1300) involved in a single transaction (for example, 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 the client terminal operated by the first entity or the first service provider that initiated or created the electronic file . These data fields can contain parameters describing the transaction, such as container size, event date, landing port, product description, gross weight, ship name, loan account, and others. In some embodiments, the electronic file can be maintained on a database (for example, the file control center 3002). The database can be maintained or belong to a transportation document control hub for coordinating communications among the user terminals. Each data field of the electronic document maintained in the database can correspond to a database item in 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 follow the initial establishment by the first entity from one of the client terminals associated with the service provider that facilitated the electronic file. The service provider associated with the request may be related to the first entity or any of the data fields that contributed to the electronic document or other service providers that provide attributes for the data fields of the electronic document Lack of any (or limited) understanding or interaction. In this way, information from various entities can be used to fill the data fields of the electronic document in a specific way. Some or all service providers may be introduced or involved in a single transaction (e.g., sub-transaction or part), in a specific way (e.g., as needed or close to the time or At that time) rather than scheduled (for example, when creating an electronic file). Each part or sub-transaction of the transaction can be filled or served by one of a plurality of available service providers, which can be dynamically matched, filled and/or selected as the transaction develops and/or needs/functions/sub-transactions are generated . Except for the role/service and/or (several) service providers that a service provider directly interfaces with to perform the role/service of the service provider in the transaction, the service provider may not have an understanding of the transaction (or Have limited understanding of transactions). The request can identify 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 one of the access control principles for a role of the client terminal. The access control principle can stipulate which data fields the client terminal (or corresponding role) involved in the transaction has the authority to access or modify. In order to determine whether there is authority, the client terminal can recognize a role of the client terminal in the transaction. The role can be identified based on the role list of one of the sub-transaction series involved in the transaction.

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

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

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

In the distribution, the server can 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 the data field provided by the corresponding client terminal. In some embodiments, the server can identify two or more client terminals involved in a single transaction based on their respective roles according to the access control principle. For example, a first role associated with a first client terminal and a second role associated with a second client terminal can be specified by the access control principle as having access to data fields in electronic documents Access to one of the bits. The server can use another encryption key (for example, a public encryption key) of the second client terminal to encrypt one of the encryption keys (for example, a private encryption key) of the first client terminal. During encryption, the server can provide the encryption key of the first client terminal to the second client terminal.

In addition, the server can provide a public encryption key to one or more of the client terminals according to the access control principle. For example, the access control principle can be specified for one of the data fields: two client terminals have the authority to access the attributes in the data field. In this example, the server can provide the public encryption key to two 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 the private encryption key or the public encryption key provided to the client terminal.

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

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

In some embodiments, the server may receive or recognize a signature for each of the client terminals involved in a single transaction. The signature can be generated by applying the encryption key corresponding to the client terminal to the hash value derived from the attribute of the data field provided by the 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 integrity of the attribute data in the data field in the electronic document.

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

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 based on roles according to the access control principle. The hash value and signature of the data field in the electronic file may have been provided to each of the identified clients. The hash value can be derived from the attribute in the data field and the hash value of the client terminal that provides the attribute and the encryption key (for example, the public encryption key) can be used to generate the signature. 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 can calculate the hash value based on the encrypted attribute, and use the hash value to decrypt the signature to obtain the decrypted hash value. The client terminal can then compare the decrypted hash value with the hash value to determine completeness. When the hash value matches, the client terminal can determine that the attribute has data integrity. Otherwise, when the hash value does not match, the client terminal can determine that the attribute lacks data integrity.

Referring now to FIG. 37, the computer 3700 may include one or more processors 3705, volatile memory 3710 (e.g., random access memory (RAM)), and non-volatile memory 3720 (e.g., one or more hard disks). Hard drive (HDD) or other magnetic or optical storage media, one or more solid state drive (SSD) (such as a flash drive or other solid storage media), one or more hybrid magnetic and solid state drives, and / Or one or more virtual storage capacity (such as a cloud storage device) or a combination of these physical storage capacity and virtual storage capacity or one of its arrays), 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 (for example, a touch screen, a display, etc.) and one or more input/output (I/O) devices 3755 (for example, a mouse, a keyboard) , A microphone, one or more speakers, one or more cameras, one or more biological scanners, one or more environmental sensors, one or more accelerometers, etc.). The non-volatile memory 3720 stores the operating system 3735, one or more application programs 3740 and data 3745, so that (for example) the computer commands of the operating system 3735 and/or application programs 3740 are processed outside the volatile memory 3710器3705 executes. In some embodiments, the volatile memory 3710 may include one or more types of RAM and/or a cache memory that can provide a response time faster than a main memory. You can use one of the GUI 3750 input devices to input data or receive data from the I/O device 3755. The various components of the computer 3700 can communicate via one or more of the communication buses 3730 shown as communication buses.

The computer 3700 shown in FIG. 37 is shown (just as an example) as a client, server, intermediary structure, and other networked devices, and can be used in any computing or processing environment and can be as described herein The operation is suitable for any type of machine or machine set of 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 system functions. As used herein, the term "processor" describes a circuit system that performs a function, an operation, or a sequence of operations. The function, operation or sequence of operations can be hard-coded into the circuit system or soft-coded by means of instructions stored in a memory device and executed by the circuit system. A "processor" can use digital values and/or use analog signals to perform the function, operation, or sequence of operations. In some embodiments, the "processor" may be embodied in one or more application-specific integrated circuits (ASIC), microprocessors, digital signal processors (DSP), graphics processing units (GPU), microcontrollers , Field programmable gate array (FPGA), programmable logic array (PLA), multi-core processor or general purpose computer 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 containing multiple processor cores and/or multiple processors can provide the function of parallel simultaneous execution of several instructions on more than one data piece or parallel simultaneous execution of one instruction on more than one data piece Sex.

The communication interface 3715 may include one or more interfaces to enable the 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), and a personal area network (PAN) or the Internet.

The subject matter and operation embodiments described in this specification can be implemented in digital electronic circuits or computer software, firmware, or hardware (including the structures disclosed in this specification and their structural equivalents), or various One or more of the items in the combination. The 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 data processing equipment (such as a processing circuit) to execute or use One or more computer program instruction modules to control the operation of data processing equipment. A controller or processing circuit (such as a CPU) can include any digital and/or analog circuit components configured to perform the functions described herein, such as a microprocessor, microcontroller, special application integrated circuit, Stylized logic, etc. Alternatively or additionally, the program instructions can be encoded on an artificially generated propagation signal (for example, an electrical, optical or electromagnetic signal generated by a machine), which is generated and encoded for transmission to a suitable receiver Information for a data processing device to execute.

A computer storage medium can be or be included in the following: a computer-readable storage device, a computer-readable storage substrate, a random or serial access memory array or device, or any of them One or more combinations. In addition, although a computer storage medium is not a propagated signal, a computer storage medium may be a source or destination of computer program instructions encoded in an artificially generated propagated signal. The computer storage medium may also be one or more separate components or media (for example, multiple CDs, disks, or other storage devices), or be included in one or more separate components or media. Therefore, 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 device on data stored on one or more computer-readable storage devices or received from other sources. The term "data processing equipment" or "computing device" encompasses all types of equipment, devices, and machines used to process data. By way of example, it includes a programmable processor, a computer, a system-on-chip, or any of the foregoing Many or a combination. The device can include special-purpose logic circuit systems, such as an FPGA (field programmable gate array) or an ASIC (application-specific integrated circuit). In addition to hardware, the device can 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, and a cross-platform operation Time environment, a virtual machine, or a combination of one or more of them. The equipment and execution environment can implement various computing model infrastructures, such as web services, distributed computing and grid computing infrastructures.

A computer program (also called a program, software, software application program, descriptive language or program code) can be written in any form of programming language including compiled language or interpretation language, declarative or procedural language, and can Deploy the computer program in any form, including deployment as an independent program or as a module, component, subroutine, object, or other unit suitable for use in a computing environment. A computer program may but does not need to correspond to a file in a file system. A program can be stored in a part of a file that stores other programs or data (for example, stored in one or more descriptive languages in a markup language document), in a single file dedicated to the program in question, or Stored in multiple coordinated files (for example, a document storing one or more modules, subprograms, or parts of code). A computer program can be deployed to be executed on one computer or on multiple computers located at one site or distributed across multiple sites and interconnected by a communication network.

The procedures and logic flows described in this specification can be executed by one or more programmable processors that execute one or more computer programs to perform actions by operating on input data and generating output. These programs and logic flows can also be executed by a special-purpose logic circuit system (for example, an FPGA (Field Programmable Gate Array) or an ASIC (Special Application Integrated Circuit)), and the device can also be implemented as the dedicated logic electrical system.

For example, processors suitable for executing a computer program include, by way of example, both general-purpose microprocessors and special-purpose microprocessors, and any one or more processors of any type of digital computer. Generally speaking, a processor will receive commands and data from a read-only memory or a random access memory or both. The basic element of a computer is a processor used to perform actions according to instructions and one or more memory devices used to store instructions and data. Generally speaking, a computer will also include one or more mass storage devices (for example, magnetic disks, magneto-optical discs or optical discs) for storing data or be operatively coupled to receive from the one or more mass storage devices Data or send data to it or both receive and send data. However, a computer need not have such a device. In addition, a computer can be embedded in another device, such as a mobile phone, a personal assistant (PDA), a mobile audio or video player, a game console, a global positioning system (GPS) receiver, or a computer Portable storage device (for example, a universal serial bus (USB) flash drive) (just 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 (for example, EPROM, EEPROM, and flash memory devices); magnetic Disk (for example, internal hard disk or removable disk); magneto-optical disk; and CDROM and DVD-ROM disk. The processor and the memory can be supplemented by a special-purpose logic circuit system or incorporated into the special-purpose logic circuit system.

In order to provide interaction with a user, the embodiments of the subject matter described in this specification can be implemented on a computer with: a display device, for example, a CRT (Cathode Ray Tube) or LCD (Liquid Crystal Display) Monitor, OLED (Organic Light Emitting Diode) monitor or other form of display used to display information to the user; and a keyboard; and/or a pointing device, such as a mouse or a trackball, the user The pointing device can provide input to the computer. Other types of devices can also be used to provide interaction with a user; for example, the feedback provided to the user can 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 voice, voice or tactile input. In addition, a computer can interact with a user by sending documents to a device used by the user and receiving documents from the device; for example, by responding to one of the user’s client devices The web browser receives the request and sends a web page to the web browser.

Although this specification contains many specific embodiment details, these details should not be construed as limitations on the scope of any embodiment or content that can be claimed, but should be construed as descriptions of specific features of specific embodiments. The specific features described in this specification in the context of individual embodiments can also be implemented in a single embodiment in combination. Conversely, various features described in the context of a single embodiment can also be implemented in multiple embodiments individually or in any suitable sub-combination. In addition, although features may be described above as functioning in a particular combination and even initially claimed as such, in some cases, one or more features from a claimed combination may be removed from that combination, and so The claimed combination can be for a sub-combination or a variation of a sub-combination.

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

References to "or" can be construed as inclusive, so that any term set forth using "or" can indicate any of a single, more than one, and all of the terms set forth.

Therefore, specific embodiments of the subject matter have been described. There are other embodiments within the scope of the attached patent application. In some cases, the actions stated in the scope of the patent application can be performed in a different order and still achieve a satisfactory result. In addition, the procedures shown in the drawings do not necessarily require the specific order or sequence shown in order to achieve desired results. In certain embodiments, multitasking and parallel processing may be advantageous.

Specific embodiments of the method and system have been described, and those familiar with the art will now understand that other embodiments incorporating concepts can be used. It should be understood that the system described above can provide any or more of each of these components, and these components can be provided on a separate machine or in some embodiments in a distributed system On multiple machines. The system and method described above can be implemented as a method, device, or article using programming and/or engineering design techniques to generate software, firmware, hardware, or any combination thereof. In addition, the systems and methods described above can be provided as embodied on one or more parts or one or more computer-readable programs. The term "article" as used herein is intended to include code or logic that can be accessed from and embedded in: one or more computer-readable devices, firmware, programmable logic, Memory devices (for example, EEPROM, ROM, PROM, RAM, SRAM, etc.), hardware (for example, integrated circuit chip, field programmable gate array (FPGA), special application integrated circuit (ASIC), etc.), electronics Device, a computer-readable non-volatile storage unit (for example, CD-ROM, floppy disk, hard disk drive, etc.). The product can be accessed from a file server that provides access to computer-readable programs via a network transmission line, wireless transmission media, signals transmitted through space, radio waves, infrared signals, etc. The product can be a flash memory card or a tape. The artifacts include hardware logic and software or programmable codes embedded in a computer-readable medium and executed by a processor. Generally speaking, a computer readable program can be implemented in any programming language (such as LISP, PERL, C, C++, C#, PROLOG) or in any byte code language (such as JAVA). Software programs can be stored on or in one or more objects as object code.

102: Shipper 104: Forwarder 106: Carrier 108: Terminal 110: Customs 112: Port Authority 114: Consignee 116: Financial Institution 200: Transport Route 202: Shipper 204: Port Authority 206: Ship 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: Reservation application programming interface 600: Application programming interface 602: Client application 604: Application programming interface management tool 606: Blockchain application programming Interface 608: Verification 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 : Application Programming Interface Management Program 702: Start block 706: Step 708: Step 710: Step 712: Step 714: Step 716: End 718: Step 800: Distribution of transportation document data 802: Start block 804: Step 806: Step 808: Step 810: Step 812: End Block 900: Transport File Creation Model/Get Reservation Procedure 902: Start 904: Step 906: Step 908: Step 910: Step 912: Step 914: Step 916: Step 918: Step 920: End 1000: Sample reservation order 1100: Retrieve transportation documents / Retrieve reservation procedures 1102: Start block 1104: Attribute verification 1106: Obtain reservation information from the transportation document database and decrypt the encrypted reservation information 1108: Ensure that the reservations to be retrieved are appropriately Decryption of the desired reservation 1110: Transportation role check 1112: Filter attribute 1114: Success 1116: Error response 1118: End 1200: Create transportation file 1202: Start block 1204: Check attribute verification 1206: Find a role list of the reservation by locating the subkey 1208: Check whether the reservation access policy can be defined 1210: Collect the transportation role of the carrier 1212: Check whether the collected transportation role has access to create all the submitted attributes of the reservation data 1214: Generate a unique reservation identifier for the reservation 1216: Generate individual data encryption keys for each data attribute 1218: Encrypt each data attribute 1220: Retrieve the access control policy of each transport role 1222: Retrieve the public key from the public key repository 1224: Use The public key of the shipping party will correspond to The data encryption key encrypts one by one 1226: Distribute the encrypted data and the encrypted data encryption key to the appropriate organization 1228: Verify that the data and key are successfully distributed to all the ledgers of the relevant carrier 1230: Distribute the ledger The name, unique booking ID and booking version number are stored in the transportation document database 1232: a successful response code 1234 is generated: an error is returned 1236: end 1300: system 1302: transportation document control center 1304: off-chain database 1306a: First user node/user node 1306b: user node 1306n: user node 1308a-1308n: client application 1310a-1310n: client application database 1312a-1312n: key storage area 1314a-1314n: password Access layer 1316a-1316n: application programming interface/blockchain application programming interface 1318a-1318n: network communication/network connection 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: Role and Access Control Principle 1602: Data and Key Structure 1604: Sample Access Control Principle/Receive Cargo person’s access control principle 1606: Encrypt each data attribute individually with a data encryption key 1608: Public key encryption of the data encryption key 1700: Component relationship example/embodiment 1702: Access principle/transport document Access Principle 1704: Role List Access Principle 1706: Unique Identifier/Transportation Document 1708: Location Subkey 1710: Role List 1712: Location 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 Policy Location Subkey 1804: Role List Access Policy Example 1806: Role Attribute Level Example 1808: Role List Location Subkey 1810: Role List Content 1900 : Transportation document/Transport document and access control principle 1902: Container exit event/Exit instance/Exit event example 1904: Role list location subkey 1906: Transportation document access principle/Transport document hierarchy principle Example 1908: Transportation document structure example /Example/Architecture example 1910: Transport document access principle at the field level of outbound events/Transport document principle field level example/Field level example 2000: Example transportation document principle 2002: Dangerous goods certificate example 2004: Role list locator Key 2006: Document Level Access Principle 2008: Column Level Access Principle/Field Level 2010: Dangerous Goods Certificate Architecture Example 2100: Logical System Layout/System Layout 2102: Transportation document control center 2104: first user node/client node/user node 2106: document control center side message agent/message agent 2108: event message 2110: event message 2112: access policy 2114: public key Repository 2116: Identification Code Repository 2118: Client Node/User Node 2124: User Message Broker 2126: User Message Broker 2200: Sample Flowchart/Role List Submission Detailed Process 2202: Initial Check Attribute Verification 2206: Role check 2208: Define role list access policy 2210: Access right check 2212: Return an error response code 2214: Generate encryption key 2216: Encrypt the role list 2218: Generate by signing the hash with the sender's private key Sender’s signature 2220: Obtain the public key 2222: Encrypt the data encryption key 2223: Send the message to the transportation document control center 2224: Distribute the data and encryption key 2226: Check the distribution successfully 2228: Will have an error code Post event to the message agent 2232: Post an event with a success code that can go to the message agent on the client side 2234: End 2300: Read the detailed process of the role list / A procedure for reading a transport document 2302: Check Property verification 2304: Obtain the encrypted role list and the encrypted data encryption key 2310: Check the relevance of the role list 2312: Access the key storage area 2314: Decrypt the data encryption key 2316: Return an error response code 2318: Decrypt the role list 2320: Return a successful response code 2322: End box 2402: Check attribute verification 2404: Check if there is an existing role list from the access policy repository 2406: Transport role check 2408: Check if it can be transported Document level and transport document field level define access principles 2410: Access right check 2412: Generate unique transportation document identification code that can be unique throughout the system 2414: Generate data encryption key 2416: Encrypt data attributes 2418: Generate a hash about one of the attributes of the encrypted data and access the key storage area 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 a message with encrypted data attributes, encrypted data encryption key, hash, and sender's signature 2426: send the message to the transportation document control center 2428: make each user node make a successful notification Responding to check whether the distribution is successful 2430: Receive one of the encrypted transport files, encrypted DEK, hash, and sender's signature. Event 2432: Post a successful event notification to the sender 2436: Check integrity 2438: Decrypt the encrypted data encryption key 2440: Decrypt the transportation document 2442: The client application can receive the transportation in plain text File 2448: End block 2502: Start block 2504: Check attributes 2506: Check an existing transport document 2508: Find existing role list 2510: Role check 2512: Whether to define access policy 2514: Access right check 2516: Merge existing transport document attributes Encrypted data with the attributes of the submitted data (if available) 2518: Increase the version number of the transport document by one 2520: Generate a data encryption key 2522: New data attributes in the submitted transport document 2524: Add the submitted transport document Data attribute encryption 2526: Generate a hash about any newly encrypted data attribute (data field) and access the key storage area to generate the sender's signature by signing the hash with the sender's private key 2528: Get the role The public key of the parties in the list 2530: Encrypt the updated data encryption key 2532: Pack the message with the attributes of the encrypted data, the encrypted data encryption key, the hash, and the sender’s signature 2534: Put the message The encrypted transport document, the encrypted data encryption key, the hash and the sender's signature key are distributed to the appropriate blockchain ledger 2536: Whether the execution successfully distributes the encrypted transport document, the encrypted data encryption key, hash and send One of the signature checks of the user 2538: An event with an encrypted transport document, an encrypted data encryption key and the sender’s signature is released to the intended recipient 2540: Integrity check 2542: The data encryption key is decrypted 2544 : Decrypt the transportation document 2546: Receive the transportation document in plain text 2548: Return the error response code to the recipient 2550: Execute the success code with the sender's success code when a success code is sent to the sender's message agent a publishing events 2554: the error code has to send one message to one of the events published by the sender of the agency 2556: end box 2600: an exemplary program for reading a transport documents 2602: start box 2604: a comparison The transaction reference database checks the version number of the transport document 2606: Attribute verification 2608: Obtain the encrypted transport document and the encrypted data encryption key 2610: Check the correlation 2612: Access the key storage area 2614: Retrieve the data encryption key 2616 : Error 2618: Decrypt the encrypted transport document 2620: Return a successful response code to the client application 2622: End 2700: Reservation configuration 2702: Reservation version number 2800: Partial reservation view 2900: Possible activity 2902: Registered use User/User 2904: Third Party 2906: Document Control Hub 2908: User Node 2910: Third Party Node 3002: Document Control Hub 3004a: Transportation Document Database 3004b: Access Policy Repository 3004c: Public Key Repository 3004d: Identity Repository 3004n: Database 3006a: Recipient Library Encryption 3006b: Recipient Library Encryption 3006n: Recipient Library Encryption 3010 : Authentication function/authentication function hosted by the document control center 3020: Secure communication link 3022: User 3024: User-controlled data package/Data package 3026: Data encryption key/Encrypted data encryption key/Decrypted data encryption Key 3028: User Private Key 3060: Third Party 3062: Third Party Controlled Data Package/Third Party Data Package/Data Package 3064: Separate Secure Communication Link 3102: Loan Application 3104: App Verification 3106: Compliance Inspection 3108: Payment 3110: Approved and issued loan 3112: Transport incident 3114: Transport document 3116: Invoicing 3118: Forwarder experiences its own forwarder activities 3120: Bank experiences its own banking activities 3200: Account 3202: On behalf of Carrier 3204: Secure Communication 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: Example 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: Application 3745: Data 3750: Graphical User Interface 3755: Input/Output Device

In order to easily identify the discussion of any particular element or action, one or more of the most significant digits in an element symbol refers to the figure number in which the element is first introduced.

Figure 1 illustrates a communication system.

Figure 2 illustrates an example transportation route 200 according to one embodiment.

FIG. 3 illustrates a key repository program 300 according to an embodiment.

Figure 4 illustrates an asymmetric key position 400 according to an embodiment.

Figure 5 illustrates an authentication process 500 according to an embodiment.

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

Figure 7 illustrates an API management program 700 according to an embodiment.

Figure 8 illustrates a shipping document distribution 800 according to one embodiment.

Figure 9 illustrates a shipping document creation model 900 according to one embodiment.

Figure 10 illustrates a sample booking list 1000 according to an embodiment.

FIG. 11 illustrates the retrieval of a transport document 1100 according to one embodiment.

Figure 12 illustrates the creation of a shipping file 1200 according to one of the embodiments.

Figure 13 illustrates an example system 1300 according to one embodiment.

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

FIG. 15 illustrates generating keys and matching the assigned roles of their keys and a user with the access policy 1500 according to an embodiment.

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

Figure 17 illustrates a component relationship example 1700 according to an embodiment.

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

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

Figure 20 illustrates an example transport 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 for submitting a role list according to an embodiment.

FIG. 23 illustrates a detailed flow 2300 of reading a role list according to an embodiment.

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

Figure 25 illustrates a shipping file update 2500 according to one embodiment.

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

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

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

Figure 29 illustrates a possible activity 2900 regarding a third party non-user according to an embodiment.

Figure 30 illustrates that a user provides information from the system to a third party according to an embodiment.

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

Figure 32 illustrates a documented exchange to support the creation of a loan account according to an embodiment.

Figure 33 illustrates a documented exchange to support financing applications according to an embodiment.

Figure 34 illustrates an example invoice according to an embodiment.

Figure 35 illustrates an example payment option according to an embodiment.

FIG. 36 is a flowchart of a method for safely sharing data from multiple sources with different client terminals according to an embodiment.

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

102: Shipper

104: Carrier

106: Carrier

108: Pier

110: Customs

112: Port Authority

114: consignee

116: financial institutions

Claims (47)

A system for generating a transportation document, the system comprising: a transportation document control center, the transportation document control center including: A computer including a first logic, a first memory, and a first communication device; A message agent, the message agent can send and receive an event message; An access policy repository, the access policy repository is stored on the first memory: A public key repository, which is stored on the first memory; An ID repository, the ID repository including one or more users, one or more user login credentials, and a list of one or more user parameters; 1. Transport document database; and A blockchain database for storing one or more of the following: the access policy repository, the public key repository, the ID repository, and the transportation document database; A first user node, which includes: A user computer including a second logic, a second memory, and a second communication device; A key storage area, the key storage area includes a user login ID secret and a private key, the key storage area can be accessed by the second logic; An API interface, which includes a cryptographic access layer for electronic communication with the key storage area, and a user message broker; and A portal for the user to access the transportation document control center; The API interface is executed on the second logic and communicates with the information agent of the transportation document control center. Such as the system of claim 1, wherein the access policy repository further includes: One role list principle for each role list type; The principle of one common transportation document for each common transportation document type; A list of global users; and A list of dynamic access policies, where each dynamic access policy is specific to a set of shared transportation documents, and the dynamic access policy defines the access rights of each user. Such as the system of claim 1, in which the blockchain database is stored on a distributed ledger. Such as the system of claim 1, wherein the blockchain database is stored in a super ledger. Such as the system of claim 1, where the portal is one or more of the following: a web portal, a user application, and a server application. Such as the system of claim 1, wherein the system further includes a plurality of user nodes. For example, the system of claim 1 further includes a third-party node, wherein the third-party node communicates with a verification function of the transportation document control center. A user node used when generating a shared transportation document transaction, the user node includes: A computer including a logic for executing program instructions, a memory device, a user interface, and a communication device for accessing a transportation document control center; A message agent, the message agent can send and receive an event message; An application programming interface (API), which further includes a password access layer, the API coordinates the correspondence between the shared transportation document transaction and the transportation document control center; and A block chain database is stored on the memory device, and the block chain database includes information related to a user role in the shared transportation document transaction. Such as the user node of request 8, where the memory device maintains a distributed ledger. Such as the user node of request 8, where the memory device maintains a super ledger. Such as the user node of request 8, where the message broker is configured to send a message to a third-party non-user, where the message includes encrypted data from the transportation document control center, and the encrypted data is Limited to the data that a user of the user node can access according to an access control policy and a user role list. A transportation document control center for coordinating the communication between a first user node and a second user node in the distribution of a shared transportation document, the shared transportation document including a plurality of data attributes and a digital signature, The transportation document control center includes: A computer including a logic for executing program instructions, a memory device, and a communication device for accessing the first user node; A communication routing controller, the communication routing controller includes a routing logic to route a shared transport document received from the first user node to the second user node, wherein the second user node is based on the The first user node provides a list of recipients selected from a list of acceptable user nodes; A distributed ledger, which is stored on the memory, wherein the distributed ledger includes an encrypted shared transport document, an encrypted data encryption key, a hash of the encrypted shared transport document, and the digital One of the signatures is a blockchain database. For example, the transportation document control center of claim 12, wherein the distributed ledger maintains a super ledger. For example, the transportation document control center of claim 12, wherein the computer further includes a second memory device, and the second memory device stores off-link data. A method for generating a common transportation document for a cargo transportation, the method includes: A shared transportation document is generated through a first client node, and the shared transportation document is encrypted by an application programming interface (API); Submit the encrypted shared transportation document to a transportation document control center via a communication device; Identify one or more users through an access control logic, and each user has at least one assigned role according to an access control principle; and Through the transportation document control center, forward the encrypted shared transportation document to the one or more users, wherein the one or more users can use the one or more users as provided in the access control principle The assigned role of the person to perform one of the roles of the encrypted transport file. Such as the method of claim 15, wherein the shared transportation document further includes a role list. Such as the method of claim 16, wherein the role list further includes a transportation role list. Such as the method of claim 15, further including: Obtain a data package through the first client node. Such as the method of claim 18, wherein the data is packaged and distributed to a third-party non-user. Such as the method of claim 19, wherein the third-party non-user communicates with a verification function of the transportation document control center to verify the integrity of a data package. A method for identifying a user's access right to a shared transportation document, the method comprising; Receiving a shared transport document via a communication device, the shared transport document having an initiator user, a role list, and an identification code; Identifying the originator user of the shared transport document via a processor; Determine the role of the identified initiator user via a processor, and the role is established by a global user list; Through a processor, verify the role list of the shared transportation document against the global member list; Encrypt at least one data attribute of the shared transport document through a processor; and Distribute the encrypted data attribute to at least one authenticated user on the role list via a communication device. A method for safely storing shared data among multiple users. The method includes: Encrypt a plurality of data fields in an electronic document, where each data field is encrypted separately from each other data field; For each encrypted data field, encrypt the encryption key to generate an encrypted encryption key for each data field; Distribute the encrypted encryption keys and the encrypted data to a plurality of data storage devices; Each user can access the encrypted data by decrypting the encrypted encryption key for the encrypted data field assigned to the user. Such as the method of claim 22, wherein the method further includes: A user access to a data field is identified based on a role policy list, a user list, and a transportation document control list. A method for safely sharing data from multiple sources with different client terminals, which includes: Created by at least one server with one or more processors to define an electronic document for a single transaction, the electronic document has a plurality of data fields, and each of the plurality of data fields will be the same as the plural Is associated with one of the client terminals; A plurality of encryption keys used to encrypt the corresponding plurality of data fields contained in the electronic document identified by the at least one server; The at least one server distributes the plurality of encryption keys across the plurality of client terminals according to an access control principle, and the access control principle is based on one of the plurality of client terminals corresponding to the client terminal A role in the single transaction defines the access authority of the corresponding client terminal to each of the plurality of data fields; and The at least one server provides the plurality of data fields in the electronic document to 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 them. Such as the method of claim 24, wherein the establishment of the electronic file further includes: Receiving a request to update one of the attributes of one of the first data fields in the electronic document from one of the first user terminals in the plurality of user terminals; According to the access control principle, it is determined 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 single transaction; and In response to 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 electronic document. Such as the method of claim 24, further including: The at least one server responds to the update of one of the first data fields in the plurality of data fields in the electronic document in response to the first client terminal receiving from one of the plurality of client terminals A request for one attribute and one role of the first client terminal are identified from a role list in the single transaction; The at least one server determines that the first client terminal lacks the authority to modify the first data field based on the recognized role of the first client terminal according to the access control principle; and The at least one server responds to determining that the first client terminal lacks the authority and prevents the first client terminal from updating the attribute of the data field in the electronic document. For example, the method of claim 24, wherein identifying the plurality of encryption keys further includes identifying a plurality of private encryption keys and a plurality of public encryption keys for the corresponding plurality of client terminals; and The distribution of the plurality of encryption keys further includes: Providing one of the plurality of private encryption keys to a corresponding one of the plurality of client terminals; and According to the access control principle, one of the plurality of public encryption keys is provided to at least one of the plurality of client terminals, and one of the plurality of data fields in the electronic document At least one 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. Such as the method of claim 24, further including: According to the access control principle, the at least one server recognizes the plurality of client terminals based on a first role of a first client terminal and a second role of a second client terminal The first client terminal and the second client terminal; and In response to identifying the first client terminal and the second client terminal, the at least one server uses one of the public encryption keys of the second client terminal to make the first client terminal a first An encryption key encryption; Wherein distributing the plurality of encryption keys further includes providing the first encryption key of the first user terminal encrypted with the public encryption key of the second user terminal to the second user terminal . Such as the method of claim 24, further including: The at least one server identifies the plurality of hash values derived from the corresponding plurality of attributes in the plurality of data fields of the electronic file, and each of the plurality of hash values is used to ensure that the plurality of attributes are Data integrity of one of them; and The at least one server uses one of the plurality of hash values and one of the plurality of encryption keys for the first encryption for one of the plurality of client terminals. The key generates a first signature, the first hash value is derived from one of the first attributes of the plurality of attributes, and the first encryption key is for the plurality of data fields corresponding to the first attribute A first data field. The first signature is used to ensure the data integrity of the first attribute and the first data field. Such as the method of claim 24, further including: According to the access control principle, the at least one server recognizes the plurality of client terminals based on a first role of a first client terminal and a second role of a second client terminal A first client terminal and the second client terminal; Wherein providing access further includes a hash value derived from an attribute of the data field and a signature of the first client terminal, providing the second client terminal to the first client terminal Access to one of the plurality of data fields, the second client terminal is used to use the hash value and the signature to obtain the plurality of encryption keys of the first client terminal One of the encryption keys. Such as the method of claim 24, further including: The at least one server determines whether the distribution of the plurality of encryption keys across one of the plurality of client terminals is successful; and The at least one server provides 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 is successful. For example, the method of claim 24, wherein identifying the plurality of encryption keys further includes aggregating one of the plurality of encryption keys from each of the plurality of client terminals to correspond to the encryption key, and the corresponding encryption The key is generated by the client terminal to encrypt one of the data fields. For example, the method of claim 24, wherein creating the electronic document further includes creating the electronic document on a database of a transportation document control center to coordinate communication among the plurality of client terminals, the plurality of data of the electronic document The fields correspond to the corresponding plural database items on the database. Such as the method of claim 24, wherein the single transaction involves a physical commodity and includes a series of sub-transactions of the physical commodity, and each of the plurality of data fields is mapped to one of the sub-transactions. Such as the method of claim 24, wherein at least one service provider handles each of the sub-transactions of the physical commodity. A system for safely sharing data from multiple sources with different client terminals, which includes: At least one server with a processor configured to perform one or more of the following operations: Create an electronic document used to define a single transaction, the electronic document has a plurality of data fields, each of the plurality of data fields will be associated with one of a plurality of client terminals; Identify a plurality of encryption keys used to encrypt the corresponding plurality of data fields contained in the electronic document; According to an access control principle, the plurality of encryption keys are distributed across the plurality of client terminals. The access control principle is based on one of the plurality of client terminals corresponding to the client terminal in the single transaction. A role that defines the corresponding client terminal's access authority to each of the plurality of data fields; and Provide each of the plurality of client terminals with access to at least one of the plurality of data fields in the electronic file through the plurality of encryption keys distributed according to the access control principle . Such as the system of claim 36, wherein the at least one server is further configured to: Receiving a request to update one of the attributes of one of the first data fields in the electronic document from one of the first user terminals in the plurality of user terminals; According to the access control principle, it is determined 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 single transaction; and In response to 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 electronic document. Such as the system of claim 36, wherein the at least one server is further configured to: In response to a request from one of the plurality of client terminals to the first client terminal to update one of the attributes of one of the first data fields in the electronic document, and Identify a role of the first client terminal from a list of roles in the single transaction; According to the access control principle, it is determined that the first client terminal lacks the authority to modify the first data field based on the recognized role of the first client terminal; and In response to determining that the first client terminal lacks the authority, the first client terminal is prevented from updating the attribute of the data field in the electronic document. Such as the system of claim 36, wherein the at least one server is further configured to: For the corresponding plurality of client terminals, identify a plurality of private encryption keys and a plurality of public encryption keys; Providing one of the plurality of private encryption keys to a corresponding one of the plurality of client terminals; and According to the access control principle, one of the plurality of public encryption keys is provided to at least one of the plurality of client terminals, and one of the plurality of data fields in the electronic document At least one can be accessed by at least two of the plurality of client terminals using at least one of the private encryption keys and the public encryption keys. Such as the system of claim 36, wherein the at least one server is further configured to: According to the access control principle, the first client terminal is identified from the plurality of client terminals based on a first role of a first client terminal and a second role of a second client terminal And the second client terminal; and In response to identifying the first client terminal and the second client terminal, encrypting the first encryption key of one of the first client terminals using one of the public encryption keys of the second client terminal; The first encryption key of the first client terminal encrypted with the public encryption key of the second client terminal is provided to the second client terminal. Such as the system of claim 36, wherein the at least one server is further configured to: Identify the multiple hash values derived from the corresponding multiple attributes in the multiple data fields of the electronic document, and each of the multiple hash values is used to ensure that the data of one of the multiple attributes is complete Sex; and For a first client terminal of the plurality of client terminals, a first hash value of the plurality of hash values and a first encryption key of the plurality of encryption keys are used to generate a first encryption key. A signature, the first hash value is derived from one of the first attributes of the plurality of attributes, wherein the first encryption key is for the first data corresponding to the first attribute in the plurality of data fields Field, the first signature is used to ensure the data integrity of the first attribute and the first data field. Such as the system of claim 36, wherein the at least one server is further configured to: According to the access control principle, the first client terminal is identified from the plurality of client terminals based on a first role of a first client terminal and a second role of a second client terminal And the second client terminal; Provide the plurality of data fields of the first client terminal to the second client terminal through a hash value derived from an attribute of the data field and a signature of the first client terminal For accessing one of the data fields in the bit, the second client terminal is used to use the hash value and the signature to obtain one of the encryption keys of the first client terminal. Such as the system of claim 36, wherein the at least one server is further configured to Determine whether the plurality of encryption keys are successfully distributed across one of the plurality of client terminals; and Based on a determination of whether the distribution of the plurality of encryption keys is successful, an event notification is provided to at least one of the plurality of client terminals. For example, the system of claim 36, wherein the at least one server is further configured to aggregate one of the plurality of encryption keys from each of the plurality of client terminals corresponding to the encryption key, and the corresponding The encryption key is generated by the client terminal to encrypt one of the data fields. For example, the system of claim 36, wherein the at least one server is further configured to create the electronic document on a database of a transportation document control center to coordinate communication among the plurality of client terminals, and the electronic document The plurality of data fields correspond to the corresponding plurality of database items on the database. For example, the system of claim 36, wherein the single transaction involves a physical commodity and includes a series of sub-transactions of the physical commodity, and each of the plurality of data fields is mapped to one of the sub-transactions. Such as the system of claim 36, wherein each of the sub-transactions of the physical commodity is handled by at least one service provider.

Images