Storage management based on message feedback

Abstract

Disclosed herein are methods, systems, and devices for managing blockchain-based event messages, including computer programs encoded on computer storage media. One of the methods includes: based on initiating a consensus algorithm through a blockchain node associated with a computing system, storing shipping data and shipping insurance order data associated with a purchase order on a blockchain; determining whether the shipping insurance order associated with the shipping insurance order data is valid; generating an event message dedicated to notifying an insurance provider that the shipping insurance for the purchase order is valid; storing the event message in a hardware cache managed by the computing system; sending the event message to a blockchain node associated with the insurance provider; and processing the event message in response to receiving a feedback message from the blockchain node associated with the insurance provider.

Description

Technical Field

[0001] This article deals with providing a blockchain-based messaging service for storage management. Background Art

[0002] A distributed ledger system (DLS), which may also be referred to as a consensus network and / or a blockchain network, enables participating entities to store data securely and immutably. Without reference to any specific use case, a DLS is often referred to as a blockchain network. Examples of types of blockchain networks may include public blockchain networks, private blockchain networks, and consortium blockchain networks. A consortium blockchain network is provided for a selected group of entities that controls the consensus process and includes an access control layer.

[0003] Digital networks have made it possible for people around the world to find information and interact with each other easily and efficiently. For example, social media platforms make it easy for people to share messages, photos, and videos with friends and colleagues. Online shopping sites allow consumers to easily find information about a wide range of products and purchase products from merchants around the world through electronic payments. Various payment and delivery services make it easier for e-commerce providers and consumers to conduct online and international transactions and shipments. As more people connect to the Internet and more transactions are conducted digitally online, the need for protection of valuables during transportation and the data that will be processed by insurance companies to provide transportation protection are increasing.

[0004] Parties such as online shopping platforms, delivery service providers, and insurance companies are often involved in providing transportation insurance. Many data exchanges may take place between the parties to fulfill each transportation insurance order and finalize the insurance payment. The data and messages exchanged between the parties are usually communicated through point-to-point communication, which makes it difficult to verify the authenticity of the data and recover from data loss. Moreover, the data provided by different parties may be inconsistent, which reduces the efficiency of the processing of transportation insurance and the allocation of insurance premiums.

[0005] It is expected that there will be a unified platform that can provide transparent, effective, consistent and verifiable data and message services to facilitate the processing and storage of transportation insurance data while ensuring data privacy and integrity for all parties involved. Summary of the invention

[0006] Embodiments of the described subject matter may include one or more features alone or in combination.

[0007] For example, in one embodiment, a computer-implemented method executed by a computing system includes: receiving shipping data and shipping insurance order data associated with a purchase order; determining whether the shipping insurance order corresponding to the shipping insurance order data is valid by executing a first smart contract based on the shipping data and one or more first predetermined rules; in response to determining that the shipping insurance order is valid, initiating a consensus algorithm to record the shipping data and the shipping insurance order data on a blockchain; generating a first event message by executing the first smart contract, the first event message including a notification that the shipping insurance for the purchase order is valid; receiving shipping insurance premium allocation data, the shipping insurance premium allocation data indicating the allocation of the shipping insurance premium associated with the shipping insurance order to one or more service providers; determining that the allocation of the shipping insurance premium is legal by executing a second smart contract based on one or more second predetermined rules; initiating the consensus algorithm of the blockchain network to record the shipping insurance premium allocation data on the blockchain; generating a second event message by executing the second smart contract, the second event message notifying that the shipping insurance premium is allocated according to the shipping insurance premium allocation data.

[0008] In some embodiments, the first event message and the second event message are stored as transactions on the blockchain.

[0009] In some embodiments, the first event message is included in a plurality of event messages to an insurance provider, and the first event message is transmitted to the insurance provider via a blockchain node associated with the insurance provider, and wherein the transportation insurance premium is received in response to transmitting the first event message to the insurance provider.

[0010] In some embodiments, the second event message is included in a plurality of event messages to the one or more service providers.

[0011] In some embodiments, the shipping data is received from a delivery service provider and verifies that the purchase order was shipped by the delivery service provider.

[0012] In some embodiments, the one or more first predetermined rules include one or more of the coverage of the declared value of the purchase order, the items covered by the shipping insurance, or the insurance limit of the purchase order, and wherein the shipping insurance order is valid when the purchase order satisfies the one or more first predetermined rules.

[0013] In some embodiments, the transportation insurance order is received from a transportation insurance service platform or an e-commerce platform, and wherein the transportation insurance order indicates one or more of the insurance items, insurance premiums, the declared value of the purchase order, or the insurance included in the purchase order.

[0014] In some embodiments, the consensus algorithm is one of Proof of Work (PoW), Proof of Stake (PoS), or Practical Byzantine Fault Tolerance (PBFT).

[0015] In some embodiments, the one or more service providers include one or more of the service system, a transportation insurance service platform, or an insurance provider.

[0016] In some embodiments, the one or more second predetermined rules provide a transportation insurance premium allocation plan agreed upon by the service system, the transportation insurance service platform, or the insurance provider.

[0017] In some embodiments, in response to determining that the transportation insurance order is valid, the service system withholds the insurance premium, and in response to determining that the allocation of the transportation insurance premium is legal, the insurance premium is allocated to the service system, the transportation insurance service platform and the insurance provider according to the one or more second predetermined rules.

[0018] In another embodiment, a computer-implemented method executed by a blockchain node of a blockchain network includes: storing shipping data and shipping insurance order data associated with a purchase order on a blockchain based on a consensus algorithm initiated by a blockchain node associated with a computing system; determining whether a shipping insurance order associated with the shipping insurance order data is valid by executing a smart contract based on the shipping data and one or more first predetermined rules; in response to determining that the shipping insurance order is valid, generating an event message dedicated to notifying an insurance provider that the shipping insurance for the purchase order is valid by executing the smart contract; storing the event message in a hardware cache managed by the computing system; sending the event message to a blockchain node associated with the insurance provider; and, in response to receiving a feedback message from the blockchain node associated with the insurance provider, processing the event message.

[0019] In certain embodiments, the feedback message indicates that the event message is received by the blockchain node associated with the insurance provider, and processing the event message includes: storing the event message on the blockchain based on executing the consensus algorithm; and deleting the event message from the hardware cache.

[0020] In some embodiments, when the feedback message indicates that the event message was not correctly received or was not received within a predetermined time period, processing the event message includes resending the event message to the blockchain node associated with the insurance provider. In some embodiments, the event message is sent periodically until the feedback message is received.

[0021] In some embodiments, the event message is a first event message, the smart contract is a first smart contract, the feedback message is a first feedback message, and the method further includes: receiving a second event message for one or more service providers from the blockchain node associated with the insurance provider, wherein the second event message notifies the allocation of the transportation insurance premium associated with the transportation insurance order to one or more service providers; sending a second feedback message to the blockchain node associated with the insurance provider to indicate that the second event message is correctly received; determining that the allocation of the transportation insurance premium is legal by executing a second smart contract based on one or more second predetermined rules; storing the second event message on the blockchain based on the consensus algorithm; and sending the second event message to the one or more service providers.

[0022] In some embodiments, the method further includes: in response to transmitting the first event message to the insurance provider, receiving transportation insurance premium allocation data from the blockchain node associated with the insurance provider; and storing the transportation insurance premium allocation data on the blockchain based on the consensus algorithm.

[0023] In some embodiments, the one or more service providers include one or more of a service system, a transportation insurance service platform, or an insurance provider. In some embodiments, the one or more second predetermined rules provide an insurance premium allocation plan agreed to by the service system, the transportation insurance service platform, or the transportation insurance provider.

[0024] In some embodiments, the one or more first predetermined rules include one or more of the coverage of the declared value of the purchase order, the items covered by the shipping insurance, or the insurance limit of the purchase order, and wherein the shipping insurance order is valid when the purchase order satisfies the one or more first predetermined rules.

[0025] In some embodiments, the shipping insurance order indicates one or more of insurance items, insurance premiums, a declared value of the purchase order, or insurance included in the purchase order.

[0026] It should be understood that the method described herein may include any combination of the various aspects and features described herein. That is, the method described herein is not limited to the combination of the various aspects and features specifically described herein, but also includes any combination of the various aspects and features provided.

[0027] The details of one or more embodiments of the present invention will be set forth in the accompanying drawings and the following description. Other features and advantages of the present invention will be apparent from the description and drawings, and from the claims. BRIEF DESCRIPTION OF THE DRAWINGS

[0028] Figure 1 is a diagram illustrating an example of an environment that can be used to perform embodiments herein.

[0029] Figure 2 is a diagram illustrating an example of an architecture according to an embodiment of the present invention.

[0030] Figure 3 is a swim lane diagram illustrating an example of a message flow according to an embodiment of the present invention.

[0031] Figure 4 is a diagram illustrating an example of an internal system of a service provider according to an embodiment of this document.

[0032] Figure 5 is a relationship diagram showing an example of the relationship between sub-models of the transportation insurance data model according to an embodiment of this document.

[0033] Figure 6 is a diagram illustrating an example of a process of providing message feedback according to an embodiment of this document.

[0034] Figure 7 An example of a system according to embodiments herein is depicted.

[0035] Figure 8 Depicted are examples of processes that may be performed according to embodiments herein.

[0036] Fig. 9 Examples of modules of an apparatus according to embodiments herein are depicted.

[0037] Fig.10 Another example of a process that may be performed according to embodiments herein is depicted.

[0038] Fig.11 Another example of modules of an apparatus according to embodiments herein is depicted.

[0039] Like reference numbers and designations throughout the various drawings represent like elements. DETAILED DESCRIPTION

[0040] The present invention describes technologies for blockchain-based message services. These technologies generally involve: receiving shipping data and shipping insurance order data associated with a purchase order; determining whether the shipping insurance order corresponding to the shipping insurance order data is valid by executing a first smart contract based on the shipping data and one or more first predetermined rules; in response to determining that the shipping insurance order is valid, initiating a consensus algorithm to record the shipping data and the shipping insurance order data on a blockchain; generating a first event message by executing the first smart contract, the first event message including a notification that the shipping insurance for the purchase order is valid; receiving shipping insurance premium allocation data, the shipping insurance premium allocation data indicating the allocation of the shipping insurance premium associated with the shipping insurance order to one or more service providers; determining that the allocation of the shipping insurance premium is legal by executing a second smart contract based on one or more second predetermined rules; initiating the consensus algorithm of the blockchain network to record the shipping insurance premium allocation data on a blockchain; generating a second event message by executing the second smart contract, the second event message notifying the allocation of the shipping insurance premium according to the shipping insurance premium allocation data.

[0041] The present invention also describes techniques for storage management based on message feedback. These techniques generally involve: based on initiating a consensus algorithm through a blockchain node associated with a computing system, storing the shipping data and shipping insurance order data associated with a purchase order on a blockchain; determining whether the shipping insurance order associated with the shipping insurance order data is valid by executing a smart contract based on the shipping data and one or more first predetermined rules; in response to determining that the shipping insurance order is valid, generating an event message dedicated to notifying an insurance provider that the shipping insurance for the purchase order is valid by executing the smart contract; storing the event message in a hardware cache managed by the computing system; sending the event message to a blockchain node associated with the insurance provider; and, in response to receiving a feedback message from the blockchain node associated with the insurance provider, processing the event message.

[0042] The technology described herein produces several technical effects. In certain embodiments, the entire life cycle of a transportation insurance service (e.g., insurance order generation and insurance premium allocation) can be recorded on a blockchain. For example, a blockchain can store an unalterable and transparent chain of records linking data associated with the same purchase order. Since the records on the blockchain are recorded by consensus, they can be easily verified and trusted by entities that have access to the blockchain. Compared to point-to-point communication, the use of blockchain technology can improve data processing efficiency when data is generated by different entities.

[0043] In some embodiments, transportation insurance data may be time-sensitive. The disclosed smart contract technology allows for rapid verification of the authenticity and validity of transportation information, order information, and transportation insurance orders. Smart contract technology also allows for different types of event messages to be generated for different services or service providers associated with insurance processing. Event messages can be used to quickly notify service providers of important insurance events, especially when the total data volume is high. By selectively generating different types of event messages, services related to important events can be more easily associated with and identified by the corresponding service providers. In this way, transportation insurance policies can take effect quickly and insurance premiums can be distributed among service providers in a timely manner.

[0044] In some embodiments, a feedback mechanism is provided to strategically manage data retransmissions due to potential packet loss. As a result, time-sensitive event messages can be released from cache storage after receiving positive feedback about data transmission. The time period that occupies valuable cache storage space can be reduced, and storage usage efficiency can be improved. In addition, as the number of data retransmissions is reduced, the consumption of communication bandwidth within the blockchain network can be reduced. The feedback mechanism is particularly suitable for blockchain networks with a large number of nodes, where the transmission path of data packets may be relatively long, increasing the chance of packet loss.

[0045] In some embodiments, the privacy of insurance data can be further protected based on the use of trusted execution environment (TEE) technology. A trusted execution environment is an isolated and trusted computing environment that can be integrated into a blockchain node in a blockchain network. The trusted execution environment processes the plaintext of insurance-related data and outputs the ciphertext of the data. Using the trusted execution environment technology, data can be easily updated within the trusted execution environment without disclosing the actual update. In addition, the output of the trusted execution environment is encrypted and trusted by the blockchain nodes in the blockchain network, so it can be effectively stored in the blockchain after the blockchain nodes reach a consensus.

[0046] To provide further background for the embodiments of the present invention, as described above, a distributed ledger system (DLS), which may also be referred to as a consensus network (e.g., composed of peer-to-peer nodes) and a blockchain network, enables participating entities to conduct transactions and store data securely and immutably. Although the term blockchain is often associated with a specific network and / or use case, blockchain is generally used herein to refer to a DLS without reference to any specific use case.

[0047] Blockchain is a data structure that stores transactions in a way that they cannot be tampered with. Therefore, the transactions recorded on the blockchain are reliable and trustworthy. The blockchain includes one or more blocks. Each block in the chain is linked to the previous block by the cryptographic hash value of the previous block immediately before it in the chain. Each block also includes a timestamp, its own cryptographic hash value, and one or more transactions. Transactions that have been verified by nodes in the blockchain network are hashed and compiled into a Merkle tree. A Merkle tree is a data structure in which the data at the leaf nodes of the tree are hashed, and all hash values ​​in each branch of the tree are concatenated at the root of the branch. This process continues along the tree until the root of the entire tree, where hash values ​​representing all the data in the tree are stored. The hash value can be quickly verified by determining whether the hash value of the transaction claimed to be stored in the tree is consistent with the structure of the tree.

[0048] A blockchain is a decentralized or at least partially decentralized data structure for storing transactions, and a blockchain network is a network of computing nodes that manage, update, and maintain one or more blockchains by broadcasting, verifying, and confirming transactions. As described above, a blockchain network may be provided as a public blockchain network, a private blockchain network, or a consortium blockchain network. The embodiments herein are further described in detail with reference to a consortium blockchain network. However, it is contemplated that the embodiments herein may be implemented in any suitable type of blockchain network.

[0049] Typically, a consortium blockchain network is private among participating entities. In a consortium blockchain network, the consensus process is controlled by an authorized set of nodes, which may be referred to as consensus nodes, and one or more consensus nodes are operated by the corresponding entity (e.g., financial institution, insurance company). For example, a consortium of ten (10) entities (e.g., financial institutions, insurance companies) may operate a consortium blockchain network, with each entity operating at least one node in the consortium blockchain network.

[0050] In some examples, in a consortium blockchain network, a global blockchain is provided as a blockchain replicated across all nodes. That is, all consensus nodes are in full consensus with respect to the global blockchain. In order to reach consensus (e.g., agree to add a block to the blockchain), a consensus protocol is implemented within the consortium blockchain network. For example, the consortium blockchain network can implement a practical Byzantine fault tolerance (PBFT) consensus, which will be described in further detail below.

[0051] Figure 11 is a diagram showing an example of an environment 100 that can be used to perform embodiments of the present invention. In some examples, the environment 100 enables entities to participate in a consortium blockchain network 102. The environment 100 includes computing systems 106, 108 and a network 110. In some examples, the network 110 includes a local area network (LAN), a wide area network (WAN), the Internet, or a combination thereof, and connects websites, user devices (e.g., computing devices), and back-end systems. In some examples, the network 110 can be accessed via a wired and / or wireless communication link. In some examples, the network 110 enables communication with the consortium blockchain network 102 and communication within the consortium blockchain network 102. Typically, the network 110 represents one or more communication networks. In some cases, the computing systems 106, 108 can be nodes of a cloud computing system (not shown), or each of the computing systems 106, 108 can be a separate cloud computing system that includes multiple computers interconnected by a network and used as a distributed processing system.

[0052] In the depicted example, computing systems 106, 108 may each include any suitable computing device capable of participating as a node in consortium blockchain network 102. Example computing devices include, but are not limited to, servers, desktop computers, laptop computers, tablet computing devices, and smart phones. In some examples, computing systems 106, 108 host one or more computer-implemented services for interacting with consortium blockchain network 102. For example, computing system 106 may host a computer-implemented service for a first entity (e.g., user A), such as a transaction management system used by the first entity to manage its transactions with one or more other entities (e.g., other users). Computing system 108 may host a computer-implemented service for a second entity (e.g., user B), such as a transaction management system used by the second entity to manage its transactions with one or more other entities (e.g., other users). Figure 1 In the example of , the consortium blockchain network 102 is represented as a peer-to-peer network of nodes, and the computing systems 106 , 108 provide nodes of a first entity and a second entity participating in the consortium blockchain network 102 , respectively.

[0053] Figure 22 is an example of an architecture 200 according to an embodiment of the present invention. The exemplary conceptual architecture 200 includes participant systems 202, 204, 206 corresponding to participant A, participant B, and participant C, respectively. Each participant (e.g., user, enterprise) participates in a blockchain network 212 provided as a peer-to-peer network, which includes multiple nodes 214, at least some of which record information in an unalterable manner in a blockchain 216. As further detailed herein, although a single blockchain 216 is schematically depicted in the blockchain network 212, multiple copies of the blockchain 216 are provided and maintained on the blockchain network 212.

[0054] In the depicted example, each participant system 202, 204, 206 is provided by or on behalf of participant A, participant B, and participant C, respectively, and functions as a respective node 214 in the blockchain network. As used herein, a node generally refers to an individual system (e.g., computer, server) that is connected to the blockchain network 212 and enables the corresponding participant to participate in the blockchain network. Figure 2 In the example of , a participant corresponds to each node 214. However, it is contemplated that a participant may operate multiple nodes 214 within the blockchain network 212, and / or multiple participants may share a node 214. In some examples, the participant systems 202, 204, 206 communicate with or through the blockchain network 212 using a protocol (e.g., Hypertext Transfer Protocol Secure (HTTPS)) and / or using remote procedure calls (RPCs).

[0055] Nodes 214 may have different levels of participation within blockchain network 212. For example, some nodes 214 may participate in the consensus process (e.g., as miner nodes that add blocks to blockchain 216), while other nodes 214 do not participate in this consensus process. As another example, some nodes 214 store a complete copy of blockchain 216, while other nodes 214 store only a copy of a portion of blockchain 216. For example, data access privileges may limit the blockchain data that a respective participant stores within their respective system. Figure 2 In the example of FIG. 2 , participant systems 202 , 204 , and 206 store complete copies 216 ′, 216 ″, and 216 ′″ of blockchain 216 , respectively.

[0056] Blockchain (e.g. Figure 2The blockchain 216) consists of a series of blocks, each of which stores data. Examples of data include transaction data representing a transaction between two or more participants. Although "transaction" is used herein by way of non-limiting example, it is contemplated that any appropriate data may be stored in the blockchain (e.g., documents, images, videos, audio). Examples of transactions may include, but are not limited to, the exchange of valuables (e.g., assets, products, services, currencies). Transaction data is stored in an unalterable manner in the blockchain. That is, the transaction data cannot be changed.

[0057] Before storing the transaction data in the block, the transaction data is hashed. Hashing is the process of converting the transaction data (provided as string data) into a fixed-length hash value (also provided as string data). It is impossible to un-hash the hash value to obtain the transaction data. Hashing ensures that even a slight change in the transaction data will result in a completely different hash value. In addition, as mentioned above, the hash value has a fixed length. That is, regardless of the size of the transaction data, the length of the hash value is fixed. Hashing includes processing the transaction data through a hash function to generate a hash value. Examples of hash functions include, but are not limited to, the Secure Hash Algorithm (SHA)-256, which outputs a 256-bit hash value.

[0058] The transaction data of multiple transactions are hashed and stored in a block. For example, the hashes of two transactions are provided and they themselves are hashed to provide another hash. This process is repeated until a single hash is provided for all transactions to be stored in a block. This hash is known as the Merkle root hash and is stored in the block header. Changes in any transaction will cause its hash to change and ultimately the Merkle root hash to change.

[0059] Blocks are added to the blockchain through a consensus protocol. Multiple nodes in the blockchain network participate in the consensus protocol and perform work to add blocks to the blockchain. Such nodes are called consensus nodes. The PBFT introduced above is used as a non-limiting example of a consensus protocol. Consensus nodes execute the consensus protocol to add transactions to the blockchain and update the overall state of the blockchain network.

[0060] In more detail, the consensus node generates a block header, hashes all transactions in the block, and combines the hashes in pairs to generate further hashes until a single hash (Merkle root hash) is provided for all transactions in the block. This hash is added to the block header. The consensus node also determines the hash of the latest block in the blockchain (i.e., the last block added to the blockchain). The consensus node also adds a nonce value and a timestamp to the block header.

[0061] In general, PBFT provides practical Byzantine state machine replication that tolerates Byzantine faults (e.g., faulty nodes, malicious nodes). This is achieved by assuming in PBFT that failures will occur (e.g., assuming that there are independent node failures and / or manipulated messages sent by consensus nodes). In PBFT, consensus nodes are provided in a sequence that includes a primary consensus node and a backup consensus node. The primary consensus node is changed periodically. Transactions are added to the blockchain by all consensus nodes within the blockchain network reaching a consensus on the global state of the blockchain network. In this process, messages are transmitted between consensus nodes, and each consensus node proves that the message is received from a designated peer node and verifies that the message has not been modified during transmission.

[0062] In PBFT, the consensus protocol is provided in multiple stages with all consensus nodes starting from the same state. First, the client sends a request to the primary consensus node to invoke a service operation (e.g., execute a transaction within the blockchain network). In response to receiving the request, the primary consensus node multicasts the request to the backup consensus nodes. The backup consensus nodes execute the request, and each node sends a reply to the client. The client waits until a threshold number of replies are received. In some examples, the client waits until f+1 replies are received, where f is the maximum number of faulty consensus nodes that can be tolerated within the blockchain network. The end result is that a sufficient number of consensus nodes agree on the order in which records will be added to the blockchain, and the record is either accepted or rejected.

[0063] In some blockchain networks, cryptography is used to maintain the privacy of transactions. For example, if two nodes want to keep a transaction private so that other nodes in the blockchain network cannot see the details of the transaction, the two nodes can encrypt the transaction data. Examples of encryption include, but are not limited to, symmetric encryption and asymmetric encryption. Symmetric encryption refers to the use of a single key to both encrypt (generate ciphertext from plaintext) and decrypt (generate plaintext from ciphertext). In symmetric encryption, the same key can be used for multiple nodes, so each node can encrypt / decrypt the transaction data.

[0064] Asymmetric encryption uses key pairs, each of which consists of a private key and a public key, where the private key is known only to the corresponding node and the public key is known to any or all other nodes in the blockchain network. A node can encrypt data using the public key of another node, and the encrypted data can be decrypted using the private key of the other node. For example, referring again to Figure 2 , participant A can use participant B's public key to encrypt data and send the encrypted data to participant B. Participant B can use its private key to decrypt the encrypted data (ciphertext) and extract the original data (plaintext). Messages encrypted using a node's public key can only be decrypted using that node's private key.

[0065] Asymmetric encryption is used to provide digital signatures, which enables participants in a transaction to confirm the other participants in the transaction and the validity of the transaction. For example, a node can digitally sign a message, and another node can confirm that the message was sent by the node based on the digital signature of participant A. Digital signatures can also be used to ensure that the message has not been tampered with during transmission. For example, again referring to Figure 2 , Participant A is about to send a message to Participant B. Participant A generates a hash value of the message and then encrypts the hash value using its private key to provide a digital signature that is an encrypted hash value. Participant A appends the digital signature to the message and sends the message with the digital signature to Participant B. Participant B decrypts the digital signature using Participant A's public key and extracts the hash value. Participant B hashes the message and compares the hash values. If the hash values ​​are the same, Participant B can confirm that the message is indeed from Participant A and has not been tampered with.

[0066] In some embodiments, nodes of the blockchain network and / or nodes communicating with the blockchain network are able to operate using a trusted execution environment (TEE). At a high level, a TEE is a trusted execution environment within the hardware (one or more processors, memory) that is isolated from the hardware's operating environment (e.g., operating system (OS), basic input / output system (BIOS)). In more detail, a TEE is a separate, secure area of ​​the processor that ensures the privacy and integrity of code execution and data loaded in the main processor. Within the processor, the trusted execution environment runs in parallel with the operating system. At least part of the so-called trusted application (TA) is executed within the trusted execution environment and has access to the processor and memory. Through the TEE, the TA can be protected from attacks by other applications running in the main OS. In addition, the TEE cryptographically isolates the TA from each other within the TEE.

[0067] Examples of TEEs include Software Guard Extensions (SGX) provided by Intel Corporation of Santa Clara, California, U.S. Although SGX is discussed herein by way of example, it is contemplated that any suitable TEE may be used to implement embodiments herein.

[0068] SGX provides a hardware-based TEE. In SGX, the trusted hardware is the core of the central processing unit (CPU), and a portion of the physical memory is isolated to protect selected code and data. The isolated portion of the memory is called an enclave. More specifically, the enclave is provided as an enclave page cache (EPC) in the memory and mapped to the application address space. The memory (e.g., DRAM) includes a reserved random access memory (PRM) for SGX. The random access memory is a continuous memory space at the basic input / output system level and cannot be accessed by any software. Each EPC is a storage set (e.g., 4KB) allocated by the OS to load application data and code in the PRM. The enclave page cache metadata (EPCM) is the entry address of the corresponding enclave page cache and ensures that each enclave page cache can only be shared by one enclave. That is, a single enclave can use multiple EPCs, and the EPC is dedicated to a single enclave.

[0069] During the execution of TA, the processor runs in the so-called enclave mode when accessing data stored in the enclave. Operation in enclave mode performs additional hardware checks on each memory access. In SGX, trusted applications are compiled into trusted and untrusted parts. For example, the OS, BIOS, privileged system code, virtual machine manager (VMM), system management mode (SMM), etc. cannot access the trusted part. In operation, TA runs in the PRM of the memory and creates an enclave. The trusted function executed by the trusted part within the enclave is called by the untrusted part, and the code executed within the enclave treats the data as plaintext data (unencrypted) and denies external access to the data. The trusted part provides an encrypted response to the call, and TA continues to execute.

[0070] An attestation process may be performed to verify that an expected node (e.g., a trusted portion of a trusted application) is securely executing within the trusted execution environment provided by SGX. Typically, an attestation process includes a trusted application receiving an attestation request from a challenger (e.g., another node in a blockchain network, a key management system (KMS) of the blockchain network). In response, the trusted application requests its enclave to generate a remote attestation, also referred to as a reference. Generating a remote attestation includes a local attestation being sent from the enclave to a so-called reference enclave, which verifies the local attestation, and converts the local attestation to a remote attestation by signing the local attestation with an asymmetric attestation key. The remote attestation (reference) is provided to the challenger (e.g., a key management system of the blockchain network).

[0071] The challenger uses the authentication verification service to verify the remote authentication. For SGX, Intel provides the Intel Attestation Service (IAS), which receives the remote authentication from the challenger and verifies the remote authentication. More specifically, IAS processes the remote authentication and provides a report (e.g., an authentication verification report (AVR)) indicating whether the remote authentication is verified. If not verified, an error may be indicated. If verified (the expected code is securely executed in a trusted execution environment), the challenger can start or continue to interact with the trusted application. For example, in response to verification, the key management system (as a challenger) can issue an asymmetric encryption key (e.g., a public key and a private key pair) to a node executing a trusted execution environment (e.g., after key exchange processing, such as elliptic curve Diffie-Hellman (ECDH)) to enable the node to communicate securely with other nodes and / or clients. Additional details of the trusted execution environment technology are described in, for example, PCT application PCT / CN2019 / 081180 filed on April 3, 2019, the contents of which are incorporated herein by reference.

[0072] Figure 3 300 is a swimlane diagram showing an example of a message flow 300 according to an embodiment of the present invention. At a high level, the message flow 300 is transmitted downstream from the transportation insurance service platform 302 to the insurance provider 318 through the alliance blockchain network, and transmitted upstream back to the service platform 302. The service platform 302 can provide interfaces and data services to participants participating in online orders and related transportation insurance services. Such service providers may include online sellers or e-commerce platforms (e.g., ALIBABA, EBAY or AMAZON), delivery service providers (e.g., FEDEX, DHL or SFEXPRESS), transportation insurance brokers, insurance providers 318, etc. The data service can be based on blockchain technology implemented on the alliance blockchain network. The alliance blockchain network may include nodes owned by one or more of the service platform 302 and other service providers.

[0073] In some embodiments, the service platform 302 can act as a collector and facilitator of data provided by the service provider. Data can be provided in documents related to transportation insurance, including purchase order documents, logistics documents (or transportation documents), and / or transportation insurance order documents. The purchase order document can be provided to the service platform 302 by the e-commerce platform. In some examples, the purchase order can be a credit insurance order. In a credit insurance order, when placing an order, the buyer can pay the amount of the order. However, the e-commerce platform will withhold payment until the order delivery is confirmed or otherwise fulfilled, and then release the payment to the seller.

[0074] In some embodiments, the purchase order may also include a shipping insurance payment selected to be paid by the buyer. In some examples, the shipping insurance payment is included in the purchase order and may be considered a shipping insurance order. In some examples, a shipping insurance order document separate from the purchase order document may be created and provided by a shipping insurance broker or underwriter. In some embodiments, the shipping document may be provided to the service platform 302 by a delivery service provider.

[0075] At 304, the service platform 302 may send the transportation insurance related document to a blockchain node 306 associated with the service platform 302. The blockchain node 306 may be a node of a blockchain network.

[0076] In some embodiments, some or all of the transportation insurance related documents may be encrypted by an encryption key to protect the privacy of the document owner. The document owner may determine which users of the service platform 302 may be allowed to access the plain text version of the document and request the system administrator of the service platform 302 to set the access rights of the document. In some embodiments, the document owner may also provide a list of users who are allowed to access the plain text version of the document in addition to the document owner himself. For example, for a transportation document, the list of users who are allowed to view the plain text document may be the service platform 302 and the insurance provider 318.

[0077] In some examples, the encryption key used to encrypt the document can be a symmetric key. To set access permissions for a user, a system administrator can use the user's public key to encrypt the symmetric key. The encrypted version of the symmetric key can be stored in a smart contract. A user with access to the document can retrieve the encrypted version of the symmetric key from the smart contract and use their corresponding private key to decrypt the encrypted version of the symmetric key. After decrypting the symmetric key, the user can use it to decrypt the encrypted document.

[0078] The service platform 302 includes an application programming interface (API) layer, which includes multiple APIs that can be called by users to provide services associated with transportation insurance. These APIs can be accessed from a computing device (e.g., a smart phone) through a software application (APP). In some examples, the API can interact with one or more services including a transportation insurance-related document registration service, a document data update service, a query service, an insurance history generation service, a premium history generation service, a premium allocation history service, etc.

[0079] At 308, the blockchain node may call a smart contract 310 to store the document as a transaction to the blockchain. Transactions added to the blockchain may be verified and agreed upon by blockchain nodes in the blockchain network through consensus based on a consensus algorithm. Exemplary consensus algorithms may include proof of work (PoW), proof of stake (PoS), PBFT, etc. Once a transaction is added, it becomes immutable and can be verified by any of the blockchain nodes of the blockchain network.

[0080] At 312, smart contract 310 may be executed to generate and store event messages. Event messages may include document events indicating that a new document is recorded on the blockchain and insurance order events indicating that a new insurance order is valid. Smart contract 310 may also be stored on the blockchain as a special type of transaction. In some embodiments, smart contract 310 may be called by different nodes of the blockchain network through API calls to perform different functions. These functions may include blockchain storage, document status management, insurance order review, and / or event management. For example, a blockchain node associated with an e-commerce platform and a delivery service provider may make an API call to call a blockchain storage function. The blockchain storage function may be called to store purchase order documents and transportation insurance order documents on the blockchain. In response to a document event indicating that a new document is added to the blockchain, an insurance order review function may be called to verify and approve the transportation insurance order.

[0081] In some embodiments, the service platform 302 may also make an API call to invoke the event management function to generate or perform other management functions of the event message. For example, in response to a new document being recorded on the blockchain, the event management function may generate a corresponding document event. In response to the insurance order being approved by the insurance order review function, the event management function may generate an insurance order event indicating that the transportation insurance order is valid.

[0082] In some embodiments, event messages can be used to mark or notify events associated with transportation insurance services that require timely response. By generating event messages, parties involved in transportation insurance services can more easily identify time-sensitive event messages from a large amount of blockchain data.

[0083] In some embodiments, the service platform 302 may call an insurance order review function to review whether the document meets one or more predetermined rules. For example, in order to generate an event message for the insurance provider 318 indicating that the transportation insurance order is valid, the one or more predetermined rules may include the coverage of the declared value of the purchase order, the items covered by the transportation insurance, the insurance limit of the purchase order, and / or the premium allocation plan. Accordingly, after the insurance order review function is called to verify that the declared value of the purchase order is within the coverage, the items covered by the transportation insurance are insurable, and the insurance amount of the purchase order is lower than the insurance limit, the transportation insurance order is valid.

[0084] In some embodiments, event messages can be stored on the blockchain as event logs. In order to obtain event messages stored in the event logs, blockchain nodes associated with different service providers can retrieve the event logs periodically or as needed. In some embodiments, after event messages associated with the service are generated, they can be automatically sent to other blockchain nodes to reach a consensus. After the event message is stored on the blockchain, the event message can be sent to its dedicated service provider or retrieved by its dedicated service provider. For example, after the event message indicating that the transportation insurance order is valid is stored on the blockchain, at 316, the insurance provider 318 can retrieve the event message through the blockchain node 314, or the blockchain node 314 can send the event message to the insurance provider 318.

[0085] At 320, the insurance provider 318 may generate the premium allocation agreed to by the service provider and send it to the blockchain node for storage on the blockchain. At 322, the blockchain node 314 may make an API call to call the smart contract 310 to perform the insurance order review function and verify whether the premium allocation complies with the premium allocation plan agreed to by the service provider. If so, the blockchain storage function of the smart contract 310 may be called to store the premium allocation on the blockchain.

[0086] At 324, the smart contract 310 may be executed to generate and store a premium allocation event message. In some embodiments, the premium allocation event message may be generated by calling an event management function. After the premium allocation event message is generated, it may be sent to other blockchain nodes to reach a consensus. After the premium allocation event message is stored on the blockchain, at 326, the premium allocation event message may be retrieved by the service platform 302 so that the service platform 302 may notify the e-commerce platform to allocate the insurance premium accordingly to the qualified service providers.

[0087] Figure 4400 is a diagram showing an example of an internal system 400 of a service provider of a transportation insurance service according to an embodiment of the present invention. The service provider may be an e-commerce platform, a delivery service provider, a transportation insurance broker, or an insurance provider. At a high level, the internal system 400 may include an APP 402, a database 404, a key management system (KMS) 406, and a computing and connection component 408. In some embodiments, the internal system 400 may include fewer or more components. The internal system 400 is connected to a blockchain network 409 including multiple blockchain nodes (for illustration purposes, the internal system 400 is connected to a blockchain network 409 including multiple blockchain nodes). Figure 4 Only blockchain node 410 and blockchain node 412 are shown in FIG. 4 , and it should be understood that blockchain network 409 may include many additional blockchain nodes. For example, blockchain nodes 410 and 412 may be Figure 3 The blockchain nodes 306 and 314 depicted in the figure serve the service platform 302 and the insurance provider respectively.

[0088] APP 402 can be a software programming for carrying the API of the service platform to provide data services associated with transportation insurance. APP 402 can be an interface between the user of the service platform and the internal system 400 of the service platform. For example, APP 402 can be used to receive input including user profile information, login information, transportation insurance related service data, etc. In some embodiments, data related to transportation insurance services can be stored in database 404. Database 404 can include any memory or database module, and can take the form of volatile or non-volatile memory, including but not limited to magnetic media, optical media, random access memory (RAM), read-only memory (ROM), removable media or any other suitable local or remote memory component. Database 404 can store various objects or data, including classes, frameworks, applications, backup data, business objects, tasks, web pages, web page templates, database tables, repositories for storing business or dynamic data, and any parameters, variables, algorithms, instructions, rules, constraints or any other suitable information referenced by them associated with the purpose of APP 402 or internal system 400.

[0089] Exemplary data may include order data, logistics data, tracking data, insurance payment data, premium data, templates and encryption keys, etc. In addition, database 404 may include any other appropriate data, such as VPN applications, firmware logs and policies, firewall policies, security or access logs, print or other report files, and other files. In some examples, APP 402 can retrieve data from database 404 via a database API.

[0090] APP 402 can communicate information related to transportation insurance services with computing and connection components 408. In some embodiments, computing and connection components 408 may include a trusted computing module 420, a trusted time module 422, and a trusted identity module 424. Trusted computing module 420 may include one or more processors that execute instructions provided by a software development kit (SDK). Exemplary instructions may include performing encryption, generating digital signatures and / or zero-knowledge proofs ZKP or other applicable proofs. In some embodiments, one or more data processors may have a TEE that is isolated from the operating system of one or more processors and configured to provide enhanced privacy and integrity for the code executed and the data loaded within one or more data processors.

[0091] In some embodiments, the trusted computing module 420 can be configured to record data associated with the transportation insurance service in accordance with privacy laws. For example, the trusted computing module 420 can generate a hash value of the record (i.e., a transaction hash value) and add a block including the record and the hash value to a blockchain associated with the blockchain network 409. As previously described, a document can contain dynamic data and unmodifiable blockchain data stored in a smart contract data cache and a blockchain database, respectively. For the same document or smart contract transaction, the transaction hash value of the dynamic data can be stored together with the corresponding blockchain data under the same data structure on the blockchain, so that the dynamic data and the unmodifiable blockchain data can be linked. Alternatively or additionally, the transaction hash value of the blockchain data can be stored in the smart contract data cache together with the corresponding dynamic data, so that the data can be linked.

[0092] In some embodiments, the trusted computing module 420 can be configured to provide a verified record of the steps / operations performed by the APP 402 in response to a request for a verified record associated with a transportation insurance service document. The trusted computing module 420 can also provide a verified timestamp generated by the trusted time module 422, a verified identity generated by the trusted identity module 424, and / or a calculation result associated with each of the steps / operations performed by the APP 402.

[0093] In some embodiments, cryptographic keys for performing encryption and generating digital signatures and certifications may be provided to trusted computing module 420 by key management system 406. In some embodiments, key management system 406 may generate, store, and manage cryptographic keys. In some embodiments, key management system 406 includes a secure application environment implemented using trusted execution environment technology (e.g., Intel SGX). The trusted execution environment may execute one or more software programs or libraries.

[0094] In some embodiments, the trusted time module 422 can be configured to generate a timestamp based on national standard time information (e.g., Greenwich Mean Time (GMT), UTC) or time information obtained from a global positioning system. In some embodiments, the trusted time module 422 can synchronize the time it maintains with the global time adopted by the blockchain nodes in the blockchain network 409 to ensure the accuracy of the timestamp stored on the blockchain.

[0095] In some embodiments, the trusted time module 422 can be configured to generate timestamps associated with different users using different standard times for different regions. For example, the trusted time module 422 can generate timestamps associated with an e-commerce platform using a first standard time identified by an international delivery service provider, and generate timestamps associated with an insurance provider using a second standard time identified by a domestic insurance service platform associated with the insurance provider, wherein the e-commerce platform and the insurance provider are located in different regions with different logistics systems.

[0096] The trusted identity module 424 may be configured to verify the identity of the service platform user based on one or more unique IDs associated with the user. In some embodiments, the unique ID may include at least one of the following: (i) a mobile phone number, (ii) a credit card number, (iii) a user ID associated with an online payment system, (iv) a user ID associated with an online shopping account, (v) a user ID associated with a music streaming or downloading account, (vi) a user ID associated with a movie streaming or downloading account, (vii) a user ID associated with a messaging or chat account, (viii) a user ID associated with an online banking account, (ix) a user ID associated with a ride-hailing service, (x) a user ID associated with an online food ordering service, (xi) a social security number, (xii) a driver's license number, (xiii) a passport number, (xiv) a user ID associated with an online gaming service, (xv) an ID issued by a government entity, (xvi) one or more fingerprints, (xvii) one or more voiceprints, or (xviii) iris information.

[0097] In some embodiments, the unique ID may also include a decentralized identifier of the user. The decentralized identifier may include a uniform resource locator (URL) scheme identifier, an identifier for a decentralized identifier method, and an identifier dedicated to a decentralized identifier method. The decentralized identifier may point to a corresponding decentralized identifier document, which may include a descriptive text in a preset format (e.g., JSON-LD) related to the decentralized identifier and the owner of the decentralized identifier. The decentralized identifier may be used as a uniform resource identifier (URI) for locating a decentralized identifier document. The decentralized identifier document may include various attributes, such as context, decentralized identifier subject, public key, authentication, authorization and proxy, service endpoint, creation, update, certification, and scalability. The decentralized identifier document may define or point to a resource that defines multiple operations, which may be performed relative to the decentralized identifier. In the example described herein, the decentralized identifier complies with the standards specified by the World Wide Web Consortium (W3C). However, other decentralized identifiers may also be used.

[0098] In some embodiments, a unique ID can be used to uniquely identify an insurance applicant or a transportation insurance order. Before the data is recorded on the blockchain, the service provider can embed the unique ID into the transportation insurance data associated with the insurance applicant. The insurance provider or regulator can track the transportation insurance data associated with the insurance applicant based on recovering the embedded unique ID. In this way, it can be ensured that the data used to verify the transportation insurance order belongs to the same insurance applicant and that the data is complete for review. Additional information about the unique ID can be found in the application PCT / CN2019 / 095299 filed on July 9, 2019, the application PCT / CN2019 / 103780 filed on August 30, 2019, and the application CN201910963431.0 filed on October 11, 2019. The above applications are incorporated herein by reference.

[0099] In some embodiments, the trusted identity module 424 can be configured to verify different insurance applicants located in different areas with different insurance policy systems by using different identifiers. For example, the trusted identity module 424 can be configured to verify the identity of the first insurance applicant using at least one of a first set of identifiers recognized by a first insurance policy system associated with the first insurance applicant, and to verify the identity of the second insurance applicant using at least one of a second set of identifiers recognized by a second insurance policy system associated with the second insurance applicant, wherein the first insurance applicant and the second insurance applicant are located in different areas with different insurance policy systems.

[0100] In some examples, the computing and connection components 408 may also include a router 426 that can route information processed by one or more processors to a blockchain node 410 in a blockchain network 409 that is communicatively coupled to the internal system 400. As previously described, the blockchain node 410 can be a cloud node that can sign and / or verify messages and communicate with other blockchain nodes. The blockchain node 410 can also be a consensus node that participates in consensus processing in the blockchain network 409. In some embodiments, internal communication between the internal system 400 and the blockchain network 409 and between them can be performed based on a secure communication protocol such as Hypertext Transfer Protocol Secure (HTTPS) or Transport Layer Security (TLS). For example, a function executed by the blockchain node 410 can be defined in a smart contract, wherein a miner node of the blockchain network executes the function in the smart contract, and a consensus full node of the blockchain network verifies the transaction.

[0101] The time, identity, and content carried by the transportation insurance data recorded on the blockchain can be credible. The blockchain enables the APP 402 providing transportation insurance services to save verified records of information related to events that occurred during each of the multiple steps or key time points of the service (e.g., who, what, and when). The record of information is saved in a manner that complies with (or is more consistent with than previous systems) predetermined rules. For example, when an order is insured by a Chinese insurance provider, the predetermined rules may be the Insurance Law of the People's Republic of China.

[0102] Figure 5 5 is a relationship diagram showing an example of the relationship between the sub-models of the transportation insurance data model 500 according to an embodiment of the present invention. The transportation insurance data model 500 may be a computer-implemented model used by one or more APPs of the service platform, such as in Figure 3 and Figure 4 In the description of the service platform discussed in the above, to process the transport insurance related data. At a higher level, the model 500 may have sub-models, including a service platform user sub-model 502, a credit insurance order sub-model 504, a logistics document sub-model 506 and an insurance document sub-model 508.

[0103] The service platform user submodel 502 can be used to model the attributes of the user account that is allowed to access the services provided by the service platform. Such a user account can be associated with users such as a transportation insurance applicant or a customer who places a purchase order. The service platform user submodel 502 can have a primary key (Primary Key, PK) including a user account ID and a user name. Each user account can correspond to one or more credit insurance orders modeled under the credit insurance order submodel 504. Each credit insurance order can have a PK of a unique order ID, and one or more foreign keys (Foreign Key, FK). FK can include account ID, order amount and order status. The account ID included in FK can link the corresponding order to the user account. In this way, the corresponding user account can be found when searching for a credit insurance order.

[0104] Each credit insurance order may correspond to one or more logistics documents (or shipping documents). The logistics document data may be modeled under the logistics document sub-model 506. The logistics document sub-model 506 may have a PK of a unique logistics ID (e.g., a shipping document ID or a tracking number), and a FK including the order ID and shipping status of the corresponding credit insurance order.

[0105] Each logistics document may correspond to an insurance document. Insurance document data may be modeled under the insurance document sub-model 508. The insurance document sub-model 508 may have a PK of the insurance document ID, and a FK including the logistics ID and the insurance amount of the corresponding logistics document.

[0106] Figure 6 600 is a swim lane diagram showing an example of a process 600 for providing message feedback according to an embodiment of the present invention. Figure 3 As discussed in the description, various event messages for different services can be generated to facilitate shipping insurance generation and premium allocation. As purchase orders, shipping insurance, and logistics documents accumulate, the amount of data communicated within or through the blockchain network can be high. In some cases, packet loss may occur, especially when data surges occur during busy times. In order to avoid losing important event messages, message feedback processing can be implemented.

[0107] At 612, the service platform 602 may send one or more of the shipping document and the shipping insurance order to a blockchain node 604 associated with the service platform. At 614, the blockchain node 604 may call a smart contract by reaching a consensus with other blockchain nodes of the blockchain network to store the document on the blockchain 606. In some embodiments, the blockchain node 604 may be part of the service platform 602. In some embodiments, the blockchain node 604 may be a computing device or system that remotely serves the service platform 602.

[0108] In some examples, the smart contract may generate an event message to notify blockchain node 604 of a document event that a new document has been successfully stored on blockchain 606. The event message may be stored in a cache storage of blockchain node 604. In response to receiving the notification, blockchain node 604 may send a response to service platform 602 indicating that the document sent by service platform 602 was successfully processed.

[0109] At 616, the smart contract can determine whether the insurance order is valid based on the shipping insurance order and the shipping document. For example, in response to the document event, the smart contract can call the insurance order review function, such as Figure 3 As discussed in the description of , to verify and approve the transportation insurance order. After the insurance order is approved by the insurance order review function, the smart contract can call the event management function to generate an insurance order event message indicating that the transportation insurance order is valid.

[0110] At 618, a blockchain node 608 associated with insurance provider 610 may be notified of the insurance order event. In some embodiments, blockchain node 608 may be part of a computing system of insurance provider 610. In some embodiments, blockchain node 608 may be a computing device or system remote to service platform 602. In some examples, the event message may be automatically sent to blockchain node 608 after being generated. In some examples, the event message may be retrieved by blockchain node 608.

[0111] At 620, the blockchain node 608 may determine whether an insurance order event message is received. If so, at 622, the insurance order event message may be forwarded to the insurance provider 610. Otherwise, at 624, a feedback message may be sent by the blockchain node 608. In some cases, the smart contract may call an event management function to periodically generate event messages until an acknowledgment (ACK) of receiving the feedback is received at 624.

[0112] In some cases, at 620, if it is determined that the event message is not correctly received or is not received within a predetermined time period, the feedback message may be a negative acknowledgement (NACK). In this case, at 626, it may be determined that the event message needs to be resent. In some examples, at 626, after the event message is resent, the event message may be deleted from the cache to save storage space. In some examples, after receiving an ACK from the blockchain node 608, the event message may be deleted.

[0113] In some cases, the feedback message may include specific instructions. In some examples, the feedback message may include instructions to provide a shipping insurance order document to further review the validity of the order. In response to receiving the feedback message, a smart contract may be executed to retrieve the shipping insurance order document from blockchain 606 to blockchain node 608. In some examples, the specific instructions may include sending event messages in a range of message numbers or in a specific order. In response to receiving the feedback message, a smart contract may be executed to resend the event message according to the range or order provided by the feedback message.

[0114] At 628, insurance provider 610 generates the premium allocation and sends it to blockchain node 608 for storage on blockchain 606 at 630. In some examples, the smart contract may generate an event message to notify blockchain node 608 that the premium allocation has been successfully stored on blockchain 606. In response to receiving the notification, blockchain node 608 may send a response to insurance provider 610 indicating that the premium allocation was successfully recorded.

[0115] At 632, the blockchain node 608 may execute a smart contract to call an insurance order review function to verify whether the premium allocation complies with the premium allocation plan agreed to by the service provider. If so, the smart contract may be executed to generate and store a premium allocation event message by calling an event management function. After the premium allocation event message is generated, the premium allocation event message may be sent to other blockchain nodes to reach a consensus. After consensus is reached, the premium allocation event message is stored on the blockchain. At 634, the event message may then be notified to the blockchain node 604 associated with the service platform 602 and the blockchain node 608 associated with the insurance provider 610.

[0116] At 636, blockchain node 608 may determine whether a premium allocation event message is received. If so, the event message may be forwarded to insurance provider 610. Otherwise, at 640, a feedback message may be sent by blockchain node 608. At 638, blockchain node 604 may determine whether a premium allocation event message is received. If so, the event message may be forwarded to service platform 602. Otherwise, at 642, a feedback message may be sent by blockchain node 604. In some examples, the feedback message sent at 640 or 642 by blockchain node 604 or blockchain node 608, respectively, may be similar to the feedback message sent at 624.

[0117] In some cases, the smart contract may call the event management function to periodically generate event messages until an ACK is received. In some cases, if it is determined that the event message is not correctly received or is not received within a predetermined time period, the feedback message may be a NACK. In this case, at 644, it may be determined that the event message needs to be resent. After receiving the premium allocation event message, the service platform 602 may notify the e-commerce platform to allocate the premium to the service provider. In some examples, the service platform 602 may forward the event message to other service providers, such as an e-commerce platform and a transportation insurance broker.

[0118] Figure 7 An example of a system for realizing a transportation insurance service platform 700 based on blockchain to enable safe and efficient processing of transportation insurance documents according to an embodiment of the present invention is shown. The platform 700 provides an integrated interface that allows users to manage the information used in each stage of transportation insurance generation and insurance premium allocation processing. The service platform 700 provides services related to each stage of processing transportation insurance documents. In some embodiments, the service platform 700 provides services to insurance brokers 706, so that the transportation insurance services processed by insurance brokers 706 can be recorded in a safe manner, such as stored in a blockchain database and smart contract data cache. In some embodiments, the service platform 700 can also provide services to other entities associated with purchase orders or credit insurance orders through a network 718 such as the Internet, and other entities are, for example, one or more insurance providers 702, one or more insurance brokers 706, one or more banks or payment companies 708, one or more delivery service companies 710, e-commerce platforms 712 or online sellers, one or more insured persons 714, and one or more administrators 716.

[0119] For example, insurance provider 702 may be responsible for providing and processing transportation insurance services, such as reviewing information about insurance applications, assessing eligibility for insurance, and assessing duties, taxes, and fees associated with transportation insurance. Insurance provider 702 may also be responsible for detecting fraudulent activity intended to commit insurance fraud.

[0120] One feature of the service platform 700 is that the platform is able to link multiple types of documents associated with a purchase order or link multiple purchase orders, so that the insurance provider 702 can more easily review the information recorded in multiple documents associated with the purchase order, and thus can more easily detect inconsistencies or anomalies indicating potential fraudulent activities in the documents. Another feature of the service platform 700 is that the platform provides encryption services for encrypting private information to protect user privacy. Another feature of the service platform 700 is that the transportation information, insurance terms and conditions, and insurance premium allocation information are recorded in the blockchain database through the consensus of the blockchain nodes 734 of the blockchain network 732, and the information can be easily verified and trusted by all parties with access to the blockchain database. A further feature of the service platform 700 is that the platform can be expanded by using a smart contract pool so that the service platform 700 can handle a large amount of transportation insurance data.

[0121] Insurance broker 706 may be, for example, a professional who prepares and submits documents to obtain transportation insurance from insurance provider 702. Insurance broker 706 may be, for example, an online or web-based system maintained by one or more insurance brokers for collecting and processing information related to transportation insurance. In some examples, insurance broker 706 collects information related to transportation insurance from multiple parties such as banks or payment companies 708, delivery service companies 710, e-commerce platforms 712, and insureds 714, and provides the collected information to insurance broker 706, which then submits the document to insurance provider 702. Insurance broker 706 sends a copy of the document to service platform 700 to save records, for example, by storing the document in blockchain database 740 and / or smart contract data cache 742.

[0122] In some embodiments, the insurance broker 706 submits the document to the service platform 700, and the service platform 700 notifies the insurance provider 702 that the information has been recorded. The insurance provider 702 then accesses the information recorded by the service platform 700 to assess and collect insurance premiums associated with the purchase order and detect fraudulent activity.

[0123] The bank or payment company 708 sends the insurance payment to the e-commerce platform 712. The bank or payment company 708 provides payment information associated with the shipping insurance premium for the purchase order to the insurance broker 706. The bank or payment company 708 also interacts with the service platform 700 to provide, for example, payment information related to the purchase order.

[0124] The delivery service company 710 receives a package including merchandise from the e-commerce platform 712 and generates a delivery document including shipping tracking information associated with the purchase order. The delivery service company 710 provides the delivery document related to the purchase order to the e-commerce platform 712 and the insurance broker 706. The delivery service company 710 transports and delivers the merchandise package to the insured 714. The delivery service company 710 provides updated delivery information, such as updated shipping tracking information, to the insurance broker 706. The delivery service company 710 also interacts with the service platform 700 to provide, for example, shipping tracking information related to the purchase order.

[0125] The e-commerce platform 712 provides information about the purchase order, such as order data, invoice information, shipping insurance order, and shipping tracking number, to the insurance broker 706. In some examples, the e-commerce platform 712 can also act as the insurance broker 706.

[0126] The insured 714 places an order for merchandise and shipping insurance, pays for the merchandise and insurance, and initiates delivery of the merchandise. The insured 714 may provide relevant information to the insurance broker 706. The insured 714 may also interact with the service platform 700, for example to provide information about the purchase order, or to obtain information about the progress of the insurance status for the purchase order.

[0127] Administrator 716 is responsible for controlling which members or parties have access to which information and controlling the authorization levels of users of service platform 700 to ensure that the privacy of users is protected.

[0128] In some examples, the service platform 700 collects information from the above-mentioned parties (e.g., e-commerce platform 712, bank or payment company 708, delivery service company 710, and insured 714) and compiles the information into a format that can be easily reviewed by insurance provider 702. The service platform 700 can link multiple documents obtained from multiple parties to make it easier for insurance provider 702 to review these documents together.

[0129] The service platform 700 interacts with a blockchain network 732 including a plurality of blockchain nodes 734 to securely record information related to transportation insurance in a blockchain database 740 and a smart contract data cache 742. The smart contract data cache 742 can store variable data in the form of smart contract data, while the blockchain database 740 can store incremental, immutable, and permanent blockchain data. This provides a good balance between the processing efficiency and storage cost of blockchain data.

[0130] The service platform 700 is configured to provide tools (e.g., web-based ports and interfaces, APIs, and smart contracts) that enable insurance providers 702, insurance brokers 706, banks or payment companies 708, delivery service companies 710, e-commerce platforms 712, insureds 714, and administrators 716 to conveniently and securely access and process information related to transportation insurance and documents associated with insurance orders. For example, the service platform 700 may provide an interface that facilitates recording, updating, and reviewing order data, logistics data, insurance data, and payment data associated with a purchase order, as well as an interface that facilitates recording information related to transportation insurance in one or more blockchain databases 740 and smart contract data caches 742.

[0131] For example, the service platform 700 may provide tools to implement Figure 3 and Figure 5 In some examples, the service platform 700 includes a transportation insurance service module 720, a user control module 722, a privacy and encryption module 724, a DIS service module 726, a document lifecycle management module 728, and a smart contract service module 730. Figure 3 ) include APIs (e.g., 336, 338, 340, 342, 344, and 346), which users can call to invoke the services of modules 720, 722, 724, 726, 728, and 730, respectively.

[0132] The service platform 700 includes a notification service 348 (described above in conjunction with Figures 3 to 5 ), the notification service 348 enables the blockchain node 734 of the blockchain network 732 to notify the service platform 700 and / or users about updates on document events and user events.

[0133] Many of the functions provided by the service platform 700 related to recording or accessing information stored in the blockchain database 740 and the smart contract data cache 742 involve the use of smart contracts. In some embodiments, the smart contract is developed by a software programmer and / or someone familiar with the transportation insurance generation or insurance premium allocation process, and the administrator 716 registers the smart contract with the blockchain network through the service platform 700.

[0134] For example, the service platform 700 may provide an API (e.g., CreateContract<contractId,body> ). The administrator 716 calls the API provided by the service platform 700 to establish a new smart contract using the blockchain network. The service platform 700 sends a request to the blockchain network to establish a new smart contract. After the blockchain network registers the smart contract on the blockchain, the blockchain network sends a message to the service platform 700 indicating that the new smart contract has been registered on the blockchain. Then, the service platform 700 sends a message to the administrator 716 indicating that the new smart contract has been registered on the blockchain.

[0135] Using the above process, administrator 716 can deploy smart contracts on a blockchain without having to interact with blockchain network 732. Different blockchain networks 732 may have different protocols for deploying smart contracts, and the protocols may not be intuitive to people who are not familiar with these blockchain networks 732. The service platform 700 provides an easy-to-use and consistent application programming interface to enable administrator 716 to deploy smart contracts without having to learn the protocol of each blockchain network used to deploy smart contracts.

[0136] In some examples, the service platform 700 includes a smart contract generator 736, which includes a customizable smart contract template that allows a person who is familiar with transportation insurance processing but is not an expert in computer programming to generate a smart contract suitable for processing transportation insurance data. The person can call the function of the smart contract generator 736 by calling the API in the API layer 334 to generate a smart contract for a specific type of transportation insurance-related document for a specific stage of insurance generation or insurance premium allocation processing. The person can call the function of the smart contract deployment module 738 by calling the API in the API layer 334 to deploy a new smart contract on the blockchain. The smart contract deployment module 738 may include information about the protocol for deploying smart contracts on the reliable blockchain network 732.

[0137] Figure 8 An example of a process 800 that can be performed according to embodiments of the present invention is depicted. For convenience, process 800 will be described as being performed by a system of one or more computers located in one or more locations and appropriately programmed according to the present invention. For example, such as Figure 4 An appropriately programmed internal computer system of internal system 400 may perform process 800 .

[0138] At 802, a computer system receives shipping data and shipping insurance order data associated with a purchase order. In some cases, the shipping data is received from a delivery service provider and proves that the purchase order was shipped by the delivery service provider.

[0139] At 804 , the computer system determines whether a transportation insurance order corresponding to the transportation insurance order data is valid by executing a first smart contract based on the transportation data and one or more first predetermined rules.

[0140] In response to determining that the shipping insurance order is valid, the computer system initiates a consensus algorithm to record the shipping data and the shipping insurance order data on the blockchain at 806. In some cases, the shipping insurance order is received from a shipping insurance service platform or an e-commerce platform, wherein the shipping insurance order indicates one or more of an insurance item, an insurance premium, a declared value of the purchase order, or insurance included in the purchase order.

[0141] At 808 , the computer system generates a first event message by executing the first smart contract, the first event message including a notification that shipping insurance for the purchase order is valid.

[0142] At 810 , the computer system receives shipping insurance premium allocation data indicating allocation of a shipping insurance premium associated with a shipping insurance order to one or more service providers.

[0143] At 812, the computer system determines that the allocation of the shipping insurance premium is legal by executing the second smart contract based on the one or more second predetermined rules. In some cases, the one or more first predetermined rules include one or more of coverage of the declared value of the purchase order, the items covered by the shipping insurance, or the insurance limit of the purchase order, and wherein the shipping insurance order is valid when the purchase order satisfies the one or more first predetermined rules.

[0144] In some cases, the one or more service providers include one or more of a service system, a transportation insurance service platform, or an insurance provider. In some cases, the one or more second predetermined rules provide a transportation insurance premium allocation plan agreed to by the service system, the transportation insurance service platform, or the insurance provider.

[0145] At 814, the computer system initiates a consensus algorithm of the blockchain network to record the transportation insurance premium allocation data on the blockchain. In some cases, the consensus algorithm is one of proof of work (PoW), proof of stake (PoS), or practical Byzantine fault tolerance (PBFT).

[0146] At 816, the computer system generates a second event message by executing the second smart contract, the second event message notifying that the transportation insurance premium is allocated according to the transportation insurance premium allocation data. In some cases, the first event message and the second event message are stored as transactions on the blockchain.

[0147] In some cases, the first event message is included in a plurality of event messages for an insurance provider, and the first event message is transmitted to the insurance provider by a blockchain node associated with the insurance provider, and wherein the transportation insurance premium is received in response to transmitting the first event message to the insurance provider. In some cases, the second event message is included in a plurality of event messages for one or more service providers.

[0148] In some cases, in response to determining that the transportation insurance order is valid, the service system withholds the transportation insurance premium, and in response to determining that the distribution of the transportation insurance premium is legal, distributes the insurance premium to the service system, the transportation insurance service platform, and the insurance provider according to one or more second predetermined rules.

[0149] Fig. 9 is a diagram of an example of a module of an apparatus 900 according to an embodiment of the present invention. Apparatus 900 may be an example of an embodiment of a computer system configured to provide a message service. Apparatus 900 may correspond to the above-mentioned embodiment, and apparatus 900 includes the following: a receiving module 902, which receives transportation data and transportation insurance order data associated with a purchase order; a determining module 904, which determines whether the transportation insurance order corresponding to the transportation insurance order data is valid by executing a first smart contract based on the transportation data and one or more first predetermined rules; an initiating module 906, which, in response to determining that the transportation insurance order is valid, initiates a consensus algorithm to record the transportation data and transportation insurance order data on a blockchain; a generating module 908, which generates a first event message by executing the first smart contract, the first event message including the transportation insurance of the purchase order. A valid notification; a receiving module 902, which receives transportation insurance premium allocation data, which indicates the allocation of transportation insurance premiums associated with the transportation insurance order to one or more service providers; a determination module 904, which determines that the allocation of transportation insurance premiums is legal by executing a second smart contract based on one or more second predetermined rules; an initiation module 906, which initiates a consensus algorithm of the blockchain network to record the transportation insurance premium allocation data on the blockchain; a generation module 908, which generates a second event message by executing a second smart contract, and the second event message notifies the allocation of transportation insurance premiums according to the transportation insurance premium allocation data.

[0150] In an optional embodiment, the first event message and the second event message are stored as transactions on the blockchain.

[0151] In an optional embodiment, the first event message is included in a plurality of event messages to an insurance provider, and the first event message is transmitted to the insurance provider via a blockchain node associated with the insurance provider, and wherein the transportation insurance premium is received in response to transmitting the first event message to the insurance provider.

[0152] In an alternative embodiment, the second event message is included in a plurality of event messages to one or more service providers.In an alternative embodiment, the shipping data is received from a delivery service provider and verifies that the purchase order was shipped by the delivery service provider.

[0153] In an optional embodiment, the one or more first predetermined rules include one or more of coverage of the declared value of the purchase order, items covered by the shipping insurance, or an insurance limit of the purchase order, and wherein the shipping insurance order is valid when the purchase order satisfies the one or more first predetermined rules.

[0154] In an optional embodiment, the transportation insurance order is received from a transportation insurance service platform or an e-commerce platform, and wherein the transportation insurance order indicates one or more of insurance items, insurance premiums, declared values ​​of the purchase order, or insurance included in the purchase order.

[0155] In an optional embodiment, the consensus algorithm is one of Pow, PoS or PBFT. In an optional embodiment, the one or more service providers include one or more of a service system, a transportation insurance service platform or an insurance provider.

[0156] In an optional embodiment, the one or more second predetermined rules provide a transportation insurance premium allocation plan agreed upon by the service system, the transportation insurance service platform, or the insurance provider.

[0157] In an optional embodiment, in response to determining that the transportation insurance order is valid, the service system withholds the insurance premium, and in response to determining that the distribution of the transportation insurance premium is legal, the insurance premium is distributed to the service system, the transportation insurance service platform and the insurance provider according to one or more second predetermined rules.

[0158] Fig.10 1000 is a flowchart of another example of a process 1000 according to an embodiment of the present invention. For convenience, the process 1000 will be described as being performed by a blockchain node, which may include a system of one or more computers located in one or more locations and appropriately programmed according to the present invention. For example, such as Figure 1 Process 1000 may be performed by a suitably programmed computer system of computer system 100 .

[0159] At 1002, based on initiating a consensus algorithm by a blockchain node associated with the service system, the blockchain node stores the shipping data and the shipping insurance order data associated with the purchase order on the blockchain. In some cases, the consensus algorithm is one of Pow, PoS, or PBFT.

[0160] At 1004, the blockchain node determines whether a transportation insurance order associated with the transportation insurance data is valid by executing a smart contract based on the transportation data and one or more first predetermined rules. In some cases, the transportation insurance order indicates one or more of an insurance item, an insurance premium, a declared value of the purchase order, or insurance included in the purchase order.

[0161] At 1006, in response to determining that the transportation insurance order is valid, the blockchain node generates an event message dedicated to notifying the insurance provider that the transportation insurance purchased for the order is valid by executing the smart contract.

[0162] At 1008, the blockchain node stores the event message in a hardware cache managed by the service system. At 1010, the blockchain node sends the event message to a blockchain node associated with the insurance provider. In some cases, the event message is sent periodically until a feedback message is received.

[0163] In response to receiving the feedback message from the blockchain node associated with the insurance provider, the blockchain node processes the event message at 1012. In some cases, the feedback message indicates that the event message is received by the blockchain node associated with the insurance provider, and processing the event message includes: storing the event message on the blockchain based on executing the consensus algorithm; and deleting the event message from the hardware cache.

[0164] In some cases, when the feedback message indicates that the event message was not properly received or was not received within a predetermined time period, processing the event message includes resending the event message to a blockchain node associated with the insurance provider.

[0165] In some cases, the event message is a first event message, the smart contract is a first smart contract, the feedback message is a first feedback message, and the blockchain node further receives a second event message for one or more service providers from a blockchain node associated with an insurance provider, wherein the second event message notifies an allocation of a transportation insurance premium associated with the transportation insurance order to the one or more service providers. In some cases, the one or more service providers include one or more of a service system, a transportation insurance service platform, or an insurance provider.

[0166] In some examples, the blockchain node also sends a second feedback message to a blockchain node associated with the insurance provider to indicate that the second event message was correctly received, and determines that the allocation of the transportation insurance premium is legal by executing the second smart contract based on one or more second predetermined rules. In some examples, the blockchain node also stores the second event message on the blockchain based on a consensus algorithm; and sends the second event message to one or more service providers.

[0167] In some cases, in response to transmitting the first event message to the insurance provider, the blockchain node also receives transportation insurance premium allocation data from a blockchain node associated with the insurance provider; and based on the consensus algorithm, stores the transportation insurance premium allocation data on the blockchain.

[0168] In some cases, the one or more second predetermined rules provide an insurance premium allocation plan agreed upon by the service system, the transportation insurance service platform, or the transportation insurance provider.

[0169] In some cases, the one or more first predetermined rules include one or more of coverage for the declared value of the purchase order, items covered by the shipping insurance, or an insurance limit for the purchase order, and wherein the shipping insurance order is effective when the purchase order satisfies the one or more first predetermined rules.

[0170] Fig.11 1100 is a diagram of another example of a module of the device 1100 according to an embodiment of the present invention. The device 1100 may be an example of an embodiment of a blockchain node. The device 1100 may correspond to the above-mentioned embodiment, and the device 1100 includes the following: a storage module 1102, which stores the transportation data and transportation insurance order data associated with the purchase order on the blockchain based on initiating a consensus algorithm through a blockchain node associated with a service system; a determination module 1104, which determines whether the transportation insurance order associated with the transportation insurance data is valid by executing a smart contract based on the transportation data and one or more first predetermined rules; a generation module 1106, which generates an event message dedicated to notifying the insurance provider that the transportation insurance of the purchase order is valid by executing a smart contract in response to determining that the transportation insurance order is valid; a storage module 1102, which stores the event message in a hardware cache managed by the service system; a sending module 1108, which sends the event message to the blockchain node associated with the insurance provider; and a processing module 1110, which processes the event message in response to receiving a feedback message from the blockchain node associated with the insurance provider.

[0171] In an optional embodiment, the feedback message indicates that the event message is received by a blockchain node associated with the insurance provider, and processing the event message includes: storing the event message on the blockchain based on executing a consensus algorithm; and deleting the event message from a hardware cache.

[0172] In an optional embodiment, when the feedback message indicates that the event message was not correctly received or was not received within a predetermined time period, processing the event message includes resending the event message to a blockchain node associated with the insurance provider. In an optional embodiment, the event message is periodically sent until the feedback message is received.

[0173] In an optional embodiment, the event message is a first event message, the smart contract is a first smart contract, and the feedback message is a first feedback message, and the device 1100 is also used to: receive a second event message for one or more service providers from a blockchain node associated with the insurance provider, wherein the second event message notifies the allocation of the transportation insurance premium associated with the transportation insurance order to the one or more service providers; send a second feedback message to the blockchain node associated with the insurance provider to indicate that the second event message is correctly received; determine that the allocation of the transportation insurance premium is legal by executing the second smart contract based on one or more second predetermined rules; store the second event message on the blockchain according to a consensus algorithm; and send the second event message to one or more service providers.

[0174] In an optional embodiment, device 1100 is also used to: in response to transmitting a first event message to an insurance provider, receive transportation insurance premium allocation data from a blockchain node associated with the insurance provider; and store the transportation insurance premium allocation data on the blockchain based on a consensus algorithm.

[0175] In an optional embodiment, the one or more service providers include one or more of a service system, a transportation insurance service platform, or an insurance provider. In an optional embodiment, the one or more second predetermined rules provide an insurance premium allocation plan agreed to by the service system, the transportation insurance service platform, or the transportation insurance provider.

[0176] In an optional embodiment, the one or more first predetermined rules include one or more of coverage of the declared value of the purchase order, items covered by the shipping insurance, or an insurance limit of the purchase order, and wherein the shipping insurance order is valid when the purchase order satisfies the one or more first predetermined rules.

[0177] In an optional embodiment, the shipping insurance order indicates one or more of the insurance items, the insurance premium, the declared value of the purchase order, or the insurance included in the purchase order. In an optional embodiment, the consensus algorithm is one of Pow, PoS or PBFT.

[0178] The systems, devices, modules or units shown in the foregoing embodiments may be implemented by using a computer chip or entity, or may be implemented by using a product with a specific function. A typical embodiment device is a computer, which may be a personal computer, a laptop computer, a cellular phone, a camera phone, a smart phone, a personal digital assistant, a media player, a navigation device, an email receiving and sending device, a game console, a tablet computer, a wearable device or any combination of these devices.

[0179] For the implementation process of the functions and effects of each module in the device, reference may be made to the implementation process of the corresponding steps in the aforementioned method. For simplicity, the details are omitted here.

[0180] Since the device embodiment corresponds to the method embodiment basically, for the relevant parts, reference can be made to the relevant description in the method embodiment. The device implementation described above is only an example. The modules described as separate components may or may not be physically separated, and the components displayed as modules may or may not be physical modules, may be located in one position, or may be distributed on multiple network modules. Some or all modules may be selected based on actual needs to achieve the goal of the scheme herein. Those of ordinary skill in the art can understand and implement the embodiments of the present application without having to make creative efforts.

[0181] Reference again Figure 8 and Fig.10 , they can be interpreted as showing the internal functional modules and structures of a computer system or blockchain node. In essence, the execution subject can be an electronic device, which includes: one or more processors; one or more computer-readable memories configured to store executable instructions of one or more processors. In some embodiments, the one or more computer-readable memories are coupled to the one or more processors and have programming instructions stored thereon, which can be executed by the one or more processors to execute the algorithms, methods, functions, processes, processes and programs described herein. Also provided herein are one or more non-transitory computer-readable storage media coupled to one or more processors and having instructions stored thereon, which, when executed by the one or more processors, will cause the one or more processors to perform operations in accordance with the embodiments of the methods provided herein.

[0182] The present invention also provides a system for implementing the method provided herein. The system includes one or more processors, and a computer-readable storage medium coupled to the one or more processors and having instructions stored thereon, which, when executed by the one or more processors, causes the one or more processors to perform the operations described in the method embodiment provided herein.

[0183] The embodiments of the subject matter, actions, and operations described herein may be implemented in digital electronic circuits, tangibly embodied computer software or firmware, computer hardware, or a combination of one or more thereof, including the structures disclosed herein and their structural equivalents. The embodiments of the subject matter described herein may be implemented as one or more computer programs, for example, one or more computer program instruction modules, encoded on a computer program carrier for execution by a data processing device, or to control the operation of a data processing device. For example, a computer program carrier may include one or more computer-readable storage media on which instructions are encoded or stored. The carrier may be a tangible, non-transitory computer-readable medium, for example, a magnetic disk, a magneto-optical disk or an optical disk, a solid-state drive, a random access memory (RAM), a read-only memory (ROM), or other media types. Alternatively or additionally, the carrier may be an artificially generated propagation signal, for example, a machine-generated electrical signal, an optical signal, or an electromagnetic signal, which is generated to encode information for transmission to a suitable receiver device for execution by a data processing device. A computer storage medium may be or partly be a machine-readable storage device, a machine-readable storage substrate, a random or serial access memory device, or a combination of one or more thereof. A computer storage medium is not a propagation signal.

[0184] A computer program may also be referred to or described as a program, software, software application, app, module, software module, engine, script or code, and may be written in any form of programming language, including compiled or interpreted languages, or declarative or procedural languages; which may be deployed in any form, including as a stand-alone program or as a module, component, engine, subroutine or other unit suitable for execution in a computing environment, which may include one or more computers in one or more locations interconnected by a data communications network.

[0185] A computer program may, but need not, correspond to a file in a file system. A computer program may be stored in: a portion of a file that holds other programs or data, such as one or more scripts stored in a markup language document; a single file dedicated to the program in question; or multiple coordinated files, such as multiple files storing one or more modules, subroutines, or code portions.

[0186] Processors for executing computer programs include, for example, general and special purpose microprocessors, and any one or more processors of any kind of digital computer. Typically, the processor will receive data and instructions for the computer program to be executed from a non-transitory computer readable medium coupled to the processor.

[0187] The term "data processing apparatus" covers all types of apparatus, devices and machines for processing data, including, for example, a programmable processor, a computer, or multiple processors or computers. The data processing apparatus may include special-purpose logic circuits such as an FPGA (field programmable gate array), an ASIC (application-specific integrated circuit) or a GPU (graphics processing unit). In addition to hardware, the apparatus may also include code that creates an execution environment for a computer program, for example, code that constitutes processor firmware, a protocol stack, a database management system, an operating system, or a combination of one or more of them.

[0188] The processes and logic flows described herein can be performed by one or more computers or processors executing one or more computer programs to perform operations by operating on input data and generating output. The processes and logic flows can also be performed by special purpose logic circuits, such as FPGAs, ASICs, or GPUs, or by a combination of special purpose logic circuits and one or more programmed computers.

[0189] Computers suitable for executing computer programs may be based on general and / or special purpose microprocessors, or any other kind of central processing unit. Typically, the central processing unit will receive instructions and data from a read-only memory and / or a random access memory. Elements of a computer may include a central processing unit for executing instructions and one or more memory devices for storing instructions and data. The central processing unit and the memory may be supplemented with or integrated in a special purpose logic circuit.

[0190] Typically, a computer will also include or be operably coupled to receive data from or transfer data to one or more storage devices. A storage device may be, for example, a magnetic disk, a magneto-optical disk or optical disk, a solid-state drive, or any other type of non-temporary computer-readable medium. However, a computer need not have such a device. Thus, a computer may be coupled to one or more storage devices, such as one or more memories located locally and / or remotely. For example, a computer may include one or more local memories as computer-integrated components, or a computer may be coupled to one or more remote memories located in a cloud network. In addition, a computer may also 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 such as a universal serial bus (USB) flash drive, just to name a few.

[0191] Components may be "coupled" to one another by being connected to one another for communication, either directly or via one or more intermediate components, such as electrical or optical connections. Components may also be "coupled" to one another if one of the components is integrated into another component. For example, a memory component, such as an L2 cache component, that is integrated into a processor is "coupled" to the processor.

[0192] To interact with a user, embodiments of the subject matter described herein may be implemented on or configured to communicate with a computer having a display device, such as an LCD (liquid crystal display) monitor, for displaying information to a user, an input device, such as a keyboard and a pointing device, through which a user can provide input to the computer, and a pointing device, such as a mouse, trackball, or touchpad. Other types of devices may also be used to provide interaction with a user; for example, the feedback provided to the user may be any form of sensory feedback, such as visual feedback, auditory feedback, or tactile feedback; and any form of input from the user may be received, including sound, voice, or tactile input. In addition, a computer may interact with a user by sending documents to and receiving documents from a device used by a user; for example, by sending a web page to a web browser on a user's device in response to a request received from the web browser, or by interacting with an application (app) running on a user's device, such as a smart phone or electronic tablet. A computer may also interact with a user by sending text messages or other forms of messages to a personal device, such as a smart phone running a messaging program, and receiving a response message from the user.

[0193] The term "configured to" is used herein in connection with systems, devices, and computer program components. For a system of one or more computers configured to perform a specific operation or action, it means that the system has installed thereon software, firmware, hardware, or a combination thereof that causes the system to perform the operation or action in operation. For one or more computer programs configured to perform a specific operation or action, it means that one or more programs include instructions that, when executed by a data processing device, cause the device to perform the operation or action. For a dedicated logic circuit configured to perform a specific operation or action, it means that the circuit has electronic logic to perform the operation or action.

[0194] Although many specific implementation details are included herein, these should not be understood as limitations on the scope of the protection claimed, but rather as descriptions of features specific to a particular embodiment, the scope of the protection claimed is defined by the claims themselves. Certain features described herein in the context of separate embodiments may also be implemented in combination in a single embodiment. On the contrary, the various features described in the context of a single embodiment may also be implemented in multiple embodiments individually or in any suitable sub-combination. Moreover, although the features described above may work in certain combinations and were even initially claimed, in some cases, one or more features in the combination may be deleted from the combination claimed, and the claims may also be directed to sub-combinations or variations of sub-combinations.

[0195] Similarly, although operations are depicted in the drawings and recited in the claims in a particular order, this should not be understood as requiring that the operations be performed in the particular order shown or in sequence, or that all of the operations shown be performed, in order to achieve the desired results. In some cases, multitasking and parallel processing may be advantageous. In addition, the separation of various system modules and components in the above-described embodiments should not be understood as requiring such separation in all embodiments, and it should be understood that the described program components and systems may generally be integrated together in a single software product or packaged into multiple software products.

[0196] Specific embodiments of the subject matter have been described. Other embodiments are also within the scope of the following claims. For example, the actions recited in the claims can be performed in a different order and still achieve the desired results. As an example, the processes depicted in the accompanying drawings do not require the specific order or sequence shown to achieve the desired results. In some cases, multi-tasking parallel processing may be advantageous.

Claims

1. A computer-implemented method for managing blockchain-based event messages performed by a computing system, the method comprising: storing the shipping data and the shipping insurance order data associated with the purchase order on a blockchain based on initiating a consensus algorithm through a blockchain node associated with the computing system; Determining whether a transportation insurance order associated with the transportation insurance order data is valid by executing a smart contract based on the transportation data and one or more first predetermined rules; In response to determining that the transportation insurance order is valid, generating an event message dedicated to notifying an insurance provider that the transportation insurance for the purchase order is valid by executing the smart contract; wherein the smart contract calls an event management function to periodically generate the event message until a feedback message is received; storing the event message in a hardware cache managed by the computing system; sending the event message to a blockchain node associated with the insurance provider; and In response to receiving the feedback message from the blockchain node associated with the insurance provider, processing the event message.

2. The computer-implemented method of claim 1 , wherein: The feedback message indicates that the event message is received by the blockchain node associated with the insurance provider, and processing the event message includes: Based on executing the consensus algorithm, storing the event message on the blockchain; and The event message is deleted from the hardware cache.

3. The computer-implemented method of claim 1 , wherein: When the feedback message indicates that the event message was not correctly received within a predetermined time period or was not received, processing the event message includes resending the event message to the blockchain node associated with the insurance provider.

4. The computer-implemented method of claim 1 , wherein: The event message is sent periodically until the feedback message is received.

5. The computer-implemented method of claim 1 , wherein: The event message is a first event message, the smart contract is a first smart contract, the feedback message is a first feedback message, and the method further includes: receiving a second event message for one or more service providers from the blockchain node associated with the insurance provider, wherein the second event message notifies allocation of a transportation insurance premium associated with the transportation insurance order to the one or more service providers; sending a second feedback message to the blockchain node associated with the insurance provider indicating that the second event message is correctly received; Determining that the allocation of the transportation insurance premium is legal by executing a second smart contract based on one or more second predetermined rules; storing the second event message on the blockchain based on the consensus algorithm; and The second event message is sent to the one or more service providers.

6. The computer-implemented method of claim 5, further comprising: receiving, in response to transmitting the first event message to the insurance provider, transportation insurance premium allocation data from the blockchain node associated with the insurance provider; as well as Based on the consensus algorithm, the transportation insurance premium allocation data is stored on the blockchain.

7. The computer-implemented method of claim 5, wherein: The one or more service providers include one or more of the computing system, a transportation insurance service platform, or an insurance provider.

8. The computer-implemented method of claim 5, wherein: The one or more second predetermined rules include a transportation insurance premium allocation plan agreed upon by the computing system, the transportation insurance service platform, or the transportation insurance provider.

9. The computer-implemented method of claim 1 , wherein: The one or more first predetermined rules include one or more of coverage of the declared value of the purchase order, items covered by the shipping insurance, or insurance limits of the purchase order, and The transportation insurance order is valid when the purchase order satisfies the one or more first predetermined rules.

10. The computer-implemented method of claim 1, wherein: The transportation insurance order data indicates one or more of insurance items, insurance premiums, declared values ​​of the purchase order, or insurance included in the purchase order.

11. A computer-implemented method according to any preceding claim, wherein: The consensus algorithm is one of Proof of Work (PoW), Proof of Stake (PoS), or Practical Byzantine Fault Tolerance (PBFT).

12. A system for managing blockchain-based event messages, comprising: one or more processors; and One or more computer readable memories coupled to the one or more processors and having instructions stored thereon, the instructions being executable by the one or more processors to perform the method of any one of claims 1 to 11.

13. An apparatus for managing blockchain-based event messages, the apparatus comprising a plurality of modules for executing the method of any one of claims 1 to 11.

Images