Zero trust communication system for cargo transport organization and method of using the same

Abstract

This document presents a system and method for securely sharing data from multiple sources with different client terminals. A server can create an electronic document defining a transaction. This electronic document may have data fields. Each data field may originate from a client terminal. The server can identify an encryption key used to encrypt the corresponding data field contained in the electronic document. The server can distribute the encryption key across the client terminals according to access control principles. The access control principles can specify the access permissions of each client terminal to each of the multiple data fields based on the client terminal's role in the transaction. The server can provide each client terminal with access to the data field in the electronic document via the encryption key distributed according to the access control principles.

Description

[0001] Cross-references to related applications

[0002] This invention claims priority to U.S. Provisional Application 62 / 919,097, filed February 25, 2019, entitled "Encryted Districuted Ledger for Use with Freight Shipping Organizations, and method of use," the entire contents of which are incorporated herein by reference. This application is a continuation-in-part of US16,501,399, filed April 5, 2019, entitled "Zero Trust Communication System for Freight Shipping Organizations, and method of use," the entire contents of which are incorporated herein by reference. Technical Field

[0003] This 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. Background Technology

[0004] Long-distance transport of goods using containers is a standard form of transport. Intermodal containers are used to transport goods by road, rail, and sea. Units are stackable and designed to be moved from one form of transport to another without opening the container. Transport involving one or more containers is a commitment by a transport carrier to use intermodal containers or to deliver goods as project goods (collectively referred to as "goods" or "cargo"). For a transport to be successfully completed, relevant data needs to be shared among the various parties involved. These parties include, but are not limited to, transport carriers, ship operators in the transport process, ports / terminals, government agencies, and transport parties in the transport (including shippers, consignees, and sometimes agents and notifying parties). Other parties may also be involved in the transport of goods. Summary of the Invention

[0005] This paper describes systems and methods for using communication systems involving zero trust. These communication systems can be designed to work with users who may be direct competitors or collaborating competitors, but sometimes expect or may need to work in the same space to achieve their business objectives.

[0006] In the loading, unloading, and movement of shipping containers (sometimes called intermodal containers), the companies involved communicate with each other using business-to-business (B2B) communications, electronic data interchange (EDI), and application programming interface (API) calls. These communication channels are point-to-point, requiring one party to communicate with another. The individual-to-individual nature of this communication generally does not allow multiple parties to be "in a loop" simultaneously. Different parties also have varying agreements on how they handle communications, thus communication can be delayed or subject to company principles that reduce the timeliness of such communications. The geographical distribution of parties in moving goods causes communication delays. Goods may originate in Asia and be destined for locations in the Americas, Europe, or Africa. A convenient time to attempt communication with one party may be after another party's business hours, leading to further delays.

[0007] Organizations that directly compete with each other can sometimes share resources to fulfill their corporate responsibilities. For example, two or more shipping companies might share their vessels to transport goods, enabling better service coverage and economies of scale. Another example is multiple shippers using the same agent sharing a single intermodal container to avoid each having to pay for and transport a separately partially filled container. Other economies of scale and better service performance can be achieved when companies can coordinate their activities. However, coordination often requires disclosing confidential data, which companies are reluctant to do. There are also regulatory requirements prohibiting the sharing of specific types of data with specific parties. More generally, each party possesses confidential information. The need to protect confidential information (such as business contacts, customer lists, pricing information, etc.) is crucial for maintaining a competitive advantage and regulatory compliance in the market. Therefore, parties that compete with each other or need to use each other's services will not share their confidential information.

[0008] Methods for handling and tracking intermodal containers tend to focus on the contents of the container or on tracking within a small location rather than on a global scale. Therefore, there remains a need for communication and data control systems that allow parties working together on a common task to share confidential information in a format that allows each party to see only the information necessary for performing their task, while keeping any other information confidential from its source. Furthermore, there is a need for systems that can reduce the time required to track goods anywhere along the transport route and provide timely updates on the location of both intermodal containers and project cargo.

[0009] Further, there is a need to provide timely status and updates on such transport to all parties involved in the delivery, loading, and unloading of intermodal containers and project goods, while protecting data privacy and business confidentiality. These and other objectives can be met by the following disclosures.

[0010] A system for generating transport documents is described. The system may have a transport document control center and one or more user nodes. The transport document control center may have a computer with logic, memory, and communication devices. The center may also have a message broker capable of sending and receiving event messages. An access policy store may exist, storing a global member list, an access policy document list, and a role list. A public key store may also exist stored in the memory. An identifier (ID) store may also exist, containing a list of one or more users, one or more user login authentications, and one or more user parameters. A blockchain database may also exist, containing one or more blockchain nodes storing encrypted transport documents, encryption keys for encrypted data, and the signature of the document initiator. The user nodes may have one or more of the following: a computer, a message broker, a key store for decrypting transport documents, an API interface with a cryptographic layer for encrypting transport documents, and a portal for accessing the transport document control center. This API interface can be executed logically on the user's computer and communicate with the transport document control central message agent.

[0011] The document also describes an independent user node used in generating a single shared transport document transaction. This user node may have a computer with logic for executing program instructions, memory devices, a user interface, and communication devices for accessing the transport document control center. The user node may have a message broker capable of sending and receiving event messages. The API interface may have a cryptographic access layer that coordinates the correspondence between the shared transport document transaction and the transport document control center. The user node may also have a blockchain database stored on the memory device. The memory device may be local, remote, cloud-based, or removable. The blockchain database may contain transport documents associated with user roles in a single shared transport document transaction.

[0012] The document also describes an independent transport document control center for coordinating communication between a first user node and a second user node in the distribution of shared transport (electronic) documents. The shared transport document may have encrypted data attributes, an encrypted data encryption key, and / or a digital signature of the document initiator. The transport document control center may be a computer with logic for executing program instructions, memory devices, and communication devices for communicating with the user nodes. A communication routing controller may exist, which may use routing logic to route shared transport documents received from the first user node to the second user node. The second user node may be one of the transporters of the transport document provided by the first user node. A distributed ledger may exist stored in the memory. This distributed ledger may be a blockchain database for storing encrypted shared transport documents (or selecting the data attributes of shared transport documents). The encrypted data encryption key, the hash of the encrypted shared transport document, and the digital signature of the document initiator may also be stored.

[0013] There are also methods for generating shared transport files. These methods may involve: generating a shared transport file and encrypting it via a cryptographic access layer in an API interface; submitting the encrypted shared transport file, the encrypted data encryption key, and the digital signature of the file initiator to a transport file control hub (the hub); identifying one or more users, each of whom may have at least one assigned role according to access control principles; and forwarding the encrypted shared transport file, the encrypted data encryption key, and the digital signature of the file initiator to the one or more users, wherein the one or more users may perform the role of the encrypted transport file based on the roles assigned to them as provided by the access control principles.

[0014] Alternatively, a method may exist for identifying user access rights to the shared transport file. This method may involve receiving a transport file to be shared by at least one user, the file containing an initiator, a role list, and an identifier. The initiator is then identified, their role is determined based on a global user list (or global member list), the role list of the shared transport file is verified, at least one data attribute of the shared transport file is encrypted using a data encryption key, the data encryption key is encrypted using the public key of the relevant transporter according to access principles, and the at least one data attribute is distributed to at least one verified user.

[0015] It also elaborates on additional aspects.

[0016] The cargo tracking system and methods described herein help companies and individuals track the progress of cargo containers, such as intermodal containers, through transportation processes. This is achieved by assigning roles to each party when they provide transportation documents to the system. The system can organize these transportation documents and encrypt them according to a logical scheme. These transportation documents can undergo a process in which they can be shared with other logically related parties (e.g., when they are all associated with a co-carrier or agent). Data corresponding to the transported cargo can be updated at various times and events during the transportation of goods from the point of origin to the point of destination. Each update generates a new encrypted transportation document, which can be shared with all parties sharing logical, business, or financial relationships.

[0017] Transport documents indicating freight may contain information about the transport of goods, such as what products can be transported, their weight, and whether any special handling is required (to name just a few). The transport document may also contain information about the parties involved (e.g., shipper, consignee, transport carrier) and the route of transport. Additionally, the transport document may contain one or more event logs storing events that occur during transport that may be significant to its status. In short, the transport document may cover a variety of other details that may relate to any transport. Access rules for the transport document may also include information about who can act as a transporter. Transport documents can be added, edited, or read within the system. In some embodiments, the transport document may contain information about the user. In some embodiments, the transport document may be a virtual document for the transport of goods. In some embodiments, the transport document may contain information about the user.

[0018] In some embodiments, the party accessing the system may be a user of the system. Such users may have various access levels and privileges to the system. In some embodiments, such users may be able to read data presented in the system. In some embodiments, users may be able to create data in the system. In still other embodiments, users may be able to update existing information in the system. In some embodiments, users 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.

[0019] In some embodiments, the system may have one or more member levels. These different member levels may be accompanied by different access rights or authorizations. In some embodiments, these different access rights may be accompanied by different fees.

[0020] In some embodiments, a system may exist that receives user information and stores information related to the transportation and tracking of containers in real time. This system may include a computer having a processor, memory, and a communication interface for accessing the Internet. The computer system may receive data from one or more users via the communication interface. The data may be processed, collected, and categorized into an organized data structure in the memory. The computer may have logic enabling it to transform the data from one or more users into encrypted records. The computer may use various encryption methods to encrypt the data to produce the encrypted transport document. A series of data encryption keys may also be generated, with one data encryption key provided for each attribute of the transport document. Individual data encryption keys may be encrypted based on the user's role within the relevant transporter using the user's public key. This user's public key is called a key encryption key. These encrypted data encryption keys and encrypted data encapsulations may be provided to users through blockchain nodes accessible to each user by the system. Nodes may be shared or dedicated to the transporter. Users can use their private key to decrypt the encryption key of encrypted data, and then use the decrypted encryption key to decrypt the relevant data in the node.

[0021] In some embodiments, methods may exist for protecting the data privacy of transport files shared among a distributed group of users. The method includes receiving the transport file from a user via a communication network, the user possibly having an assigned role, wherein the transport file includes multiple data attributes. The multiple data attributes may also be encrypted into a similar number of encrypted data attributes via a first encryption logic, the first encryption logic generating a data encryption key corresponding to each encrypted data attribute. The method may also involve organizing the multiple encrypted data attributes into a distributed data ledger containing at least one encrypted transport file from a user via programmatic logic. The method further involves encrypting the encryption keys corresponding to the multiple data attributes via a second encryption logic, the second encryption logic using a lookup table that provides permissions to one or more users of the distributed data ledger based on the user's assigned role. The method may also include distributing the encrypted data attributes and the encrypted data encryption keys to the blockchain nodes via the communication network in a more efficient manner, making the entire solution scalable. Each user can access a node that provides access to one of the distributed data ledgers. Each user can decrypt only the data related to the role they are assigned.

[0022] The first and second encryption methods can utilize various encryption techniques. The user-assigned roles can be associated with user access control policies.

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

[0024] At least one aspect of the present invention relates to a method for securely sharing data from multiple sources with different client terminals. At least one server having one or more processors can create an electronic document for defining a single transaction. The electronic document may have multiple data fields. Each of the multiple data fields may be associated with one of a plurality of client terminals. The at least one server can identify multiple encryption keys to encrypt the corresponding multiple data fields contained in the electronic document. The at least one server can distribute the multiple encryption keys across the multiple client terminals according to access control principles. The access control principles can specify the access rights of a corresponding client terminal to each of the multiple data fields based on the role of that client terminal in the single transaction. The at least one server can provide each of the multiple client terminals with access to at least one of the multiple data fields in the electronic document via the multiple encryption keys distributed according to the access control principles.

[0025] In some embodiments, creating the electronic document may include receiving a request from a first client terminal among a plurality of client terminals to update the attribute of a first data field among the plurality of data fields in the electronic document. In some embodiments, creating the electronic document may include determining, based on the access control policy and the role of the first client terminal in the individual transaction, that the first client terminal has permission to modify the first data field. In some embodiments, creating the electronic document may include, in response to determining that the first client terminal has the permission, allowing the client terminal to update the attribute of the first data field in the electronic document.

[0026] In some embodiments, the at least one server may, in response to a request received from a first client terminal among a plurality of client terminals to update the attribute of a first data field among a plurality of data fields in the electronic document, identify the role of the first client terminal from a role list in the single transaction. In some embodiments, the at least one server may, based on the identified role of the first client terminal and according to the access control policy, determine that the first client terminal lacks permission to modify the first data field. In some embodiments, the at least one server may, in response to determining that the first client terminal lacks the permission, prevent the first client terminal from updating the attribute of the data field in the electronic document.

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

[0028] In some embodiments, the at least one server may identify the first client terminal and the second client terminal from the plurality of client terminals based on a first role of the first client terminal and a second role of the second client terminal, according to the access control policy. In some embodiments, the at least one server may, in response to identifying the first client terminal and the second client terminal, encrypt a first encryption key of the first client terminal using one of the public encryption keys of the second client terminal. In some embodiments, distributing the plurality of encryption keys may include providing the first encryption key of the first client terminal, encrypted using the public encryption key of the second client terminal, to the second client terminal.

[0029] In some embodiments, the at least one server may identify multiple hash values ​​derived from corresponding attributes in the plurality of data fields of the electronic document. Each of the plurality of hash values ​​may ensure the data integrity of one of the plurality of attributes. In some embodiments, the at least one server may generate a first signature for a first client terminal among the plurality of client terminals using a first hash value among the plurality of hash values ​​and a first encryption key among the plurality of encryption keys. The first hash value may be derived from a first attribute among the plurality of attributes. The first encryption key may be for a first data field among the plurality of data fields corresponding to the first attribute. The first signature may ensure the data integrity of the first attribute and the first data field.

[0030] In some embodiments, the at least one server may identify the first client terminal and the second client terminal from among the plurality of client terminals based on a first role of the first client terminal and a second role of the second client terminal, according to the access control policy. In some embodiments, providing access may include granting the second client terminal access to a data field among the plurality of data fields of the first client terminal via a hash value derived from an attribute of the data field and a signature of the first client terminal. The second client terminal may use the hash value and the signature to obtain an encryption key among the plurality of encryption keys of the first client terminal.

[0031] In some embodiments, the at least one server may determine whether the distribution of the plurality of encryption keys across 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 the determination of whether the distribution of the plurality of encryption keys is successful.

[0032] In some embodiments, identifying the plurality of encryption keys may include a corresponding encryption key aggregated from each of the plurality of client terminals. This corresponding encryption key may be generated by the client terminal to encrypt the data fields among the plurality of data fields. In some embodiments, creating the electronic document may include creating the electronic document on a database of a transport document control center to coordinate communication among the plurality of client terminals, wherein the plurality of data fields of the electronic document correspond to corresponding database entries on the database.

[0033] In some embodiments, the single transaction may involve a physical product and may include a series of sub-transactions related to that physical product. Each of the plurality of data fields may map to one of the sub-transactions. In some embodiments, each of the sub-transactions related to the physical product may be handled by at least one service provider.

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

[0035] In some embodiments, the at least one server may receive a request from one of the plurality of client terminals to update an attribute of one of the plurality of data fields in the electronic document. In some embodiments, the at least one server may determine, based on the access control policy and the role of the first client terminal in the single transaction, that the first client terminal has permission to modify the first data field. In some embodiments, the at least one server may, in response to determining that the first client terminal has the permission, allow the client terminal to update the attribute of the first data field in the electronic document.

[0036] In some embodiments, the at least one server may, in response to receiving a request from one of the plurality of client terminals to update an attribute of one of the plurality of data fields in the electronic document, identify a role of the first client terminal from a role list in the single transaction. In some embodiments, the at least one server may, based on the identified role of the first client terminal, determine that the first client terminal lacks permission to modify the first data field according to the access control policy. In some embodiments, the at least one server may, in response to determining that the first client terminal lacks the permission, prevent the first client terminal from updating the attribute of the data field in the electronic document.

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

[0038] In some embodiments, the at least one server may identify the first client terminal and the second client terminal from among the plurality of client terminals based on a first role of a first client terminal and a second role of a second client terminal, according to the access control policy. In some embodiments, the at least one server may, in response to identifying the first client terminal and the second client terminal, encrypt a first encryption key of the first client terminal using a public encryption key of the second client terminal. In some embodiments, the at least one server may provide the first encryption key of the first client terminal, encrypted using the public encryption key of the second client terminal, to the second client terminal.

[0039] In some embodiments, the at least one server may identify multiple hash values ​​derived from corresponding attributes in the plurality of data fields of the electronic document. Each of the plurality of hash values ​​ensures the data integrity of one of the plurality of attributes. In some embodiments, the at least one server may generate a first signature for a first client terminal among the plurality of client terminals using a first hash value among the plurality of hash values ​​and a first encryption key among the plurality of encryption keys. The first hash value may be derived from a first attribute among the plurality of attributes. The first encryption key may be for a first data field among the plurality of data fields corresponding to the first attribute. The first signature ensures the data integrity of the first attribute and the first data field.

[0040] In some embodiments, the at least one server may identify the first client terminal and the second client terminal from among the plurality of client terminals based on a first role of a first client terminal and a second role of a second client terminal, according to the access control policy. In some embodiments, the at least one server may grant the second client terminal access to one of the plurality of data fields of the first client terminal via a hash value derived from an attribute of the data field and a signature of the first client terminal. The second client terminal may use the hash value and the signature to obtain one of the plurality of encryption keys of the first client terminal.

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

[0042] In some embodiments, the at least one server may aggregate one of the plurality of encryption keys corresponding to an encryption key from each of the plurality of client terminals. The corresponding encryption key may 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 in a transport document control hub to coordinate communication among the plurality of client terminals, wherein the plurality of data fields of the electronic document correspond to corresponding database entries in the database.

[0043] In some embodiments, the single transaction may involve a physical commodity and may include a series of sub-transactions of that physical commodity. Each of the plurality of data fields may map to one of the sub-transactions. In some embodiments, each of the sub-transactions of the physical commodity may be handled by at least one service provider (e.g., a shipper, carrier, ship operator, terminal operator). A service provider may also be referred to as a facilitator or transaction member / user.

[0044] Those skilled in the art will understand alternative embodiments of the system and method based on the study of this invention. For the purposes of the claims appended herein, these alternative embodiments are intended to be equivalent. Attached Figure Description

[0045] To facilitate identification of any particular component or action, one or more of the most significant digits in a component symbol refer to the diagram number in which that component is first introduced.

[0046] Figure 1 Illustrated explanation of a communication system.

[0047] Figure 2 The illustration illustrates an exemplary transport route 200 according to one embodiment.

[0048] Figure 3 The illustration illustrates a key storage library program 300 according to one embodiment.

[0049] Figure 4 The illustration shows the asymmetric key position 400 according to one embodiment.

[0050] Figure 5 The illustration illustrates an authentication procedure 500 according to one embodiment.

[0051] Figure 6 The illustration illustrates API interface 600 according to one embodiment.

[0052] Figure 7 The illustration illustrates an API management program 700 according to one embodiment.

[0053] Figure 8 The illustration illustrates the distribution of transport document data 800 according to one embodiment.

[0054] Figure 9 The illustration illustrates the creation of model 900 based on a transportation document according to one embodiment.

[0055] Figure 10 The illustration illustrates a sample reservation list 1000 according to one embodiment.

[0056] Figure 11 The illustration illustrates the retrieval of transport document 1100 according to one embodiment.

[0057] Figure 12 The illustration shows the creation of transport document 1200 according to one embodiment.

[0058] Figure 13 The illustration depicts an example system 1300 according to one embodiment.

[0059] Figure 14 The illustration illustrates the instance access principle 1400 according to one of the embodiments.

[0060] Figure 15 One embodiment illustrates the generation of keys and matching those keys with a user's assigned role and access principle 1500.

[0061] Figure 16 The illustration shows a procedure for encrypting data attributes based on role and access control principle 1600, according to one embodiment.

[0062] Figure 17The diagram illustrates a component relationship example 1700 according to one embodiment.

[0063] Figure 18 The diagram illustrates an instanced role list and access control principle 1800 according to one of the embodiments.

[0064] Figure 19 The illustration illustrates an example of transport documents and access control principles 1900 according to one of the embodiments.

[0065] Figure 20 The illustration illustrates an example of a transport document principle 2000 based on one of its embodiments.

[0066] Figure 21 The diagram illustrates a system layout (logic) 2100 according to one embodiment.

[0067] Figure 22 Illustrated explanation of the detailed process for submitting a role list according to one of the embodiments 2200.

[0068] Figure 23 The diagram illustrates the detailed process of reading a role list according to one of the embodiments, 2300.

[0069] Figure 24 The illustration illustrates the creation of transport documents 2400 according to one of the embodiments.

[0070] Figure 25 The illustration illustrates the update of transport documents 2500 according to one embodiment.

[0071] Figure 26 The illustration illustrates the transport file reading 2600 according to one embodiment.

[0072] Figure 27 The illustration illustrates a pre-configured 2700 according to one embodiment.

[0073] Figure 28 The illustration shows a partial pre-view 2800 according to one embodiment.

[0074] Figure 29 The illustration illustrates possible activities 2900 of a third-party non-user according to one embodiment.

[0075] Figure 30 The illustration shows, according to one embodiment, a user providing information from the system to a third party.

[0076] Figure 31 The diagram illustrates a possible loan application procedure according to one embodiment.

[0077] Figure 32The illustration illustrates a documented exchange used to support the establishment of a loan account, according to one embodiment.

[0078] Figure 33 The illustration depicts a document exchange used to support a financing application, according to one embodiment.

[0079] Figure 34 The illustration shows an example invoice based on one embodiment.

[0080] Figure 35 The illustration illustrates an example payment option according to one embodiment.

[0081] Figure 36 This is a flowchart of one method for securely sharing data from multiple sources with different client terminals according to one embodiment.

[0082] Figure 37 This is a block diagram of one embodiment of a computing device. Detailed Implementation

[0083] Data sharing among multiple parties can generate synergy and efficiency. However, data sharing becomes problematic when the data required or utilized for a single transaction (e.g., multi-level transactions, multi-party transactions, a series / sequence of sub-transactions) is confidential to one or more of the parties involved in that transaction. This problem can be particularly acute in the transportation of goods. Other businesses may also face this issue. A possible solution could be a system and procedure that uses encryption to protect data privacy while allowing appropriate parties to share relevant data within a distributed ledger system, as described herein. The systems and methods described herein can be useful in the transportation of goods and cargo. The systems and methods described herein can also be applied to other industries.

[0084] The cargo tracking system and methods described in this paper help companies and individuals track the progress of goods in the transportation process. This is achieved by having individual users provide transportation documents to the system. The system may contain a list of roles and a lookup table of rights for each role. When a user submits transportation documents to the system, the documents may contain the user's identifier and a list of roles for the individual transporter. The system can associate the listed roles of the user from the transportation documents with the rights of the roles in the lookup table. The system can process transportation documents, so users and relevant transporters can access the data after it has been encrypted. Each user in the system may have one or more defined roles. Access to each data attribute in the transportation documents can be defined by the user's role. Users can access only the data relevant to them based on their roles in the access control principles.

[0085] The system can identify transport documents submitted by the user and encrypt each data attribute of the transport document. The first encryption procedure can create an individual encryption key for each data attribute.

[0086] As an example, a transport document may have five headers and five data attributes. A first encryption procedure may encrypt the five data attributes without encrypting the five header fields. The distributed ledger may also have header fields corresponding to at least one of each encrypted data attribute. The header fields of the distributed ledger correspond to at least one of the header fields of the transport document. In some embodiments, the header fields of the distributed ledger correspond to the header fields of the transport document on a one-to-one basis. The distributed ledger header fields may not be encrypted, but the data attributes corresponding to each header field of the distributed ledger may be encrypted. A second level of encryption may be used to encrypt each of the encryption keys in the data attributes of the distributed ledger. This second level of encryption may be performed using the public keys of one or more users who have known roles in the transport procedure. The second encryption procedure may identify the user's role in the transport by associating the user role from the transport document with a lookup table. The user's public key can then be used to encrypt the encryption key corresponding to the user-related data attributes based on the user's assigned role and access principles. Various attributes (encrypted data attributes, encrypted encryption keys based on different roles, hashes (generated from encrypted data attributes), and the signature of the document initiator) can be placed into permission-based distributed ledger blockchain nodes. Some users can have their own blockchain nodes. To improve scalability and performance when using distributed ledgers, data can be placed into the nodes of users involved in the transport.

[0087] Each user in the system may have one or more assigned roles. Each transport document role list identifies the role of the user who submitted the transport document role list, and the transport document role list identifies the roles of users who may be involved in the transport. In some embodiments, the role list may track who created the role list, the user's role and the list of corresponding users, and the locator key (the creator's identifier and the transport document's reservation number).

[0088] The various embodiments described herein can be used with all types of transport documents. A common transport document is a “reservation” – a precursor document for creating a bill of lading. Although many transport documents can be used with the system of this invention, many instances may use the terms “reservation” or “reservation data.” These terms should be considered to be identical to any transport document or transport document data, respectively.

[0089] In some embodiments, relationships may exist between users that allow them to see each other's data attributes. In some embodiments, business relationships may exist built into a lookup table, allowing a user to see data that is not part of their own business. The lookup table of access rights can be derived by identifying the rights each party needs and desires, with the system controller acting as the final arbiter of the rights held by each user.

[0090] In some embodiments, the distributed ledger may represent a single transport document. In other embodiments, multiple transport documents may be incorporated into a single distributed ledger.

[0091] In some embodiments, asymmetric cryptography may be used as part or all of the encryption methods described herein.

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

[0093] exist Figure 1 The diagram illustrates the procedures used to track the status of transport in the freight corridor. Shaded ellipses represent the various parties involved in a single transport transaction and how they communicate with each other using EDI (Electronic Data Interchange). Instances of parties are shown as shippers, forwarders, carriers, terminals, customs, port authorities, and consignees.

[0094] Brief description of the parties involved

[0095] Shipper – The company or person who transports goods to the consignee.

[0096] Consignee – The person or company designated in the freight contract to transport or transfer the goods to its care.

[0097] Forwarder (or freight forwarder) – A person or business engaged in the assembly, collection, consolidation, transportation, and distribution of less-than-truckload (LTL) freight. Also, a person acting as an agent in the transshipment of goods through customs (including adequate documentation, arranging transportation, warehousing, delivery, and export clearance).

[0098] Carrier – An individual or legal entity that operates the business of transporting passengers or goods in exchange for rental income.

[0099] Ship operator – any business entity responsible for the operating costs, maintenance, and profits of a vessel. The operator may or may not be the owner of the vessel. Costs include crew wages, port charges, and hull insurance. Ocean carriers share the use of vessels through alliances or vessel-sharing agreements, and the ship owner (ship operator) of the carrier may carry transport booked through other carriers.

[0100] Terminal Operators – Maritime Terminal Operators (MTOs) provide berths, docks, warehouses or other maritime terminal facilities to ocean co-carriers who move goods in maritime foreign trade.

[0101] In addition to the parties involved in the transportation of goods, there may be other parties interested in the transportation of goods, such as government agencies (customs, inspection bureaus), financial institutions, insurance companies, etc.

[0102] Shipper 102 may initiate product transportation and provide information to other parties through direct communication. This is unidirectional communication from shipper 102 to each of the following: consignor 104, carrier 106, terminal 108, customs 110, port authority 112, consignee 114, and (if necessary) financial institutions 116 (such as banks, lenders, insurance companies, bondholders, etc.). Figure 1 As can be seen, each communication with other parties is a one-way communication with each party, where each party essentially sends some information related to the transport to the other party, and then the receiving party sends a response to the original party. Each party in the process may have developed its own proprietary technology for this form of communication. The communication protocols are not integrated to work together, so each receiving party receives the message, then responds with its own protocol and waits for a response from the other party. This process is inefficient and time-consuming.

[0103] One or more roles in transportation can be assigned to each party in a transportation contract. Figure 2 The image displays various characters. The location of each assigned character is marked by a different shade on the map. Figure 2 This is merely illustrative. Many other role positions are possible and exist in actual transactions. Figure 2 The illustration 200 shown illustrates a system for creating bookings and transporting freight worldwide. In some embodiments, a shipper 202 may initiate a transport booking by determining that goods will be collected and sent to a specific destination. Shipper 202 may create a booking request (a preliminary step in forming a commercial contract to send the goods) and specify a port authority 204 with terminals A, B, and C as shown. The shipper may also select a vessel or ship to be carried by a vessel operator 206. Shipper 202 may also specify a final consignee 208 for transport. Also in Figure 2 The text uses examples to illustrate possible transportation routes. Following a path from the origin (receiving location) to the destination (final destination), it becomes clear that numerous parties are involved. Transporting goods along this route can involve many parties, each with its own communication methods, as previously described.

[0104] The examples above do not illustrate all the parties that may be involved in transportation. Whenever goods enter a port, the port authority 204 may have several agents operating under its jurisdiction. Various inspectors may be present (e.g., for grains, livestock, fruits, and vegetables), inspectors for unauthorized dangerous goods, ITC inspectors to certify any sanctioned materials, immigration inspectors, etc. Terminal operators may be private companies with terminal facilities under their authority in several other ports. In some cases, the parties may be larger companies that must communicate upwards or downwards along a chain of subsidiaries within a higher-level organization.

[0105] This document describes various embodiments of systems and methods for creating new types of booking contracts (types of transport documents) that allow the parties involved in the agreement to track the progress of freight shipments through a single point of contact. This single point of contact provides up-to-date information that is available to all relevant parties and avoids the restrictive communication that requires each party to communicate with each other one at a time or sequentially. Updates can be continuously provided to each user as the goods move through various stages of transport. These updates may include the status of the goods, liabilities, regulatory matters, and other issues.

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

[0107] In some embodiments, a user can log onto the system and then gain access to the key vault and various assigned keys. The user can initiate the key vault program 300 ( Figure 3The user logs into the system, and the system can access the key store, causing the key store to generate a key repository for the user. The system's global user list (or global member list) records the user's basic information. This basic information may include the user's name, the user's role in any subscription, contact information, and other information related to the user's role. The system can store an image of the user's key repository in a key repository image database. The user can then log into the system to generate a public key and a private key. The private key can be stored in the user's private key repository. The system can obtain the public key from the key store and store it in a public key store. Once both keys are protected in their respective databases, the process can end. In some embodiments, the user may have pre-configured access to the key store and use a pre-existing key store in conjunction with the system as described herein.

[0108] In some embodiments, parties can track one or more keys at a time. Key location 400 ( Figure 4 In this system, a user may have the right to use their own private key 404, while the system may use the user's public key 402. Each user may have a key repository containing both the private key 404 and the public key 402. The public key may be stored in the system service provider network. The system may encrypt the data encryption key using the user's public key. This encryption may occur within the system service provider network. When the system decrypts the encrypted data encryption key (DEK), it sends the encrypted DEK to the key store network via a secure network connection 410. The key store can then use the user's private key 404 to decrypt the encrypted DEK 406 to generate a decrypted DEK in the key store network. The key store can then send the decrypted DEK 408 back to the system via a secure network connection 412. The user can use DEK 408 to decrypt encrypted data associated with that specific key.

[0109] In some embodiments, each data attribute encryption key may be encrypted using a separate public key or a separate encryption protocol, but the same public key is used to encrypt the data encryption key. Where a particular user may have a role that allows that user to see multiple data attributes in each subscription record, the above procedure may be repeated for each field accessed by the user. This encryption and decryption procedure occurs during communication between the various systems and may be invisible to those accessing the database information.

[0110] In some embodiments, the user can use authentication procedure 500 ( Figure 5The user gains access to the system. The user can access the client application 502 by providing their login name and password. The client application 502 can provide organizational authentication to the authorized user and can send a login request to the authorization token generator 506 via a secure network connection 504. The client application 502 can provide authentication information (e.g., user name and password, and any other authentication information). For example, authentication information could be an API subscription ID and a secret (e.g., a 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 are 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 subscribed API 508 via the secure network connection 504. The user gains access to the subscribed API 508 to input and / or access data.

[0111] In some embodiments, client application 502 may be a web-based portal and part of authorization token generator 506 or reservation API 508. In some embodiments, client application 502 may be client software itself, and authorization token generator 506 and reservation API 508 may be debugged to communicate with the client software. In some embodiments, authorization token generator 506 and reservation 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 reservation API 508, or client application 502 may be required to authenticate itself by authorization token generator 506 in each session. In some embodiments, the predetermined time may be set as a "timeout" security protocol to automatically log off the user after a set inactivity period.

[0112] In some embodiments, three domains of the API manager may exist, such as Figure 6The API interface 600 is shown in the diagram. In some embodiments, the API interface 600 is shown as a handshake. The API interface 600 can use a client application 602, an API management tool 604, and a blockchain API 606. The client application 602 can be an application created by a client (user) or an application specifically created to work with the API management tool 604. A user can log in to the client application 602 and submit a request (e.g., create a subscription request). The client application 602 can send an authentication request 608 (which in some embodiments may include an API subscription ID and a secret) to the API management tool 604. The authentication request 608 can produce a user authentication result 616 or an error (not shown). If the user authentication 616 is successful, the API management tool 604 can then generate an access token and send the token 610 back 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 API management tool 604 receives a token and payload request 612, API management tool 604 can provide token authentication 618. The token can then be authenticated, and the token can be resolved to an organization ID based on the token and the organization's image. The organization ID and payload request can then be sent 614 to blockchain API 606 for writing to the blockchain node.

[0113] Figure 6 The exemplary embodiments shown have three domains. Client application 602 may reside in a client application network. API management tool 604 may reside in an API management tool network, and blockchain API 606 may reside in a system service provider network. However, in some embodiments, the API management tool network and the system service provider network may be merged into a single system network. In yet other embodiments, more than three domains may be used.

[0114] In some embodiments, an API management program 700 may exist, such as Figure 7As shown herein. The API management program 700 provides users with access to the system of the present invention and authenticates users to the system upon login. Users can begin at start block 702, whereby users can access the system through the user-authenticating API management program 700, as described herein. A subscription ID may be assigned to a user by the system, or the user may choose a subscription ID (e.g., from a drop-down menu, or a set of system options) and the system records it. The subscription ID may be based on a subscription fee (based on monetary payment, barter), or it may be free. The subscription ID may be issued to regulatory agencies, payment customers, system administrators, or any other party that needs access to the system described herein. Each user may also have a secret that can be issued to the system upon login request or with each communication with the system. Once a user establishes a secret with the system, the secret may be stored in the API management program 700 or a database that the API management program 700 can access to examine the user's secret as needed. Additional or alternative steps can be taken to replace the subscription ID and secret challenge, enabling acceptable security for any form of user authentication.

[0115] The system checks the authentication against its own criteria to verify its validity (706). If authentication fails, an error (714) is reported and the process ends (716). Upon successful authentication, a token (708) is issued 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 checks the token to see if it is valid (712). If the token is invalid, an error response (714) is returned. If the token is valid, it can be resolved to an organization ID based on the token and the organization's image (718). The organization ID and payload request can then be forwarded to the blockchain API, and the process ends (716).

[0116] Payload requests can be booking request data used for booking request APIs (or other shipping document APIs). When the system confirms the token and organization ID, the data can be stored in the same database along with the booking reservation request. The data can be encrypted and stored in a blockchain database. As described herein, the data used for booking requests may contain header fields. Each data attribute may have a corresponding header field. Data attributes can be stored in the database with or without corresponding header fields. In cases where data can be stored without header fields, each data attribute may contain a pointer to the header field from which it originates, so that the data can be appropriately displayed in the appropriate field when the data is read. Similarly, header data can be useful when using encrypted data to establish relationships between parties (such as when issuing a bill of lading (B / L)).

[0117] In some embodiments, at Figure 8This document provides an overview of the procedure used to distribute encrypted data and its encryption key. The procedure can begin at start block 802, where the system encrypts the data and encryption key 804, as described herein. The system can then locate, access, or position the ledgers of the sender and various carriers using their organization IDs 806. The system can check if ledgers for all carriers can be found. If no ledgers are found, the system can return an error 810 response and the procedure ends. If ledgers for all carriers are found, the system can continue sending the data and encryption key to the ledger.

[0118] The system can then continue sending encrypted data and the encrypted data key, and can check for successful transmission (808, receive verification) in various appropriate ledgers. If the transmission is successful, the program can continue to the end block 812.

[0119] In some embodiments, the user can obtain reservation information via a reservation procedure 900, such as Figure 9 As shown in the diagram. The procedure can begin at 902 with the system performing a search for the latest version 904 of the reservation. The system can find the latest version 904 of the reservation using the unique reservation ID in the transport document database. The record may contain a ledger name. The system can search for the latest version (of the reservation) using the unique reservation ID 904. In some embodiments, the system may not find the correct data record. When this occurs, the system can generate and return an error 918. If the data record is found, the system can check the organization's access principles and check the access principle definition 906 to see what data the organization's permissions can be. If the organization does not have the access principles assigned to its role, the system can return an error 918, and the procedure ends at 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 reservations at 908. The ledger of the reservation can be located by its ledger name. The system can perform a check-related step 910, 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 is returned and the program terminates. If the data is indeed related across different distributed ledgers, the program can access the key store 912, which uses the sender's organization's private key to decrypt the data encryption key. If the key store cannot decrypt the data, an error 918 response is generated, and the program terminates. The system can then decrypt the data and key 914 and publish the decrypted information 916 to the user. The program can then proceed to the end block 920.

[0120] exist Figure 10The document displays a sample list of 1000 bookings. Here, each booking created by a shipper using the booking API can be listed and categorized based on various search criteria. The sample list of 1000 bookings may represent a database of booking records, which may be encrypted and stored in the database, as described herein.

[0121] The database instance can be seen in Table I here.

[0122]

[0123]

[0124] Figure 11 The diagram illustrates the process of retrieving a reservation 1100 already placed in the system. This process begins at start block 1102 and can continue to perform attribute verification 1104 to check whether the submitted request for the reservation contains a unique reservation ID and the sender's organization ID. In some embodiments, the system may use the reservation number, version, and the reservation provider's organization ID. The system may evaluate whether the request has the required attributes (attribute verification 1104). If the request does not have the required attributes, an error response 1116 may be generated and the process terminates 1118. If the request has the required attributes, the process may retrieve the reservation information from the transport file database and decrypt the encrypted reservation information 1106. In some embodiments, the database may be encrypted in blockchain format and stored in a distributed ledger or hyperledger. The system may check to ensure that the desired reservation is properly retrieved and decrypted 1108. If not, the system may generate an error response 1116. If the reservation is retrieved and decrypted, the system may now perform a transport role check 1110 and determine for each transporter whether its organization ID is the same as the sender's organization ID. If so, the system can collect the transporter's transport role.

[0125] The system can perform a transport role check 1110 to verify the collection of at least one transport role, and then, for the collected transport roles, the system can obtain the attributes that can be read by those roles. In some embodiments, the system performs a check to examine each transport role and identifies the attributes that the parties can be allowed to view based on the transport role check 1110. In some embodiments, attributes that the parties cannot be allowed to view are removed in the filter attribute check 1112. Upon success 1114, a success response code can be returned.

[0126] Any unresolved errors may cause the program to terminate at step 1116.

[0127] Now Figure 12The creation of a reservation is shown in section 1202. Once a user or organization receives a reservation payload request, the reservation process begins (start block 1202). The system first checks if the submitted request contains a reference reservation number and the user's organization ID 1204 (attribute verification check). If the user's organization ID and / or reservation number are not in the submitted request, the system can report error 1234 and the process can terminate 1236. If the organization ID and reservation number exist, the system can find the reservation role list using the locator key 1206. The locator key can be constructed from the reference reservation number and the user's organization ID. If the role list is not found, the system can report error 1234 and the process can terminate 1236. If the role list exists, the system can check if the reservation access policy can be defined 1208. If the access policy is not defined, the system can return error 1234 and the process can terminate 1236. If the access policy is defined, the system can check for each carrier whether the carrier's organization ID can be the same as the sender's organization ID. If one or more organization IDs can be the same, the system can collect the transport role 1210 of the transporter.

[0128] The system can then check whether at least one transport role can be collected. If no role is collected, error 1234 can be returned and the process can terminate 1236. If at least one role is identified, the system can check whether the collected transport role has access rights to create all submitted attributes of the booking data 1212. If the role does not have access rights, error 1234 can be returned and the process can terminate 1236. If the access rights are correct, the system can generate a unique booking ID 1214 for the booking. Once the booking ID is created, the system can generate an individual data encryption key 1216 for each data attribute. This key can be a symmetric key. After generating the encryption key, the system can use its data encryption key to encrypt each data attribute 1218. In some embodiments, a data encryption key (1:1 relationship) can exist for each encrypted data attribute. The system can then retrieve the transport role information for each transport party and can also retrieve the access control policy 1220 for each transport role. If the transport party has an access control policy, the system can retrieve the public key 1222 from the public key store. The system can retrieve the appropriate key for a specific organization ID associated with the party assigned to the role. For each carrier, for each readable data attribute, the system encrypts the corresponding data encryption key one by one with the carrier's public key 1224. 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 key have been successfully distributed to all ledgers of the relevant carriers 1228. In some embodiments, the ledger can return a response indicating whether the encrypted data and the encrypted data key have been successfully distributed. If the system cannot verify proper distribution, the system can generate an error code 1234 and the program can stop 1236. If the system does verify the distribution of the encrypted data and the encrypted data encryption key, the system can save the ledger name, unique reservation ID, and reservation version number in the transport document database 1230. The system can then generate a success response code 1232 and the program can end 1236.

[0129] In some embodiments, it is possible to Figure 13 The transport document control hub 1302 of system 1300 is shown in the diagram. In some embodiments, the transport document control hub 1302 may have a series of user nodes (user node 1 1306, user node 2 1324, and user node N 1342, presented for illustrative purposes and as examples). Each user node may be connected to a corresponding blockchain logic (1 to N) and own blockchain nodes (1 to N). Blockchain logic 1 1320 and blockchain nodes 11322 may be part of the transport document control hub 1302. The transport document control hub 1302 may also have an off-chain database 1304.

[0130] 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, terminal operator, consignee, shipper, etc.) can assign user nodes 1306a to 1306n to itself. Although three nodes are shown in the figures of this invention, it should be understood that this figure 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 notation “n”. Each blockchain logic in each node can also communicate with the off-chain database 1304. In some embodiments, user nodes 1306a to 1306n can access blockchain logic 1320a to 1320n to write encrypted data and the encrypted data encryption key (DEK) to one or more blockchain nodes 1322a to 1322n. The cryptographic access layers 1314a to 1314n can communicate with the blockchain logic 1320a to 1320n via network communication 1318a to 1318n. Any data sent between the cryptographic access layers 1314a to 1314n and the blockchain logic 1320a to 1320n can be encrypted. The cryptographic access layers 1314a to 1314n can perform various decryption and encryption functions based on access principles. The cryptographic access layers 1314a to 1314n can generate a symmetric data encryption key (DEK), encrypt data using the DEK, encrypt the DEK using the transporter's public key, and access the key storage areas 1312a to 1312n to decrypt the DEK. API interfaces 1316a to 1316n, cryptographic access layers 1314a to 1314n, and key storage areas 1312a to 1312n may reside in an isolated network or user nodes 1306a-n, which may be inaccessible without proper authorization. Client applications 1308a to 1308n may connect to API interfaces 1316a to 1316n to write to or retrieve data from blockchain nodes 1322a to 1322n. Client applications 1308a to 1308n may be computers, servers, or any computing device with a processor, accessing memory and network connections to communicate with blockchain APIs 1316a to 1316n. In some embodiments, the network connection may be secure. Blockchain APIs 1316a to 1316n can pass requests from client applications 1308a to 1308n to cryptographic access layers 1314a to 1314n. Client applications 1308a to 1308n may also have client application databases 1310a to 1310n. Data in client application databases 1310a to 1310n can be in plain text format.Client applications 1308a to 1308n can be searched directly in client application databases 1310a to 1310n. Users can access client applications 1308a to 1308n, then user nodes 1306a to 1306n, and then blockchain logic 1320a to 1320n through their own network connections 1318a to 1318n.

[0131] The description provided for user node 1306 can operate in a similar or identical manner to the description provided for user node 1324. In some embodiments, the described blockchain node component may be a distributed ledger. In some embodiments, the blockchain node component may be a hyperledger.

[0132] In some embodiments, access control principles can be used to determine the distribution of transported documents, such as Figure 14 As shown in the illustration. In some embodiments, each party can provide transport documents from a user node to a transport document control center. For example, an instance carrier and an instance shipper, both having client nodes, can transmit transport documents to the transport document control center. Each user node may have or be accessible an API interface, a cryptographic access layer, and a key store. In the illustrated example, a carrier can send a transport document role list to the transport document control center, while a shipper can send transport documents to the transport document control center. The transport document role list and the transport documents can be encrypted.

[0133] The transport document hub may have access control principles (access principles), which may have static and / or dynamic components, such as... Figure 14 As shown in the diagram. This static section may contain a global member list and a list of access principle documents. The global member list can be used to determine the assigned roles of members. In some embodiments, a member may have multiple assigned roles. The access principle may also have a list of access principle documents. This generally refers to document types that can be used between roles in the transport of goods. Some examples include, but are not limited to, bills of lading, terminal loading or unloading manifests, booking contracts, pre-booking contracts, etc. The access principle may have access principle documents corresponding to each transport document type. The relationship between the access principle documents and the transport document types may be 1:1, or it may be 2+:1, or it may be 1:2+. These various relationships and lookup features may generally be static. In some embodiments, the relationship between the access principle documents and the transport document types may be updated and / or modified.

[0134] In some embodiments, each of the list, data structure, database, and principles may have dynamic and static versions. The static version may be the last saved version, and the archive of each saved version may exist in the blockchain. The dynamic version may exist as a user or system update or to make changes to any item stored in memory or in the blockchain. In some embodiments, the dynamic version may exist only in temporary memory. In some embodiments, the dynamic version may be written to persistent memory or the blockchain.

[0135] In some embodiments, a dynamic portion of the access principle may exist. The access principle may have a list of dynamic role lists. In some embodiments, the dynamic role list may have a locator key that can locate the corresponding role list in the access principle. In some embodiments, the locator key can locate the role list or a transport file. The transport file may or may not be part of the access principle. A role list can be constructed from one or more transport files using a dynamic transporter. The dynamic access principle list can provide each transport file with an association with a specific access principle. In some embodiments, a role list in dynamic operation can be generated and submitted along with the transport files, the role list can be assigned to a dynamic version of a static access principle file (thus creating dynamic and static access principle files), and dynamic access principles can be assigned to other transport files. In some embodiments, dynamic access principles may exist as long as transport files exist, and the dynamic access principles control the distribution of transport files and all files associated with a particular transport number.

[0136] In some embodiments, the carrier sends a booking request to the transport document control hub. The shipper instance may be similar to the carrier instance, but the role list for distributing transport documents for the shipper can be an existing role list in the transport document control hub. When the carrier submits transport documents and the role list, the carrier may pre-create that existing role list in the transport document control hub. Requests can be sent to individual members based on the role list. The document control hub can notify each user of the booking request (or other documents). For example, it can notify a ship operator that its vessel will transport a specified container, notify a terminal operator that it will receive a vessel transporting a container, and notify a consignee to pick up the container on the estimated delivery date. In some embodiments, the system may record and log the individual responsibilities of each user in the booking request. In some embodiments, each user can provide a response to the receipt of the booking request (manually or automatically). The response document returns to the transport document control hub and is routed to the carrier. The role list may be part of a dynamic access policy, which can be used to control the distribution and sharing of files used in this transaction until the transaction is completed. In some embodiments, the system may only verify data delivery and may not require a response from the receiving party.

[0137] In some embodiments, access principles may have a global list of members (users). This global list of members (users) may be a list of all users in the system and the roles each user can take on in various transport transactions and documents. These roles may correspond to those roles used in shared transport documents (e.g., shipper, carrier, ship operator, terminal operator, etc.). Access principles may also have a list of access principle documents, each applicable to a transport document type (e.g., dangerous goods (DG) certificates, bills of lading, container arrival events, container departure events, etc.). Access principles may also have a list of roles, each associated with any transport document having the same locator key (e.g., carrier + booking (BKG) number). Access principles may also have a list of dynamic access principles, each associated with any transport document having the same locator key and transport document type. Dynamic access principles may define which specific party can create, update, read, and / or receive shared transport documents and can create, update, and / or read them at attribute levels. This dynamic access policy can be exported from a list of roles for a given locator key and / or an access policy file for a given shared transport file type.

[0138] When a user logs into a user node to access the Transport Document Control Center, the user is identified through login authentication. The user's client application can send a list of transport document roles to the Transport Document Control Center. The transport document user node can identify the role list type based on the transport document role list. The transport document client can obtain any one or more of the following information from the Transport Document Control Center based on the access policies:

[0139] - The role of a user from the global user list (or global member list).

[0140] - Access principle file of the role list type

[0141] - Shared access policy documents for each shared transport file type, and

[0142] - A list of dynamic access principles, which are specific to transport documents and define the access rights of each role to the transport documents.

[0143] - Any other information that links to access policies, user IDs, or user roles.

[0144] The transport document user node can verify whether a user's role is allowed by referring to the access principle document and create (update) the transport document role list. The transport document user node can then identify roles with newly assigned values ​​based on the transport document role list and further verify whether the user's role can be assigned to those roles.

[0145] The verified list of transport document roles can be encrypted and submitted to the transport document control center, and can be added to the access principles of specific locator keys.

[0146] In some embodiments, the client application can send transport files to the transport file user node. The user node can identify the file type and locator key based on the transport file. The transport file user node can obtain the following information from the transport file control center regarding access principles: -

[0147] - Dynamic access principles for transport files (at the file hub, after a transport file user node request, derived from a list of roles for a given locator key and access principles for a given transport file type, dynamic access control principles are exported from the file).

[0148] - Access principles document for transport document types

[0149] - Any other information that the user can access or has permission to access.

[0150] The user node can also identify the user's role based on the dynamic access policy. The user node can verify which roles can create (update) transport documents according to the access policy document. The user node can identify data attributes with newly assigned values ​​based on the transport document and further verify which roles can create (update) those data attributes.

[0151] In some embodiments, the verified transport document may be encrypted and submitted to the transport document control center.

[0152] For example, a carrier can submit an encrypted list of roles and encrypted shared transport documents to the transport document control center. The carrier (or other user) can first send the role list, which can then be identified by linking it to the transport document's reservation number or other document ID. Alternatively, the transport document can be sent along with (or after) the role list, and the transport document can be associated with the role list using a locator key. The role list is readable and can contain a list of roles that the carrier will notify. The role list can also have the initiator's (sender's) digital signature, allowing the role list to be associated with the initiator. The transport document can contain data representing the terms of the proposed contract (quantity, delivery, schedule, etc.). These terms can be individually encrypted as data attributes. The role list can associate the name of a specific transporter with it.

[0153] The role list can be copied from the transport file and added to the access principles unique to the transport file. Access principles can contain information about each transport party that may be involved in the transport file. The role list of the access principles provides identifiers for members who can receive data initially provided in the transport file. Each transport party on the role list can obtain the appropriate data for its specific role (function) from the transport file.

[0154] Data attributes of a transport file can be encrypted one by one using separate symmetric keys. Each symmetric key can be encrypted one by one using the public key corresponding to each transporter who may have a role in the transport file. The role of each transporter can be defined by a role list. The symmetric keys for the data attributes can then be split among each user (transporter) who needs or requests the data attributes, and the symmetric key for each data attribute destined for the appropriate transporter can be encrypted using the public key of the user. The encrypted data attributes, the encrypted encryption keys, the hash of the encrypted data attributes, and the digital signature of the file initiator can then be sent to the transporters.

[0155] In some embodiments, a transport file client may send an encrypted shared transport file, an encrypted data encryption key (DEK), a hash of encrypted data attributes, and a digital signature of the file initiator to a transport file control hub. The transport file control hub can use the transport file's locator key to locate the role list in the access policy. Based on the role list, the transport file control hub can locate the recipient list. In some embodiments, the transport file control hub may have access to decrypt the role list to obtain the recipient list. In some embodiments, a user node may provide the public key of a transporter in the role list, and the transport file control hub can locate the recipient list based on the public key. In some embodiments, a user node may provide the plaintext of the recipient list along with the transport file to the transport file control hub. The recipient list may be parties (users) in the role list. The transport file control hub can then distribute the encrypted transport file data attributes, the encrypted data encryption key, the hash of the encrypted data attributes, and the digital signature of the file initiator to write to the corresponding blockchain node according to the recipient list. The transport file control hub can check whether the file, key, hash, and signature have been successfully written to the blockchain node. If the file, key, hash, and signature are successfully written, the Transport Document Control Center can publish an event to the initiator's message broker center notifying the initiator that the transaction was successful. The Transport Document Control Center can also publish an event to the recipient list containing the encrypted transport document, the encrypted data encryption key, and the document initiator's digital signature.

[0156] The access principles contain information about each carrier (user) that may be involved in a particular transport document. The role list of the access principles provides identifiers for the users who will receive the data initially provided in the transport document. Each user on the role list can obtain the appropriate data from the transport document for their role (function).

[0157] The data attributes of the transport file can be encrypted one by one using a symmetric key generated at runtime, called the Data Encryption Key (DEK). The DEK can then be encrypted one by one using the public key corresponding to each user who has a role in the transport file and access rights to the corresponding attributes. Each user's role can be defined by a role list. Each role's access rights to each attribute can be defined by access rules. The encrypted data attributes, the encrypted DEK, the hash of the encrypted data attributes, and the digital signature of the file initiator can then be sent to the appropriate members.

[0158] In some embodiments, a user can submit a status update to the transport document control center. This status update provides data such as the receipt and unloading of a container with transport document identifier 12345, and who must receive it. The terminal status update for transport document 12345 may not find any role list. Therefore, in addition to sending the status update to the transport document control center, the update can also be buffered in the user node. Another party can then send a role list to the user node, which may have the same transport document ID (12345). The user node can then continue processing the terminal status update.

[0159] User nodes can obtain the following information from the access principles from the transport file control center:

[0160] - Dynamic access rules for dock status updates (dynamic access control rules can be exported from a list of roles for a given locator key and an access rule file for a given transport status update type).

[0161] - Access principles document for transport status update type

[0162] User nodes can identify the roles played by users based on dynamic access principles. User nodes can verify whether those roles are allowed to create transport update states according to the access principle document. User nodes can also verify whether those roles are allowed to create those data attributes for transport update states.

[0163] This verified transport status update can be encrypted and submitted to the transport document control center.

[0164] In some embodiments, user nodes can receive various files from the transport file control center based on user access principles: dynamic access principles for port status (dynamic access control principles can be derived from a role list given a locator key and an access principle file for a given transport status update type), and access principle files for transport status update types. Transport file user nodes can also identify the user's role based on dynamic access principles. Transport file user nodes can verify whether those roles are allowed to create transport status updates according to the access principle file. Transport file user nodes can also verify whether those roles can create those data attributes of the transport status update. After verification, this verified transport status update can be encrypted. The encrypted transport status update, the encryption key for the encrypted data, the hash of the encrypted data, and the user's digital signature can be submitted to the transport file control center along with the recipient list.

[0165] Now, we will illustrate the operation method with an example.

[0166] In an example of the transport operation of this invention, the following parties are involved:

[0167] Shipper: Factory A

[0168] Recipient: S-Mart

[0169] Carrier: XYZ

[0170] Route: China to USA

[0171] Goods: Toys

[0172] Container number: 5

[0173] In this example, the shipping route is XYZ, and the route is being organized to transport 5 toy containers from Factory A (located in China) to a port in the USA. The carrier generates the shipping documents for the transport.

[0174] Table II

[0175] header fields Data attributes shipper Factory A consignee S-Mart Last pier operator Long Beach, CA … … Ship operators SS Freighters carrier XYZ

[0176] The carrier is the party organizing the shipment of toys from China to the USA. The carrier then provides the shipping order to the user node in plain text via secure transmission. The user node then encrypts the data attributes and separately stores the header field. Each data attribute is encrypted and has a unique encryption key.

[0177] Table III

[0178]

[0179] *Data provided in encrypted fields does not represent actual encrypted information. The literal strings are for illustrative purposes only. "Encrypt ("Factory A", key k1)" means the literal value "Factory A" is encrypted using the "key k1".

[0180] Encrypted data can be recorded in blockchain nodes, and each data encryption key (k1 to k5 in this example) can be encrypted based on the public key of a user matching the assigned role and access principles. In this example, shipper factory A has access to all data attributes. Factory A's public key can then be used to encrypt all keys (k1, k2, k3, k4, and k5). All shipping documents can be encrypted individually. Keys can also be encrypted individually (serially or in parallel). Keys can be encrypted in batch format, as long as the individuality of each key is protected (each encrypted key can be decrypted independently and used to access the specific shipping document corresponding to the key if the key cannot decrypt any other shipping document).

[0181] Each transport role's right to read, create, or update the data attributes of transport documents may depend on access rights defined by the system. In this example scenario, a lookup table providing rules established by the system may exist, as follows:

[0182] Table IV

[0183]

[0184] Table IV illustrates the access principles for different transport roles (e.g., shipper, consignee, final destination, ship operator, carrier, etc.). D1 to D5 are data attributes encrypted using (k1 to k5). R stands for "Read," U for "Update," and C for "Create." If the consignee has access rights to D1 and D5 ("Read," "Update," or "Create"), then k1 and k5 will be encrypted using the consignee's public key.

[0185] [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 (Long Beach Terminal in the USA) can be used to encrypt k2 and k3. The public key used by the ship operator (SS freight carrier) can be used to encrypt k2 and k4, and finally, the public key used by carrier XYZ can be used to encrypt all keys (k1, k2, k3, k4, and k5). The ship operator does not need to know any information about the shipper. Information about the shipper may be invisible to the ship operator, and the data attribute key set available to the ship operator may not include keys for the shipper's data attributes.

[0186] Once the encryption of the storage keys is complete, individual users can be notified that the data is available. Each user, using their own private key, can decrypt their individual key and access the system to view the data in the distributed ledger, while other users' information remains securely encrypted.

[0187] In a more general form, a program for generating appropriate keys to access various data attributes with different owners may involve a program 1500 that generates keys and matches those keys with the user's assigned role and access principles, such as... Figure 15 As shown in the diagram. After the start block 1502, the program can generate a data encryption key 1504 for each data attribute. In some embodiments, this key may be a symmetric key. An encryption key can be formed for each data attribute. The system can retrieve the transport role 1506 for each transporter. As described herein, each party may have a transport role in a booking. This role can be any defined role in the system. Additional roles can be added to the system to accommodate additional parties whenever needed (each user may be a party to a single transport transaction, but a user is not required to be a party to a single transport transaction). In some embodiments, a single user may have one transport role. In some embodiments, a single user may have two or more transport roles. In some embodiments, a user may access the system without having a formal transport role, as described herein. The program can retrieve the access control policy 1508 for each transport role. The access control policy provides information to inform the program which data attributes each transporter can access. The program can then provide the public key for the transporter and the access control policy 1510. Here, each transporter under the access control principle may also have a public key stored in a public key store. The procedure associates the transporter's role with the access control principle to see which data attributes the transporter can access. The procedure can then retrieve the appropriate public key of the transporter. The procedure can then encrypt the corresponding data encryption key using the transporter's public key 1512. The data encryption keys can be encrypted serially, one after another. In some embodiments, the data encryption keys can be encrypted in parallel. In other embodiments, the data encryption keys can be encrypted in batches. Each data encryption key can be encrypted such 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 data attribute. It can be viewed as a one-to-many or one-to-one relationship (1:m and 1:1). Once the procedure is complete, the procedure can end 1514.

[0188] In some embodiments, a party may be added to a list of roles or access principles, but the party may not have an actual role in the transport. In some embodiments, a non-transportation role party may be a financial institution. In some embodiments, the non-transportation role party may be a regulatory or governmental authority. In some embodiments, the non-transportation role party may be an insurance company, guarantor, judicial authority, trade regulator, labor organization, or any other entity that can access or verify data against at least one data field of the system's documents, access principles, or other libraries as set forth herein.

[0189] Figure 16 Another example of a program for encrypting data attributes based on role-based and access control principles is provided. In this example 1600, five roles are presented as shipper, consignee, final dock, ship operator, and carrier. In some embodiments, there may be one party for each role. In some embodiments, there may be a party having more than one role. In still other embodiments, two or more parties may share a single role. Figure 16 The example shown in the illustration has five roles and one party for each role.

[0190] In some embodiments, the 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) using a data encryption key. Each data attribute may also have a header and data attribute fields. 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 column) 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 in 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 data, nor can the shipper create any data. On the other hand, according to Figure 16 According to the sample access control principles, carriers have the authority to create (C), read (R), and update (U). Other parties (such as consignees) may only read the H1 and H5 data corresponding to D1 and D5. The final terminal may only read the H2 and H3 data corresponding to D2 and D3. The ship operator may only read the H2 and H4 data corresponding to D2 and D4.

[0191] The data encryption keys can then be encrypted using the public key used by each party with a role matching in the access control policy. In this example, the shipper has a public key (S) that can be used to individually encrypt each data encryption key k1 to k5.pub As shown in Table 1608, the public key of the data encryption key is used to encrypt the data, as illustrated. The Shipper column in Table 1604 indicates that the Shipper will have access to read data attributes D1 through D5, but will not be able to create, delete, or update those fields. The Consignee has a public key (Co) 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). pub The consignee's public key is used to encrypt k1 and k5. The encrypted k1 and k5 can be referred to as DEK, and the consignee can have DEKs for D1 and D5, which we will 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, the vessel operator, and the carrier. Each party with a role can access its appropriate DEK through its user node in the system, and then access the data attributes corresponding to the DEK.

[0192] Figure 17The diagram illustrates embodiment 1700, which includes a transport file with a unique ID 1706 and a role list 1710. Access principle 1702 can be role-based. It can have two levels. One level can be a file object level for each role of transport file 1706 to create, update, logically delete, and read. It can also provide an attribute level that permits the creation, updating, and reading of transport file 1706. Role list access principle 1704 can also be role-based. It can also have two levels. One level can be a role list object level for each role of role list 1710 to create, update, logically delete, and read. It can also have a role attribute level that permits the creation, updating, and reading of role list 1710. In some embodiments, a role list can be assigned to transport file 1706. Role list 1710 plus transport file access principle 1702 can provide each user of the parties involved with privileges on the transport file. In some embodiments, each transport file can have its own role list and its own access principle. Each user may have roles defined on the rolling list and access defined in the access principles. The intersection between each user's role and each user's access defines the privileges of that user. The role list may apply to many different transport documents. For example, the transport role list may apply to DG documents, bills of lading, terminal loading or unloading events, or any other form of transport document 1706. These different forms of transport documents may also be referred to as document type 1714 and event type 1716. Document type 1714 and event type 1716 may define groups of supported types of transport documents 1706. In some embodiments, transport documents 1706 of document type 1714 are versioned. In some embodiments, the version number of the document may increment incrementally whenever the document is edited or modified. It can be used to support multiple versions of the same original transport document. Each transport document 1706 may have a unique ID. There may also be many kinds of role lists 1710. Transport role list 1718 and container role list 1720 are some of the possible types of role lists 1710. Transport document 1706 and role list 1710 can use locator key 1708 and locator key 1712 respectively. In some embodiments, locator key 1708 and locator key 1712 may not be encrypted. Locator key 1708 and locator key 1712 may be visible to the transport document control hub and can be used to support its (hub) functions. The locator key may allow key-based lookups (e.g., transport number) to identify the associated role list 1710 and associated transport document 1706. Transport document 1706 can be identified by its type according to access principle 1702.

[0193] Figure 18The diagram illustrates certain instanced role lists and role list principles. In some embodiments, the role list access principle locator key 1802 provides instanced headers for the "Role List Type" and "Locator Key Field". Below the "Role List Type" is the "Transport Role List", and below the locator key field are the carrier and reservation number. This diagram illustrates that the locator key field for the transport role list is the carrier and reservation number. Role list access principle instance 1804 can show categories of role list types, in which a transport role list is provided. Roles are shown as: shipper, consignee, carrier, ship operator, and terminal operator. In this instanced table, the transport role list indicates that the carrier has the authority and system privilege to create the role list. In this instance, none of the other roles can create a role list. The next table shows role attribute hierarchy instance 1806. Here, the "Role List Type" shows the "Transport Role List" in the first row and the "Role Attributes" in the second row. The individual roles from role list access principle instance 1804 are now listed in the role attribute row. The remainder of the table displays the "role" access privileges to "role attributes" used to create, read, or update (modify) the role list transportation file. The second and third rows are highlighted in bold, indicating that the shipper can read all roles in the transportation role list; however, the shipper cannot create or update any role attributes in the transportation role list. The role list instance has a role list locator key 1808 and role list content 1810. Role list locator key 1808 is illustrated with carrier XYZ and reservation number 123456. The transportation role list may contain role list content 1810, which can illustrate the identifiers of each user in their role (these identifiers are illustrative for illustrative purposes only).

[0194] Several example shipping documents (1900) are now presented. These documents may illustrate commercially relevant headers, but dummy data is used solely for illustrative purposes. Figure 19 As shown in the diagram. In some embodiments, there may be transport documents (from the terminal operator) for container departure event 1902. An instance table displays the event ID (a unique identifier for the transport document), the carrier and booking number (which allows location on the role list), and information about the intermodal container at the terminal. This information can be sent to the transport document control center and redistributed to other users identified on the role list, thus notifying each user of this particular departure event simultaneously. The transport document access policy may have three parts – “Role List Locator” key 1904, “Transport Document Access Policy” 1906, and “Transport Document Access Policy at the Departure Event Field Level” 1910. Role List Locator Key 1904 ( Figure 17Example 1708 indicates that for outbound events, a transport role list is applicable and the carrier and booking number can be used to locate the role list. The carrier and booking number can be retrieved as carrier XYZ and booking number 12345 from outbound example 1902. Transport document hierarchy principle example 1906 indicates that for outbound events, the five roles shown can read transport documents of this transport document type "Outbound Event," but only the terminal operator (the initiator of this event) role can create or update transport documents. In some embodiments, roles such as the terminal operator can also perform logical deletion of transport documents.

[0195] In some embodiments, Transport Document Schema Example 1908 can be used to illustrate the domain name (“header field”) in the left row and the data attribute type in the right row. Sample data attributes can be of any length, and the string lengths shown are merely illustrative. As illustrated in Example 1908, the Event ID is a unique ID for this Transport Document type; and the Carrier and Booking Number fields are the role list locator keys for this Transport Document type. Transport Document Principle Field Hierarchy Example 1910 provides a diagrammatic illustration of the Transport Document type (outbound event in this example) and field rows, showing the various header fields from Schema Example 1908 and Outbound Event Example 1902. The field list in rows 3 through 7 (third through seventh) of Field Hierarchy Example 1910 shows which role has what rights for each field. All roles in a single transaction can read the data, while the carrier and terminal operator can update (modify) the data. Since the Transport Document Outbound Event originates from the terminal operator's assets, only the terminal operator can create this type of Transport Document.

[0196] In some embodiments, the systems and methods described herein can be used with hazardous materials (DG), such as Figure 20As seen in the document. Dangerous goods may require special transport documents, referred to herein as Dangerous Goods Certificates (DG Certs). Dangerous goods appear in transported goods when the materials being transported may be hazardous or have a certain quantity that could pose a danger to those involved in the transport process. Examples of dangerous goods may include fuels, radioactive materials, corrosive chemicals and liquids, explosives, etc. In some embodiments 2000 of the examples, the transport documents of the DG cert instance 2002 table are shown. The header fields represent the left row and provide information categories. The data attributes in the right row show the corresponding data for each category. The role list locator information may represent the carrier and booking number. A description of the goods may also be listed. The role list locator information can be used to access the DG cert role list instance, which may be composed of the transport document access principle role list locator key 2004, the document level access principle 2006, and the field level access principle 2008. The Role List Locator Key 2004 indicates that for each outbound event, a transport role list may exist, with the "Role List Type" and carrier and booking number used as the "Locator Key Field". The Document Hierarchy Access Principles 2006 diagram illustrates a table showing the access principles for the transport document type "DG Cert" at the document hierarchy. It shows the instanced parties associated with the transport of dangerous goods and their respective Read (R), Create (C), Update (U), and Delete (D) authorities. The DG Cert Architecture Example 2010 provides the header and data attribute types of the DG certificate (transport document) for the current instance. The "DG Cert Transport Document Access Principle Example – Field Hierarchy (Fields may refer to data input fields in the file)" 2008 provides information about the transport document type (DG Cert), fields obtained from DG Cert Example 2002 and DG Cert Architecture Example 2010, and shows the individual rights of each party (user).

[0197] In the example, it is possible to Figure 21The diagram illustrates the logical system layout 2100. In some embodiments, a system for generating transport documents may exist. This system may have a transport document control hub 2102 and a first user node 2104. The transport document control hub may have a computer, which includes logic, memory, and communication devices. A message broker 2106 on the hub side can operate through computer logic. The message broker 2106 can send and receive one or more event messages 2108, 2110. An access principle store 2112 that can be stored in memory may exist. A public key store 2114 and an ID store 2116 may also exist in memory. Memory may be one or more physical devices and does not need to be physically contained within the computer. Physical memory may be distributed in a physical sense, provided the computer can access the various databases described. The ID store 2116 may have one or more users, one or more user login authentications, and one or more lists of user parameters. Memory may be a blockchain node used to store one or more of the access principles in the encrypted transport documents. The first user node 2104 may have a computer with logic, memory, and communication devices. Similar to the transport document control center, client (user) nodes 2104 and 2118 may have computer memory and may be one or more memory devices, either internal or external to the computer, as long as the computer can access such memory devices. Key stores 2120 and 2122 may be part of the user nodes and may store login ID secrets and user private keys. These key stores may be accessible by the computer. User nodes 2104 and 2118 may also have an API interface with a cryptographic access layer for electronic communication with the key store and user message brokers 2124 and 2126. The user nodes may have a portal for users to access the transport document control center, wherein the API interface is logically executable and communicates with the transport document control center message broker.

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

[0199] In some embodiments, it is possible to Figure 22See the sample flowchart 2200 for role list submission. 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 locator key (e.g., reservation number and sender's organization ID (SCAC code)) and the role list (which also includes role list types) are in the request. If so, the program may perform a role check 2206 to see if the sender's organization ID is one of the parties in the role list. If so, the program checks whether a role list access policy 2208 is defined. This step involves checking the role list access policy for that role list type. The program may then perform an access right check 2210 to look up the sender's organization's roles in the ID store and check whether the sender's roles have access rights (role list hierarchy and data fields in the role list, sometimes referred to herein as "role list field hierarchy") to create the role list and create the roles in that role list. If the process fails to produce a useful result at any point, it may terminate and return error response code 2212, and then terminate (end 2234). If all steps are successful, the process may generate encryption keys 2214 for all roles in the role list. Using these encryption keys, the process may encrypt the role list 2216. The process may generate a sender's signature 2218 by generating a hash from the encrypted role list and accessing the key store to sign the hash with the sender's private key. The process may obtain a public key 2220 for each party in the role list and encrypt the data encryption key using the party's public key according to each party's access control policy 2222. The process may package the message using the encrypted role list, the encrypted data encryption key (associated with the party's public key), the hash, and the sender's signature. The process may generate a user's signature by digitally signing the message with the user's private key. The message may be sent to the transport document control center 2223. The program can then distribute the data and encryption key 2224 by identifying the blockchain nodes of the parties involved and distributing the encrypted role list and the encrypted data encryption key to the respective blockchain nodes. The program can then check the distribution success 2226 by checking whether the encrypted data, the encrypted data encryption key, the hash, and the sender's signature were successfully distributed. The program can then publish an event with a success code 2232 to the message broker, or publish an event with an error code to the message broker 2228.

[0200] In some embodiments, the client application can create a role list and communicate with the transport document control hub via a client-side message broker and user nodes. The cryptographic access layer in the user node obtains the public key and access control principles from the hub. The access layer can then verify and strengthen the access control principles, encrypt the payload (role list), and place the message to the message broker. The message broker (client-side) can communicate with the message broker on the transport document control hub side, and the message broker on the transport document control hub side receives the message to the program to distribute encrypted data and the encrypted data key, and can then publish an event 2232 with a success code that can be sent to the client-side message broker. The client-side can respond with a success message and confirm receipt, and can create a transaction completion response.

[0201] In some embodiments, a program 2300 for reading transport files may exist, such as... Figure 23 As shown in the diagram. The procedure can begin at the start block with a given file ID (e.g., DG Cert ID) (in some embodiments, a version number may be given), transport number, sender's organization ID (e.g., SCAC (Standard Carrier Alphabet)), and a specific role list type. It proceeds to check attribute verification 2302. In this step, the procedure can check if the locator key (transport number, sender's organization ID), file ID, and role list type are valid. If so, the procedure uses the locator key of the role list and the role list type (not shown) to obtain the encrypted role list and the encryption key for the encrypted data from the sender's node 2304. If the role list cannot be found, the procedure can return error response code 2316 and then proceed to the end block 2322. If the role list is found, the procedure can check the role list relevance 2310. The procedure can check to see if the role list data in all blockchain nodes matches each other. If the role list data in any blockchain node does not match other blockchain nodes, the procedure can return error response code 2316 and then proceed to the end block 2322. If the role list data is identical across all blockchain nodes, the program can access key store 2312 to decrypt the data encryption key 2314. If the data encryption key cannot be decrypted, the program can return error response code 2316 and then proceed to end block 2322. If the data encryption key can be decrypted, the program can use the data encryption key to decrypt the role list 2318. The program can then return success response code 2320, or another option; if the program fails, it can return error response code 2316. The program can then proceed to end block 2322.

[0202] Now Figure 24The flowchart shown illustrates transport document creation 2400. In some embodiments, the program may check attribute verification 2402 by examining whether the locator key (e.g., reservation number and sender's organization ID), transport document content (e.g., DG cert), and transport document type are available in the request. The program may check whether an existing role list exists from the access policy storehouse 2404. This step may involve checking whether the access policy storehouse has an applicable role list type, and then checking an existing role list for that role list type. Transport role check 2406 (or role check only) may determine whether the sender's organization ID is a party on the role list. The program may check whether access policies can be defined at the transport document level and transport document field level 2408. The program may perform access rights check 2410 to find the sender's organization's role in the ID storehouse, and may check whether the sender's role has the correct access rights (transport document level and field level) to create a transport document of that type (e.g., DG cert) and create data within it. The program can then generate a unique transport file ID 2412 (e.g., DG cert ID) that is unique throughout the entire system. The program can generate a data encryption key 2414 for all data attributes in the transport file. The data encryption key can then be used to encrypt the data attributes in the transport file (e.g., DG cert) 2416. The program can generate a hash of the encrypted data attributes and access the key store to generate the sender's signature 2418 by signing the hash with the sender's private key. A public key 2420 can then be obtained for each party identified in the roles within the transport file. The appropriate public key can be used to encrypt the data encryption key 2422 for each party identified in the roles within the transport file. The program can package a message containing the encrypted data attributes, the encrypted data encryption key, the hash, and the sender's signature 2424. The program can then send the message 2426 to the transport file control center. The transport document control center can distribute encrypted data, keys, hashes, and sender signatures by: identifying the appropriate blockchain nodes; and distributing the encrypted transport document, encrypted data encryption key (DEK), hashes, and sender signatures to the blockchain nodes. The program can check whether the distribution was successful by having each user node respond with a success notification (2428). 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 success event notification can be published to the sender (2432). Recipients on the role list can receive publication events containing the encrypted transport document, encrypted DEK, hashes, and sender signatures (2430). The publication of an event to any recipient may depend on whether the recipient agrees to update events for a specific transport document type (e.g., "created DG cert").The receiving user node can verify integrity 2436 by calculating the hash from the encrypted transport file and obtaining the decrypted hash by decrypting the sender's signature using the sender's public key. The program can compare the decrypted hash with the hash from the encrypted transport file. The receiving node can then access the key store to decrypt the encrypted data encryption key 2438 and the transport file 2440 using the data decryption key. The client application can receive the transport file in plain text 2442. The program can then proceed to the end block 2448.

[0203] Now Figure 25The flowchart for updating transport documents 2500 is shown below. The process can continue from the start block 2502 to check attributes 2504 by verifying whether the transport document ID / locator key (e.g., reservation number and carrier organization ID (SCAC code)) and the updated transport document (e.g., DGCert) are available in the request. The process can check existing transport documents 2506. This can be determined from the blockchain ledger by searching for the transport document ID and / or locator key and transport document type. A check can be performed to see if an existing role list can be found 2508. The process can find the role list from the access policy repository by searching with one or more locator keys and / or one or more role list types. A role check 2510 can be performed to determine if the sender organization ID is a party on the role list. The process can check to see if an access policy is defined 2512. The process can obtain the transport document from a portion or the entire document by providing the "transport document type" (e.g., transport document type = "DGCert"). An access rights check 2514 can be performed to determine whether the sender's role has the access rights (at the field level) to update data values ​​in the transport file. The program can merge existing transport file attributes with the encrypted data of the submitted data attributes (if available) 2516. The program can increment the version number of the transport file 2518. The program can generate a data encryption key 2520 for new data attributes 2522 in the submitted transport file. For example, if there are 10 data fields, and 3 data fields affect a user, only the three data fields affecting that user are changed; therefore, only 3 data fields may require a new encryption key. The remaining 7 fields may not have a new key and only contain the existing old information. The program can encrypt the submitted data attributes in the transport file using the data encryption key 2524. The program can generate a hash for any newly encrypted data attributes (data fields) and access the key store to generate the sender's signature 2526 by signing the hash with the sender's private key. The program can obtain the public keys of the parties in the role list 2528. The program can encrypt the updated data encryption key using each party's public key and each party's (user's) access control principles 2530. The program can package a message containing encrypted data attributes, the encrypted data encryption key, a hash, and the sender's signature 2532. The program can send the message to the transport document control center 2532. The program can distribute the encrypted data and key by: finding the party's blockchain ledger; and distributing the encrypted transport document, the encrypted data encryption key, the hash, and the sender's signature key to the appropriate blockchain ledger 2534. A check can be performed to determine whether the encrypted transport document, the encrypted data encryption key, the hash, and the sender's signature have been successfully distributed 2536. If a success code is sent to the sender's message broker, a publication event with the success code to the sender can be executed 2550.If not saved to the transaction reference database, the program may alternatively publish an event with the error code to be sent to the sender's message broker 2554. The program may publish an event with the encrypted transport file, the encrypted data encryption key, and the sender's signature to the designated recipient 2538. The publication of the event to the recipient depends on whether the organization agrees to the transport file update event (e.g., "Updated DG Cert"). The event payload may contain the encrypted transport file, the encrypted DEK, and the sender's signature. The recipient user node may check integrity 2540 by calculating the hash from the encrypted transport file and obtaining the decrypted hash by decrypting the sender's signature using the sender's public key. The program may compare the decrypted hash with the hash from the encrypted transport file. If integrity check 2540 fails, the program may return an error response code to the recipient 2548. If integrity check succeeds, the recipient node may then access the key store to decrypt the data encryption key 2542 and decrypt the transport file using the data decryption key 2544. The client application can receive the transport file 2546 in plain text format. The program can then proceed to the end block 2556.

[0204] Now Figure 26 The example program 2600 for reading transport documents is shown. The program begins at start block 2602 and can proceed to check if a transport document version number is available in the request, and checks the transport document version number against the transaction reference database 2604. The program can then perform attribute verification 2606 to check if the transport document ID and / or locator key (reservation number and sender's organization ID (SCAC code)) and transport document type are present in the request. The program can obtain the encrypted transport document and encrypted data encryption key from the sender's blockchain node using the transport document ID 2608. (In some embodiments, a correlation check (correlation check 2610) may be performed to see if the encrypted transport document and encrypted data encryption key from the blockchain node are identical at the content level.)

[0205] The user node can access the key store 2612 to decrypt the data encryption key (DEK) using the sender's organization's private key and retrieve the data encryption key (DEK) 2614. The user node can then decrypt the encrypted transported file 2618 using the data encryption key and can send a success response code back to the client application 2620. If the process fails at any point, it can send an error code 2616 back to the client application. The process can then terminate 2622.

[0206] In some embodiments, during one or more steps of accessing existing role lists and / or existing transport documents, the user node or transport document central authority may check the data integrity of the existing role lists and / or existing transport documents. The integrity check procedure begins by calculating a hash based on the encrypted transport document (or role list) and comparing it with an existing hash in the existing transport document (or role list). The sender's signature can be verified against their public key. If the existing hash matches the calculated hash and the sender's signature verification is successful, then it is a valid signature and the integrity of the document is maintained.

[0207] Once a user has access to the booking API, they can populate booking configuration 2700 (instance). Booking configuration 2700 may have multiple fields for data input related to cargo transportation. Fields may include, but are not limited to, identifiers of the shipper, consignee, vessel operator, forwarder, carrier, and booking party (which may be the user). Booking configuration 2700 may also include route information, container / cargo information, and other or miscellaneous information as needed. The user creating the booking can see all data attributes in the booking configuration. Additional information that the booking user can enter into booking configuration 2700 may include information that may be confidential to the user. When booking configuration 2700 is entered into the system, each field can be processed individually. For example, once a record is created, the shipper in booking configuration 2700 can view the record, but the shipper can only see the information relevant to them (e.g., the actual price of transportation disposal). In another instance, the consignee can see the information relevant to them (e.g., the location of the air-to-freight container). Version number 2702 indicates the version the user is currently viewing. Generally, users can see the latest version. In some cases, users can search for records older than the most recent one.

[0208] Now Figure 28 The image shows a sample screenshot of a partial booking view 2800 as viewed by a ship operator. This screenshot includes the carrier's identifier but may hide the identifiers of the booking party, shipper, consignor, and consignee. Additionally, information fields may be present in the route information, a portion of the container / cargo information, or other information fields that remain hidden from the ship operator's view. In this way, the user (booker) creating the partial booking view 2800 can fill in all the information relevant to each other party involved in the transport of the goods. Transport documents may contain any information that each party relies on for a part of their transaction, but which the booking party may not want to share. The booking party can define which fields they want others to see, who those other parties are, or the booking party can use a standardized set of protected fields. The system can determine which fields a user can see based on access control principles for each user's role.

[0209] In some embodiments, parties who are not users of the system under the access role principle can still gain access to specific materials and information in the system by having permissions from users under the access role principle. This non-user party can be a bank or other financial institution, a government entity (such as a port inspector), or other third parties with an ancillary interest in the transport transaction (such as an insurance company, customs agent, maintenance equipment, or any other party).

[0210] In some embodiments, a user may request a third party to access specific data within the system. Alternatively, a user may request specific information within the system that can be verified by a third-party non-user. The user may submit a verification request to the system, and the non-user may gain access to the specific information to verify statements made by the user. The process may or may not involve direct action from the system, and confidentiality between the user and the third-party non-user is maintained.

[0211] exist Figure 29 The diagram illustrates the logical relationships between the system, users, and third-party non-users. In some embodiments, registered user 2902 and user node 2908 can make requests to the document control hub 2906 through user node 2908. In some embodiments, a user can communicate with a third party 2904, who may not have any access rights to the document control hub 2906 and is not a user of the system as described herein. For example, a message broker can be configured to send messages to third party 2904 (a third-party non-user), where the message includes encrypted data from the transport document control hub. The encrypted data may be limited to data that user 2902 (or the corresponding user node 2908) can access according to access control principles and user role lists. Third party 2904 may be an organization or individual interested in user 2902's transport activities, but is not a party to the transport 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 transport agreement and needs access to certain data or files on the document control hub 2906 or any of the controlled databases supported by the systems described herein.

[0212] Specifically, for the purpose of obtaining something from a third party 2904, user 2902 may transmit documents or information to the third party 2904. This item from the third party 2904 may enable the user to participate in transportation agreements or conduct business with other users of the system. Examples may include providing funding for transportation agreements, providing financial guarantees for parties to the agreement, insurance for goods or carriers, inspection data to verify container contents upon arrival at the port, etc.

[0213] To obtain assistance from third party 2904, user 2902 may submit all files that third party 2904 can request to third party 2904 using an encrypted and secure user-to-third-party communication protocol 2912. User-to-third-party communication 2912 may include encrypted data delivered from user 2902 to third party 2904 along with a data encryption key, allowing third party 2904 to properly view the data. In some embodiments, third party 2904 may wish to verify the authenticity of data provided by user 2902. Third party 2904 may access third-party node 2910 to communicate with file control hub 2906 and request verification of data received from user 2902. Third-party node 2910 may communicate with the verification function in file control hub 2906. In some embodiments, third party 2904 may send encrypted data to file control hub 2906 via third-party node 2910 and request verification of the encrypted data. In some embodiments, third party 2904 may send encrypted data and an encrypted data encryption key for decryption. Third party 2904 may send any additional materials provided by user 2902 for verification by document control center 2906. Document control center 2906 may send the information required for verification back to third party 2904 via third party node 2910.

[0214] In some embodiments, third party 2904 may send encrypted data to third party node 2910, which may generate a hash of the encrypted data and provide that hash to compare it with the hash of the transport document recorded in file control hub 2906. Matching the hash reveals the data's authenticity, although file control hub 2906 may not actually distribute any data to third party 2904. In some embodiments, verification may be permitted using key checks and hashes of encrypted keys, or any other mechanism, existing or future, which may be suitable for use by both file control hub 2906 and user 2902's systems. Once third party 2904 can verify the authenticity of data from the user, third party 2904 may continue its internal operations to provide user 2902 with anything necessary for the user to continue their responsibilities in the transport agreement.

[0215] In some embodiments, the relationship between the file control hub 3002 (DCH), the user 3022, and the third party 3060 on the system side 3012 can be illustrated, such as Figure 30 As shown in the image. DCH 3002 may have a transport document database 3004. a It can also have other databases, such as the Access Principles Store 3004. b Public Key Store 3004 c ID storage 3004 dOr any other database used for system operation 3004 n When user 3022 needs a bank loan, user 3022 can request specific data and documents from DCH 3002. This can be done by referring to the ID store, access policy store, or any other authentication method or request for user authentication. The user can be identified in system 3012 or DCH 3002. The user may have one or more "data encryption keys" residing on the system side for encryption in the recipient library 3006. a-n Once a user request is authenticated, the DCH can retrieve the requested data from one or more databases and provide the information to the user 3022. The information can be bound to a system-generated data envelope 3006 using an encryption key for encrypted data, and then sent to the user 3022.

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

[0217] On the user 3022 side, the user's private key 3028 can be used to decrypt the encrypted data encryption key 3026. The user can then send the data encapsulation 3024 and the decrypted data encryption key 3026 to the third party 3060. The user can send the data encapsulation 3024 to the third party 3060 via a separate secure communication link 3064. Due to the encrypted nature of the data, in some embodiments, the user, DCH / system, or third party may choose to use insecure communication.

[0218] Once third party 3060 possesses the encrypted data under its control, the third-party controlled data encapsulation 3062, and the decrypted data encryption key 3026 from user 3022, third party 3060 can access DCH 3002 through a third-party node (not shown). DCH 3002 can then use the DCH-hosted verification function 3010 to verify the authenticity of the third-party request using the encrypted data in the third-party data encapsulation 3062. Third party 3060 can then receive confirmation that the information provided by user 3022 is authentic, as the hash and other data encryption elements match the hash and other data encryption elements of system 3012 and / or DCH 3002.

[0219] In some embodiments, a user may provide any amount of information to a third party as if they had also accessed it. Generally, a user may only provide information relevant to a third party's request for the information. For example, a third-party bank may request financial information, records of completed transportation agreements, and payments from parties downstream of the user. An insurance third party may request the history of transporting specific types of materials (such as dangerous goods), and the user's history regarding the number of accidents, previous insurance claims, etc. For example, a government agency may act as a third party and request information regarding the final destination of the transport, who the final buyer may be, or whether the goods will or have passed through the territory of a specific country. The type of request may be unlimited. The user may then send a data request to the system. The system may generate the data in a data encapsulation 3006. The data encapsulation 3006 may contain encrypted data, hashes, timestamps, and the sender's signature. Depending on the sender's (user's) request, the data encapsulation 3006 may contain additional or less material.

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

[0221] Now Figures 31 to 35 This document provides an example implementation of third-party functionality. In some implementations, the courier may obtain or require financial support from a bank (a non-party to the transportation transaction). To facilitate a bank lending money to the courier, the bank will conduct its normal due diligence to determine whether the courier poses an acceptable risk and is likely to repay any loan. In this example, the courier may submit loan application 3102 to a bank or other lending institution, such as... Figure 31As shown in the diagram. The bank goes through its own banking activities 3120, while the courier goes through its own courier activities 3118. In the loan application process, the courier will provide various documents and data to the bank. This can be considered the application verification step 3104. The bank then goes through its own compliance check 3106 to determine whether the courier is a trustworthy party and has good financial risk. If so, the bank can approve and disburse the loan 3110 to the courier and provide payment 3108.

[0222] The consignor may conduct its activities and execute the transportation event 3112 for which it is hired, provide the transportation documents 3114 to the interested parties, and then issue an invoice 3116 to the party who has signed a contract for the transportation event. After the transportation event is completed, the contracting party may pay the consignor, and the consignor may repay the loan.

[0223] In the process of a courier wanting to open a loan account with a bank, the courier may be involved in using a trusted storage system to provide data and document verification. For example, the courier 3202 can use a secure communication system 3204 to communicate with a bank 3206 or other financial institution to set up account 3200, such as... Figure 32 As shown in the diagram, the carrier 3202 can send the loan account application and other supporting documents to the bank via secure communication 3204. These documents may contain historical data about past transport transactions, security records, payment history, etc. Secure communication 3204 can be used to send documents between the carrier 3202 and the bank 3206. Secure communication may mean encrypting messages and attachments. Secure communication 3204 may also involve security systems such as VPNs, encoded communication channels, etc.

[0224] In this example, bank 3206 can respond to courier 3202 via the same secure communication 3204. In some embodiments, the communication can be encrypted. Secure communication 3204 may contain historical documents and loan applications (loaded account applications). Documents and account applications can be encrypted, as indicated by locks and keys. In some embodiments, the encryption mechanism can be different between the courier and the DCH. Other parties (such as carrier 3208 and terminal 3212) can also use the same system 3210. In some embodiments, the carrier and terminal can be the source of transport documents and transport events. Since a courier may be involved in the transport, the courier can obtain documents and events and provide such documents and events to the bank for use in the loan account application.

[0225] Other users of system 3210 may be involved to provide additional documentation. For example, carrier 3208 can verify that forwarder 3202 will actually be involved in a transportation transaction. Carrier 3208 can provide details such as how much cargo will be transported and to what destination. Forwarder 3202 can use this data to support how much money it needs to initiate its loan application.

[0226] Bank 3206 may request document verification and send a query to system 3210. This query may be encrypted and contain a hash. The hash can be identified and compared with the original data used to generate it. If anything matches, system 3210 can then verify the data sent by bank 3206.

[0227] In some embodiments, after the courier has set up a loan account, the courier can submit a financing application to a bank to borrow money. The bank will conduct its normal due diligence to determine whether the application is an acceptable risk and whether it can repay any money loaned to the courier. In this example, the courier can submit loan application 3304 to a bank or other lending institution, such as... Figure 33 As shown in the diagram. The consignor can collect booking confirmation documents from the carrier and transportation events from the terminal as supporting documents for loan application 3304. The completion of a transportation event, the fulfillment of project 3300, or the fulfillment of loan conditions can generate events that trigger loan repayment. For example, the arrival of transport or carrier vehicles at the terminal 3312 and the subsequent unloading of transported goods can trigger the sending of various documents 3314. Transportation events can be reported to system 3310, which can then notify all relevant parties. The carrier 3308 can be notified that the vessel has arrived and unloaded. The consignor 3302 can be notified that the goods have arrived at the destination port and the event has triggered a loan payment to the bank within a fixed time period. The bank can also receive verification that the loan to the consignor 3302 is now due after the completion of transportation. System 3310 can have various triggers and alarms built into it, so that at each stage of transportation, it can receive updates on the transportation process and send alarms to all its relevant parties.

[0228] Now Figure 34 The sample invoice is 3400.

[0229] Now Figure 35 The example payment is shown in the example. In this example, the courier can choose one or more financing options from a variety of lending institutions available to the courier. The transaction can be processed by the system, provided that each party can receive data from the system and transmit data to the system.

[0230] In some embodiments, when a container is loaded onto a terminal, the terminal operator can issue a terminal event notification to the carrier to track transport milestones. The terminal event notification includes the terminal's location, event type, date, time, carrier, and container number. The carrier then locates the relevant parties for this container and notifies them via an encrypted distributed ledger.

[0231] The use of independent encryption for each data attribute of a transport document, combined with a one-to-one relationship between the encrypted fields and the encryption key, allows any number of business participants in a joint enterprise (such as those involved in the transport of intermodal containers or project goods) to create a single transport document that arranges all aspects of the goods booking without disclosing any confidential information to any other party involved in the booking or to the public.

[0232] In some embodiments, when a container is loaded onto a terminal, the terminal operator can issue a terminal event notification to the carrier to track transport milestones. This terminal event notification includes the terminal's location, event type, date, time, carrier, and container number. The carrier then locates the relevant parties for this container and notifies them via an encrypted distributed ledger.

[0233] In some embodiments, the carrier may issue an invoice to the shipper and / or consignee upon loading for transport. The shipper and / or consignee may then pay for the invoice. The carrier then issues the original bill of lading to the shipper. The consignee may pay the shipper for the goods. The shipper may then pass the original bill of lading to the consignee to receive the goods. The carrier may verify whether the consignee has paid for the invoice (if any), and the carrier verifies the original bill of lading from the consignee and other goods release procedures. The carrier may use an encrypted distributed ledger to notify the shipper or consignee of the invoice and update the invoice after the shipper or consignee has made payment.

[0234] Now, non-restrictive aspects are provided:

[0235] 1. A method for protecting the data privacy of transport files shared among a distributed group of users, the method comprising:

[0236] The transport document is received from a user with an assigned role via a communication network, and the transport document includes multiple data attributes.

[0237] The multiple data attributes are encrypted into a similar number of encrypted data attributes by a first encryption logic, and the first encryption logic generates a data encryption key corresponding to each encrypted data attribute.

[0238] The multiple encrypted data attributes are organized into a distributed data ledger via programmatic logic, which contains at least one encrypted transport file from the user;

[0239] The encryption key corresponding to the plurality of data attributes is encrypted via a second encryption logic that uses a lookup table that provides permissions to one or more users of the distributed data ledger based on the user's assigned role.

[0240] and

[0241] The distributed data ledger is distributed to the distributed user group via this communication network;

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

[0243] Each user can only decrypt data related to the role they are assigned.

[0244] 2. The method as described in aspect 1, wherein an access principle is used to determine the multiple blockchain nodes used to write the encrypted data.

[0245] 3. The method as described in aspect 2, wherein the role assigned to the user is associated with member access control principles.

[0246] 4. The method as described in aspect 1, wherein the assigned role further includes the relationship between the transport parties.

[0247] 5. The method of aspect 1, wherein the distributed data ledger contains multiple encrypted transport files from one or more users.

[0248] 6. The method of aspect 1, wherein the transport document supplied by the user contains the user's assigned role.

[0249] 7. The method as described in aspect 1, wherein the first or second encryption logic utilizes an asymmetric cryptographic algorithm.

[0250] 8. The method of aspect 1, wherein the communication network further includes secure Internet access.

[0251] 9. A communication system for providing real-time updates on the progress of a transportation transaction to parties involved in the transaction, the system comprising:

[0252] A portal website, used to access the system via secure Internet access;

[0253] The database stores system configuration information, public keys, and reference information for transportation transactions (bookings);

[0254] A distributed ledger having nodes for users, the distributed ledger containing data relating to the user in connection with the transportation transaction; and

[0255] The program coordinates field-level encryption procedures and distributes the encrypted results to the distributed ledger;

[0256] The user is a party to the transportation transaction; and

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

[0258] 10. The communication system as described in aspect 9, wherein the portal is a client application.

[0259] 11. The communication system as described in aspect 9, wherein the distributed ledger is a super ledger.

[0260] Now for reference Figure 36 This document illustrates a flowchart of a method for securely sharing data from multiple sources with different client terminals. (The flowchart is repeated in the original text.) Figures 1 to 35 or Figure 37 Any of the components described implements or performs method 3600. In a brief overview, method 3600 may include an electronic document for establishing a transaction (3605). Method 3600 may include identifying an encryption key (3610). Method 3600 may include distributing the encryption key (3615). Method 3600 may include providing access (3620).

[0261] In further detail, method 3600 may include an electronic document (3605) for establishing a transaction. A server (e.g., a transport document control center) may identify, create, or establish the electronic document (sometimes referred to herein as a transport document). The electronic document may define, contain, or include information about a single transaction conducted through multiple client terminals (or entities). The single transaction may involve physical goods (e.g., delivery from one point to another) and may include a series of sub-transactions related to the physical goods. Each sub-transaction of the physical goods may be handled by at least one service provider (e.g., an agent, intermediary). The service provider may operate 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 establishment of the electronic document, wherein the remaining service providers access and / or facilitate the electronic document after its establishment (e.g., update the electronic document, or add information to the electronic document).

[0262] The electronic document may contain a set of data fields. Each data field of the electronic document may be associated with or mapped to one of the sub-transactions of a single transaction involving the physical goods. In the electronic document, attributes or values ​​may be assigned to each data field. The attribute of at least one of the data fields may be associated with (e.g., provided / facilitated and / or updated by) one of the client terminals involved in the single transaction (e.g., provided / facilitated and / or updated by one of the client terminals). The attribute of at least one of the data fields may originate from and / or be updated by the client terminal operated by the first entity or first service provider that initiated or created the electronic document. The data fields may contain parameters describing the transaction, such as container size, event date, port of arrival, cargo description, gross weight, vessel name, and loan account, among others. In some embodiments, the electronic document may be maintained on a database (e.g., document control hub 3002). This database may be maintained or belong to a transport document control center for coordinating communication among these client terminals. Each data field of the electronic document maintained on this database may correspond to a database item on the database.

[0263] In some embodiments, during the creation of the electronic document, the server may receive a request to set, assign, or otherwise update an attribute of one of the data fields in the electronic document. This request may originate from one of the client terminals associated with the service provider facilitating the electronic document, following the initial creation by the first entity. The service provider associated with the request may lack any (or have limited) knowledge or interaction with either the first entity, the data fields facilitating the electronic document, or other service providers offering attributes for those data fields. In this way, information from various entities can be used to populate the data fields of the electronic document in a specific manner. Some or all service providers may be introduced or involved in a single transaction (e.g., a sub-transaction or part thereof), in a specific manner (e.g., as needed or close to the time at which a service provider's role in the transaction occurs, rather than predetermined (e.g., at the time of electronic document creation). Each part or sub-transaction of a transaction may be populated or serviced by one of several available service providers, which may be dynamically matched, populated, and / or selected as the transaction develops and / or as needs / functions / sub-transactions arise. A service provider may not have knowledge of the transaction (or may have limited knowledge of the transaction) except for the function / service and / or several service providers with whom a service provider directly interfaces to perform that service provider's function / service in the transaction. The request can identify data fields in the electronic document to be updated and new attributes to be set to the data fields. The server can determine whether a client terminal has permission to modify data fields based on an access control policy for a role of the client terminal. This access control policy can specify which data fields the client terminal (or corresponding role) involved in the transaction has permission to access or modify. To determine permission, the client terminal can identify its role in the transaction. This role can be identified based on a list of roles in the sub-transaction series involved in the transaction.

[0264] When no role (or authorized / valid role) is identified for the client terminal, the server can determine that the client terminal lacks permission to modify data fields and can maintain the attributes in the data fields. Otherwise, when a role is identified, the server can identify the access control policy of the role. The server can determine whether the client terminal has permission based on the access control policy of the role identified for the client terminal. When the access control policy stipulates that the client terminal (or role) lacks permission, the server can determine that the client terminal lacks permission. The server can also prevent the client terminal that submitted the request from updating the attributes of data fields in the electronic document. Conversely, when the access control policy stipulates that the client terminal (or role) has permission, the server can determine that the client terminal has access permission. The server can allow the client terminal to update the attributes of data fields in the electronic document. In some embodiments, the server can identify attributes based on the request and assign attributes to data fields.

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

[0266] Method 3600 may include a distributed encryption key (3615). The server may provide, deliver, and distribute the encryption key across client terminals involved in a single transaction for an electronic document, according to access control principles. Access control principles may specify access permissions (e.g., decrypt, open, write, or edit) for each data field in the electronic document for each client terminal (or corresponding role). Access control principles may specify access permissions based on a role of an individual client terminal. For each data field in the electronic document, the access control principles may instruct at least two client terminals (or corresponding roles) to access the data field.

[0267] In a distributed system, the server can provide a corresponding private encryption key to each of the client terminals involved in a single transaction. This private encryption key can be used to encrypt or decrypt data fields 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 individual roles and access control principles. For example, a first role associated with a first client terminal and a second role associated with a second client terminal may be defined by access control principles as having access to one of the data fields in an electronic document. The server can encrypt the encryption key (e.g., a private encryption key) of the first client terminal using another encryption key (e.g., a public encryption key) of the second client terminal. During encryption, the server can provide the encryption key of the first client terminal to the second client terminal.

[0268] Additionally, the server can provide a public encryption key to one or more client terminals according to access control principles. For example, an access control principle might specify that two client terminals have permission to access attributes in a data field. In this instance, the server can provide a public encryption key to both client terminals. In this way, each data field in the electronic document can be accessed by one or more client terminals using either the private encryption key or the public encryption key provided to the client terminals.

[0269] In some embodiments, the server may determine whether the distribution of the encryption key across one of the client terminals was successful. Based on this determination, the server may transmit, send, or provide a message (e.g., an event notification) to one or more of the client terminals. When the distribution is determined to be successful, the server may issue or provide a success code to one or more of the client terminals (such as a client terminal requesting to update one of the data fields in an electronic document). Conversely, when the distribution is determined to be unsuccessful, the server may issue or provide an error code to one or more of the client terminals.

[0270] In some embodiments, the server may identify a hash value derived from a corresponding attribute in one of the data fields of an electronic document. This hash value may be generated using hash functions (such as cyclic redundancy check, summation check codes, password hash functions, and message authentication codes, etc.). The hash value may be generated by the client terminal that provides the attribute to the data field in the electronic document. This hash value may be used to ensure the data integrity of the attribute assigned to the data field in the electronic document. The server may also distribute the hash value across client terminals according to access control principles.

[0271] In some embodiments, the server may receive or recognize a signature for each client terminal involved in a single transaction. The signature may be generated by applying an encryption key corresponding to the client terminal to a hash value derived from an attribute of a data field provided by the client terminal. The signature may be generated by the server or by the client terminal providing the attribute. The signature may be used to ensure the data integrity of attributes in data fields within an electronic document.

[0272] Method 3600 may include providing access (3620). The server may provide access to one or more data fields in an electronic document to each client terminal using an encryption key distributed according to access control principles. In some embodiments, the server may input, provide, generate, and / or maintain attributes of data fields or electronic documents. In some embodiments, the server may receive a request to access one or more data fields of an electronic document using an identifier from one of the client terminals (e.g., a transport document identifier or reservation number, carrier organization). The server may determine whether the electronic document referenced by the identifier exists in the database. If the electronic document does not exist, the server may return an error message. Conversely, if the electronic document exists, the server may continue to verify whether the client terminal accesses the data field. Each client terminal may be able to access the data field to which the client terminal provides attributes using a corresponding encryption key provided to the client terminal. Additionally, each client terminal may be able to access the data field using a corresponding encryption key provided to the client terminal, as specified by the access control principles.

[0273] In some embodiments, the server may provide access to one of the data fields in an electronic document to two or more client terminals identified based on roles and access control principles. A hash value and signature of the data field in the electronic document may be provided to each of the identified clients. The hash value can be derived from the attribute in the data field, and a signature can be generated using the hash value of the client terminal providing the attribute and an encryption key (e.g., the public encryption key). Using the hash value and signature, other client terminals can obtain the encryption key to access the attribute 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 a decrypted hash value. The client terminals can then compare the decrypted hash value with the hash value to determine integrity. When the hash values ​​match, the client terminal can determine that the attribute has data integrity. Otherwise, when the hash values ​​do not match, the client terminal can determine that the attribute lacks data integrity.

[0274] Now for reference Figure 37 The computer 3700 may include one or more processors 3705, volatile memory 3710 (e.g., random access memory (RAM)), non-volatile memory 3720 (e.g., one or more hard disk drives (HDDs) or other magnetic or optical storage media, one or more solid-state drives (SSDs) (such as a flash disk drive or other solid-state storage media), one or more hybrid magnetic and solid-state drives and / or one or more virtual storage capacities (such as a cloud storage device) or a combination of such physical storage capacities and virtual storage capacities or arrays thereof), a user interface (UI) 3725, one or more communication interfaces 3715, and a communication bus 3730. The user interface 3725 may include a graphical user interface (GUI) 3750 (e.g., a touch screen, a display, etc.) and one or more input / output (I / O) devices 3755 (e.g., a mouse, a keyboard, a microphone, one or more speakers, one or more cameras, one or more bio-scanners, one or more environmental sensors, one or more accelerometers, etc.). Non-volatile memory 3720 stores operating system 3735, one or more application programs 3740, and data 3745, such that (for example) computer instructions of operating system 3735 and / or application programs 3740 are executed by processor 3705 outside of volatile memory 3710. In some embodiments, volatile memory 3710 may include one or more types of RAM and / or a cache that provides a response time faster than main memory. Data can be input or received from I / O device 3755 using one of the input devices of GUI 3750. Various components of computer 3700 can communicate via one or more communication buses shown as communication buses 3730.

[0275] like Figure 37The computer 3700 shown herein (by way of example only) is a client, server, intermediary, and other networked device, and can be implemented in any computing or processing environment using any type of machine or set of machines capable of operating as described herein with suitable hardware and / or software. The processor 3705 can be implemented by one or more programmable processors to execute one or more executable instructions, such as a computer program, to perform the functions of the system. As used herein, the term "processor" describes a circuit system that performs a function, an operation, or a sequence of operations. The function, operation, or sequence of operations may be hard-coded into the circuit system or software-coded using instructions stored in a memory device and executed by the circuit system. A "processor" can perform the function, operation, or sequence of operations using digital values ​​and / or analog signals. In some embodiments, the "processor" may be embodied in one or more application-specific integrated circuits (ASICs), microprocessors, digital signal processors (DSPs), graphics processing units (GPUs), microcontrollers, field-programmable gate arrays (FPGAs), programmable logic arrays (PLAs), multi-core processors, or general-purpose computers with associated memory. The "processor" may be analog, digital, or mixed-signal. In some embodiments, the "processor" may be one or more physical processors or one or more "virtual" (e.g., remotely located or "cloud-based") processors. A processor comprising one or more processor cores and / or multiple processors may provide the functionality of parallel simultaneous execution of several instructions on one or more data devices or parallel simultaneous execution of one instruction on one or more data devices.

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

[0277] The objects and embodiments of operation described in this specification can be implemented in digital electronic circuits or in computer software, firmware, or hardware (including the structures disclosed in this specification and their structural equivalents), or a combination thereof. Embodiments of the objects described in this specification can also be implemented as one or more computer programs, that is, one or more computer program instruction modules encoded on one or more computer storage media for execution by a data processing device (such as a processing circuit) or for controlling the operation of a data processing device. A controller or processing circuit (such as a CPU) may include any digital and / or analog circuit components configured to perform the functions described herein, such as a microprocessor, microcontroller, application-specific integrated circuit, programmable logic, etc. Alternatively or additionally, program instructions may be encoded on an artificially generated propagation signal (e.g., a machine-generated electrical, optical, or electromagnetic signal) that is generated to encode information for transmission to a suitable receiver device for execution by a data processing device.

[0278] Computer storage media may be or be included in one or more of the following: a computer-readable storage device, a computer-readable storage substrate, a random or serial access memory array or device, or a combination thereof. Furthermore, although computer storage media is not a propagating signal, it may be a source or destination of computer program instructions encoded in an artificially generated propagating signal. The computer storage media may also be one or more individual components or media (e.g., multiple CDs, disks, or other storage devices), or contained within one or more individual components or media. Therefore, the computer storage media is both tangible and non-transitory.

[0279] The operations described in this specification can be performed by a data processing device on data stored on one or more computer-readable storage devices or received from other sources. The terms "data processing device" or "computing device" encompass all kinds of devices, apparatuses, and machines for processing data, including, by way of example, a programmable processor, a computer, a system-on-a-chip, or many or combinations of the foregoing. The device may include special-purpose logic circuitry systems, such as FPGAs (Field Programmable Gate Arrays) or ASICs (Application-Specific Integrated Circuits). In addition to hardware, the device may also include program code that creates an execution environment for the computer program in question, such as program code constituting processor firmware, protocol stacks, database management systems, operating systems, cross-platform runtime environments, virtual machines, or combinations thereof. The device and execution environment can implement various computing model infrastructures, such as web services, distributed computing, and grid computing infrastructures.

[0280] Computer programs (also known as programs, software, software applications, descriptive languages, or program code) can be written using any form of programming language, including compiled or interpreted languages, declarative or procedural languages, and can be deployed in any form, including as standalone programs or as modules, components, subroutines, objects, or other units 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 may be stored in a portion of a file that stores other programs or data (e.g., stored in one or more descriptive languages ​​in a markup language file), in a single file dedicated to the program in question, or in multiple coordinated files (e.g., a document storing one or more modules, subroutines, or portions of program code). A computer program can be deployed to execute on one computer or on multiple computers (located at a single point or distributed across multiple points and interconnected by a communication network).

[0281] The programs 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 manipulating input data and generating output. These programs and logic flows can also be executed by special purpose logic circuit systems (e.g., FPGAs (Field Programmable Gate Arrays) or ASICs (Application-Specific Integrated Circuits)), and the device can also be implemented as such a special purpose logic circuit system.

[0282] For example, a processor suitable for executing computer programs includes, by way of instance, both general-purpose microprocessors and special-purpose microprocessors, as well as one or more processors of any type of digital computer. Generally, a processor receives instructions and data from read-only memory or random access memory, or both. The basic components of a computer are a processor for performing actions according to instructions and one or more memory devices for storing instructions and data. Generally, a computer will also include one or more mass storage devices (e.g., disks, magneto-optical disks, or optical disks) for storing data, or be operatively coupled to receive data from, transfer data to, or both receive and transfer data from such mass storage devices. However, a computer does not necessarily have such devices. Furthermore, a computer may be embedded in another device, such as a mobile phone, a personal digital assistant (PDA), a mobile audio or video player, a game console, a global positioning system (GPS) receiver, or a portable storage device (e.g., a universal serial bus (USB) flash drive) (to name just 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 (e.g., EPROM, EEPROM, and flash memory devices); magnetic disks (e.g., internal hard disks or removable disks); magneto-optical disks; and CD-ROMs and DVD-ROMs. The processor and the memory may be supplemented by or incorporated into a special purpose logic circuit system.

[0283] To provide interaction with a user, embodiments of the target object described in this specification can be implemented on a computer having: a display device, such as a CRT (cathode ray tube) or LCD (liquid crystal display) monitor, OLED (organic light-emitting diode) monitor, or other form of display for displaying information to a user; and a keyboard; and / or a pointing device, such as a mouse or a trackball, through which the user 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 the input from the user can be received in any form, including sound, voice, or tactile input. Additionally, a computer can interact with a user by sending and receiving files from a device used by the user; for example, by sending a webpage to a web browser in response to a request received from a web browser on a user's client device.

[0284] While this specification contains numerous details of specific embodiments, such details should not be construed as limiting the scope of any embodiment or claim, but rather as descriptions of features specific to particular embodiments. Specific features set forth in this specification within the context of a single embodiment may also be implemented in combination within a single embodiment. Conversely, various features set forth in the context of a single embodiment may also be implemented individually or in any suitable sub-combination in multiple embodiments. Furthermore, although features may be described above as operating in a particular combination, and even initially claimed to be so, in some cases, one or more features may be removed from a claimed combination, and a claimed combination may be for a sub-combination or a variation thereof.

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

[0286] A reference to “or” can be interpreted as inclusive, such that any term used with “or” can refer to a single, more than, or any of the terms used.

[0287] Therefore, specific embodiments of the target object have been described. Other embodiments exist within the scope of the appended claims. In some cases, the actions described in the claims can be performed in a different order and still achieve the desired result. Furthermore, the procedures illustrated in the drawings do not necessarily require the specific order or sequence shown to achieve the desired result. In certain embodiments, multitasking and parallel processing may be advantageous.

[0288] Specific embodiments of the methods and systems have been described, and it will now be apparent to those skilled in the art that other embodiments incorporated herein can be used. It should be understood that the systems described above may provide any or more of those components, and such components may be disposed on a single machine or, in some embodiments, on multiple machines in a distributed system. The systems and methods described above can be implemented as a method, apparatus, or component using programming and / or engineering techniques to produce software, firmware, hardware, or any combination thereof. Furthermore, the systems and methods described above may be provided as one or more computer-readable programs embodied in or in one or more components. As used herein, the term "device" is intended to encompass program code or logic accessible from and embedded in one or more computer-readable devices, firmware, programmable logic, memory devices (e.g., EEPROM, ROM, PROM, RAM, SRAM, etc.), hardware (e.g., integrated circuit chips, field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), etc.), electronic devices, and a computer-readable non-volatile storage unit (e.g., CD-ROM, floppy disk, hard disk drive, etc.). A device may be accessible from a file server that provides access to a computer-readable program via a network transmission line, wireless transmission media, signals propagating through space, radio waves, infrared signals, etc. A device may be a flash memory card or a magnetic tape. A device comprises hardware logic and software or programmable code embedded in a computer-readable medium and executed by a processor. Generally, a computer-readable program can be implemented in any programming language (such as LISP, PERL, C, C++, C#, PROLOG) or in any bytecode language (such as JAVA). Software programs can be stored as object program code on or in one or more components.

Claims

1. A method for generating keys for accessing multiple data attributes, the multiple data attributes having different owners as part of a zero-trust communication system, wherein the multiple data attributes are part of a shared transport file of goods maintained on a server, the method comprising: At least one processor generates a data encryption key for the data attributes of the plurality of data attributes; The at least one processor retrieves the transport role for the transporter from memory; The at least one processor retrieves the access control principles corresponding to the transport role from the memory; Use this access control principle to retrieve one or more public keys for the transporter; and The at least one processor uses one or more public keys of the transporter to encrypt the data encryption key to establish an encrypted data encryption key for the data attributes of the plurality of data attributes.

2. The method of claim 1, wherein the transporter has two or more transport roles.

3. The method of claim 1, wherein the access control principle defines which portion of the plurality of data attributes the transporter can access.

4. The method of claim 1, wherein the public key is retrieved from a public key repository.

5. The method of claim 1, wherein the access control principle includes information about which parts of the plurality of data attributes each transport party is allowed to access.

6. The method of claim 1, wherein the shared transport document is an electronic document.

7. The method of claim 1, wherein the shared transport document is a reservation.

8. The method of claim 1, wherein the access control principle is dynamically updatable.

9. The method of claim 1, further comprising: Based on the transporter's role, the encrypted key for the encrypted data and the encrypted version of the data attributes are distributed to the transporter.

10. The method of claim 1, wherein the transporter further includes a government agency, financial institution, or trade organization interested in the shared transport document for the goods.

11. A method for securely sharing data from multiple sources with different client terminals, the method comprising: A transport document is established by at least one server having one or more processors, defining multiple data attributes for multiple transport parties. The transport document has multiple data fields, each of which is associated with one of multiple client terminals, each of which corresponds to one of multiple transport parties. The at least one server identifies at least one encryption key to encrypt at least one data field from the plurality of data fields contained in the transport document to form an encrypted data field; The at least one server distributes the at least one encryption key to at least one of the plurality of client terminals in accordance with access control principles, which specify the access permissions of the corresponding client terminals to one or more of the plurality of data fields based on the transport role of the corresponding transport party in the transport document. and The at least one server distributes the encrypted data fields and at least one encryption key in the transport file to at least one of the plurality of client terminals in accordance with the access control policy, wherein the access control policy instructs that different subsets of the plurality of encryption keys corresponding to different fields in the transport file be distributed to different client terminals based on the corresponding access permissions.

12. The method of claim 11, wherein establishing the transport document further comprises: The first client terminal of the plurality of client terminals receives a request to update the attribute of the first data field of the plurality of data fields in the transport document; Based on the access control principle, the first client terminal is determined to have the permission to modify the first data field according to its reserved role. and In response to determining that the first client terminal has the permission, the client terminal is permitted to update the attribute of the first data field in the transport document.

13. The method of claim 11, wherein identifying the at least one encryption key further comprises identifying a private encryption key and a public encryption key for the plurality of client terminals; and The distribution of the encryption key further includes: Provide the private encryption key to the corresponding client terminals of the multiple client terminals; and The public encryption key is provided to at least one of the plurality of client terminals in accordance with the access control principle, and at least one of the plurality of data fields in the transport document can be accessed by at least two of the plurality of client terminals using the private encryption key and the public encryption key.

14. The method of claim 11, further comprising: By using the at least one server to identify multiple hash values ​​derived from the corresponding multiple attributes in the multiple data fields of the transport file, each of the multiple hash values ​​ensures the data integrity of one of the multiple attributes; and The first signature is generated by the at least one server for the first client terminal among the plurality of client terminals using the first hash value among the plurality of hash values ​​and the first encryption key among the plurality of encryption keys. The first hash value is derived from the first attribute among the plurality of attributes. The first encryption key is for the first data field among the plurality of data fields corresponding to the first attribute. The first signature ensures the data integrity of the first attribute and the first data field.

15. The method of claim 11, further comprising: The at least one server determines whether the distribution of at least one of the plurality of encryption keys and at least one of the encrypted data fields across the plurality of client terminals is successful; and The event notification is provided to at least one of the plurality of client terminals by the at least one server determining whether the distribution of the encryption key and the encrypted data field is successful.

16. The method of claim 11, wherein the transport of goods is a combined transport container.

17. A system for securely sharing data from multiple sources with different client terminals, comprising: At least one server having one or more processors is configured to: Establish a shared transport file for defining at least one parameter for the transport of goods. The shared transport file includes a series of data inputs for multiple transport parties. The shared transport file has multiple data fields, each of which is associated with one of multiple client terminals, each of which corresponds to one of multiple transport parties. Identify multiple encryption keys to encrypt corresponding data fields contained in the shared transport file; The multiple encryption keys are distributed across the multiple client terminals according to the access control principles, which specify the access permissions of the corresponding client terminals to one or more of the multiple data fields based on the corresponding transport role in the reservation. and Access to at least one of the multiple data fields in the shared transport file is granted to each of the multiple client terminals via the multiple encryption keys distributed in accordance with the access control principle.

18. The system of claim 17, wherein the at least one server is further configured to: The first client terminal of the plurality of client terminals receives a request to update the attribute of the first data field of the plurality of data fields in the shared transport file; Based on the access control principle, the first client terminal is determined to have the permission to modify the first data field according to its role in the separate reservation; and In response to determining that the first client terminal has the permission, the client terminal is permitted to update the attribute of the first data field in the shared transport file.

19. The system of claim 17, wherein the at least one server is further configured to: Identify multiple hash values ​​derived from corresponding attributes in the multiple data fields of the shared transport file, each of the multiple hash values ​​ensuring the data integrity of one of the multiple attributes; and For the first client terminal among the plurality of client terminals, a first hash value among the plurality of hash values ​​and a first encryption key among the plurality of encryption keys are used to generate a first signature. The first hash value is derived from a first attribute among the plurality of attributes. The first encryption key is for a first data field among the plurality of data fields corresponding to the first attribute. The first signature ensures the data integrity of the first attribute and the first data field.

20. The system of claim 17, wherein the transport of goods is a combined transport container.

Images