HK40042313A - Blockchain-based message services for time-sensitive events - Google Patents

Description

Block chain based messaging service for time sensitive events

Technical Field

This document relates to providing blockchain based messaging services for time sensitive events.

Background

Distributed Ledger System (DLS), which may also be referred to as a consensus network and/or blockchain network, enables participating entities to securely and tamperproof store data. Without reference to any particular use case, DLS is often referred to as a blockchain network. Examples of types of blockchain networks may include public blockchain networks, private blockchain networks, and federation blockchain networks. A federated blockchain network is provided for a selected entity group that controls the consensus process and includes an access control layer.

Digital networks have enabled people around the world to conveniently and efficiently find and interact with information. For example, social media platforms allow people to easily share messages, photos, and videos with friends and colleagues. Online shopping websites allow consumers to easily find information about various products and purchase products from merchants around the world by way of electronic payments. Various payment and delivery services allow e-commerce providers and consumers to more easily conduct online and international transactions and shipments. As more and more people are connected to the internet and more transactions are conducted online through digitization, the need for protection of valuables during transportation and the data to be processed by insurance companies to provide transportation protection is increasing.

Parties such as online shopping platforms, delivery service providers, and insurance companies are often involved in providing transportation insurance. A number of data exchanges may be performed between the parties to fulfill each shipping insurance order and ultimately determine insurance payments. Data and messages exchanged between parties are typically 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 the different parties may be inconsistent, which reduces the processing efficiency of the transportation insurance and insurance premium distribution.

It is desirable to have a unified platform that can provide transparent, efficient, consistent, and verifiable data and messaging services to facilitate the processing and storage of transportation insurance data while ensuring data privacy and integrity for the participating parties.

Disclosure of Invention

Embodiments of the described subject matter may include one or more features, either alone or in combination.

For example, in one embodiment, a computer-implemented method performed by a computing system comprises: receiving transportation data and transportation insurance order data associated with the purchase order; determining whether a transport insurance order corresponding to the transport insurance order data is valid by executing a first intelligent contract based on the transport data and one or more first predetermined rules; initiating a consensus algorithm to record the transportation data and the transportation insurance order data on a blockchain in response to determining that the transportation insurance order is valid; generating a first event message by executing the first intelligent contract, the first event message including a notification that the shipping insurance of the purchase order is valid; receiving transport insurance premium allocation data indicating an allocation of transport insurance premiums associated with the transport insurance order to one or more service providers; determining that the allocation of the transportation insurance premium is legitimate by executing a second intelligent contract based on one or more second predetermined rules; initiating the consensus algorithm of a blockchain network to record the transportation insurance premium allocation data on a blockchain; generating a second event message by executing the second intelligent contract, the second event message notifying allocation of the transportation insurance premium in accordance with the transportation insurance premium allocation data.

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

In some embodiments, the first event message is included in a plurality of event messages for an insurance provider and 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 embodiments, the second event message is included in a plurality of event messages for the one or more service providers.

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

In some embodiments, the one or more first predetermined rules include one or more of an coverage of an declared value of the purchase order, an item covered by the transportation insurance, or an insurance limit of the purchase order, and wherein the transportation insurance order is valid when the purchase order satisfies the one or more first predetermined rules.

In some embodiments, the shipping insurance order is received from a shipping insurance service platform or an e-commerce platform, and wherein the shipping insurance order indicates one or more of an insurance item, an insurance premium, a claim value for the purchase order, or an insurance contained by the purchase order.

In some embodiments, the consensus algorithm is one of proof of workload (PoW), proof of entitlement (PoS), or Practical Byzantine Fault Tolerance (PBFT).

In some embodiments, the one or more service providers comprise 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 a transportation insurance premium distribution plan agreed to by the service system, the transportation insurance service platform or an insurance provider.

In some embodiments, in response to determining that the transport insurance order is valid, the service system withholds an insurance premium, and in response to determining that the allocation of the transport insurance premium is legitimate, allocating the insurance premium to the service system, transport insurance service platform and insurance provider according to the one or more second predetermined rules.

In another embodiment, a computer-implemented method performed by a block link point of a block chain network comprises: storing transportation data and transportation insurance order data associated with the purchase order on the blockchain based on initiating a consensus algorithm by a blockchain node associated with the computing system; determining whether a shipping insurance order associated with the shipping insurance order data is valid by executing an intelligent contract based on the shipping data and one or more predetermined rules; generating, by executing the smart contract, an event message dedicated to notifying an insurance provider that the shipping insurance of the purchase order is valid in response to determining that the shipping insurance order is valid; storing the event message in a hardware cache managed by the computing system; sending the event message to a block chain node associated with the insurance provider; and, in response to receiving a feedback message from the block chain node associated with the insurance provider, processing the event message.

In some embodiments, the feedback message indicates that the event message was received by the blockchain node associated with the insurance provider, and processing the event message comprises: storing the event message on the blockchain based on executing the consensus algorithm; and deleting the event message from the hardware cache.

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 comprises 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.

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 comprises: 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 informs of an allocation of a transport insurance premium associated with the transport insurance order to one or more service providers; sending a second feedback message to the blockchain node associated with the insurance provider indicating correct receipt of the second event message; determining that the allocation of the transportation insurance premium is legitimate by executing a second intelligent 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.

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

In some embodiments, the one or more service providers comprise 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 distribution plan agreed to by the service system, the transport insurance service platform or the transport insurance provider.

In some embodiments, the one or more first predetermined rules include one or more of an coverage of an declared value of the purchase order, an item covered by the transportation insurance, or an insurance limit of the purchase order, and wherein the transportation insurance order is valid when the purchase order satisfies the one or more first predetermined rules.

In some embodiments, the shipping insurance order indicates one or more of an insurance item, an insurance premium, an declared value for the purchase order, or an insurance contained by the purchase order.

It should be understood that any combination of the various aspects and features described herein may be included according to the methods described herein. That is, the methods according to the present disclosure are not limited to the combinations of the various aspects and features specifically described herein, but also include any combination of the various aspects and features provided.

The details of one or more embodiments of the disclosure are set forth in the accompanying drawings and the description below. Other features and advantages will be apparent from the description and drawings, and from the claims.

Drawings

FIG. 1 is a diagram illustrating an example of an environment that may be used to perform embodiments herein.

Fig. 2 is a diagram illustrating an example of an architecture according to embodiments herein.

Fig. 3 is a swim lane diagram illustrating an example of message flow according to embodiments herein.

Fig. 4 is a diagram illustrating an example of an internal system of a service provider according to embodiments herein.

Fig. 5 is a relationship diagram illustrating an example of relationships between sub-models of a transportation insurance data model according to embodiments herein.

Fig. 6 is a diagram illustrating an example of a process of providing message feedback according to an embodiment herein.

Fig. 7 depicts an example of a system according to embodiments herein.

Fig. 8 depicts an example of a process that may be performed according to embodiments herein.

Fig. 9 depicts an example of modules of an apparatus according to embodiments herein.

Fig. 10 depicts another example of a process that may be performed in accordance with embodiments herein.

Fig. 11 depicts another example of modules of an apparatus according to embodiments herein.

Like reference numbers and designations in the various drawings indicate like elements.

Detailed Description

Techniques for blockchain based message services are described herein. These techniques generally involve: receiving transportation data and transportation insurance order data associated with the purchase order; determining whether a transport insurance order corresponding to the transport insurance order data is valid by executing a first intelligent contract based on the transport data and one or more first predetermined rules; initiating a consensus algorithm to record the transportation data and the transportation insurance order data on a blockchain in response to determining that the transportation insurance order is valid; generating a first event message by executing the first intelligent contract, the first event message including a notification that the shipping insurance of the purchase order is valid; receiving transport insurance premium allocation data indicating an allocation of transport insurance premiums associated with the transport insurance order to one or more service providers; determining that the allocation of the transportation insurance premium is legitimate by executing a second intelligent contract based on one or more second predetermined rules; initiating the consensus algorithm of a blockchain network to record the transportation insurance premium allocation data on a blockchain; generating a second event message by executing the second intelligent contract, the second event message notifying allocation of the transportation insurance premium in accordance with the transportation insurance premium allocation data.

Techniques for storage management based on message feedback are also described herein. These techniques generally involve: storing transportation data and transportation insurance order data associated with the purchase order on the blockchain based on initiating a consensus algorithm by a blockchain node associated with the computing system; determining whether a shipping insurance order associated with the shipping insurance order data is valid by executing an intelligent contract based on the shipping data and one or more predetermined rules; generating, by executing the smart contract, an event message dedicated to notifying an insurance provider that the shipping insurance of the purchase order is valid in response to determining that the shipping insurance order is valid; storing the event message in a hardware cache managed by the computing system; sending the event message to a block chain node associated with the insurance provider; and, in response to receiving a feedback message from the block chain node associated with the insurance provider, processing the event message.

The techniques described herein produce several technical effects. In some embodiments, the entire life cycle of the transport insurance service (e.g., insurance order generation and insurance premium distribution) may be recorded on the blockchain. For example, the blockchain may store a non-tamperproof 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 having access to the blockchain. Using block chaining techniques can improve data processing efficiency when data is generated by different entities as compared to point-to-point communications.

In some embodiments, the transport insurance data may be time sensitive. The disclosed intelligent contract techniques allow for rapid verification of the authenticity and validity of shipping information, order information, and shipping insurance orders. The smart contract technique also allows different types of event messages to be generated for different services or service providers associated with the insurance process. The event message may be used to quickly notify the service provider of important insurance events, especially when the total data volume is high. By selectively generating different types of event messages, services associated with significant events may be more easily associated with and identified by a corresponding service provider. In this way, the shipping insurance policy can be quickly validated and insurance premiums can be distributed among service providers in a timely manner.

In some embodiments, a feedback mechanism is provided to strategically manage data retransmission due to potential packet loss. As a result, the time sensitive event message may be released from the cache storage upon receiving positive feedback regarding the data transmission. Time periods that take up valuable cache storage space may be reduced and storage utilization efficiency may be improved. In addition, as the number of data retransmissions is reduced, the consumption of communication bandwidth within the blockchain network may be reduced. The feedback mechanism is particularly suitable for a block chain network with a large number of nodes, the transmission path of a data packet may be relatively long, and the probability of packet loss is increased.

In some embodiments, the privacy of the insurance data may be further protected based on the use of Trusted Execution Environment (TEE) technology. The trusted execution environment is an isolated and trusted computing environment that may be integrated in a blockchain node in a blockchain network. The trusted execution environment processes the plaintext of the insurance-related data and outputs a ciphertext of the data. Using trusted execution environment technology, data can be easily updated inside a trusted execution environment without revealing the actual updates. In addition, the output of the trusted execution environment is encrypted and trusted by the blockchain nodes in the blockchain network, and thus can be efficiently stored into the blockchain after the blockchain nodes achieve consensus.

Further background is provided for embodiments herein, as described above, a Distributed Ledger System (DLS), which may also be referred to as a consensus network (e.g., consisting of Peer-to-Peer (Peer) nodes) and a blockchain network, enables participating entities to securely and non-tamperproof conduct transactions and store data. Although the term blockchain is generally associated with a particular network and/or use case, the use of blockchain herein generally refers to DLS without reference to any particular use case.

Blockchains are data structures that store transactions in a transaction-untamperable manner. Thus, the transactions recorded on the blockchain are reliable and trustworthy. A block chain includes one or more blocks. Each block in the chain is linked to the immediately preceding block in the chain by a cryptographic hash value (cryptographic hash) that contains the preceding block. Each tile 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 merkel (Merkle) trees. A merkel tree is a data structure in which data at leaf nodes of the tree is hashed and all hash values in each branch of the tree are concatenated at the root of the branch (concatenate). This process continues down the tree up to the root of the entire tree where hash values representing all of the data in the tree are stored. By determining whether the hash value purporting to be a transaction stored in the tree is consistent with the structure of the tree, the hash value can be quickly verified.

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

Typically, a federated blockchain network is private among the participating entities. In a federated blockchain network, consensus processes are controlled by a set of authorized nodes, which may be referred to as consensus nodes, one or more of which are operated by respective entities (e.g., financial institutions, insurance companies). For example, a federation of ten (10) entities (e.g., financial institutions, insurance companies) may operate a federated blockchain network, with each entity operating at least one node in the federated blockchain network.

In some examples, in a federated blockchain network, a global blockchain is provided as a blockchain that is replicated across all nodes. That is, all the consensus nodes are in a fully consensus state with respect to the global blockchain. To achieve consensus (e.g., agree to add a block to a blockchain), a consensus protocol is implemented within the federated blockchain network. For example, a federated blockchain network may implement a Practical Byzantine Fault Tolerant (PBFT) consensus, which will be described in further detail below.

FIG. 1 is a diagram illustrating an example of an environment 100 that may be used to perform embodiments herein. In some examples, environment 100 enables entities to participate in a federated 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 backend systems. In some examples, network 110 may be accessed through wired and/or wireless communication links. In some examples, network 110 enables communication with federated blockchain network 102 as well as communication within federated blockchain network 102. In general, network 110 represents one or more communication networks. In some cases, the computing systems 106, 108 may be nodes of a cloud computing system (not shown), or each of the computing systems 106, 108 may be a separate cloud computing system that includes multiple computers interconnected by a network and functioning as a distributed processing system.

In the depicted example, computing systems 106, 108 may each include any suitable computing device capable of participating as a node in federation 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 carry one or more computer-implemented services for interacting with federation blockchain network 102. For example, the computing system 106 may host a computer-implemented service of 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 of 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). In the example of fig. 1, the federated blockchain network 102 is represented as a peer-to-peer network of nodes, and the computing systems 106, 108 provide the nodes of the first and second entities, respectively, participating in the federated blockchain network 102.

Fig. 2 is an example illustrating an architecture 200 according to embodiments herein. The exemplary concept 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 that includes a plurality of nodes 214, at least some of which record information in a blockchain 216 without tampering. As detailed further herein, although a single blockchain 216 is schematically depicted in blockchain network 212, multiple copies of blockchain 216 are provided and maintained on blockchain network 212.

In the depicted example, each participant system 202, 204, 206 is provided by or represents 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 respective participants to participate in the blockchain network. In the example of fig. 2, a participant corresponds to each node 214. However, it is contemplated that one participant may operate multiple nodes 214 within blockchain network 212, and/or that multiple participants may share a node 214. In some examples, the participant systems 202, 204, 206 communicate with the blockchain network 212, or through the blockchain network 212, using a protocol (e.g., hypertext transfer protocol secure (HTTPS)) and/or using a Remote Procedure Call (RPC).

The nodes 214 may have different degrees of participation within the blockchain network 212. For example, some nodes 214 may participate in the consensus process (e.g., as miners' nodes that add tiles to the 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, the data access privileges may restrict blockchain data stored by the respective participants within their respective systems. In the example of fig. 2, participant systems 202, 204, and 206 store full copies 216', 216 ", and 216"', respectively, of block chain 216.

A blockchain (e.g., blockchain 216 of fig. 2) consists of a series of blocks, each block storing data. Examples of data include transaction data representing transactions between two or more participants. Although "transaction" is used herein by way of non-limiting example, it is contemplated that any suitable data may be stored in the blockchain (e.g., documents, images, video, audio). Examples of transactions may include, but are not limited to, the exchange of value (e.g., assets, products, services, currency). Transaction data is stored in the blockchain in a tamperproof manner. That is, the transaction data cannot be changed.

The transaction data is hashed prior to being stored in the chunk. The hash process is a process of converting transaction data (provided as character string data) into a hash value of a fixed length (also provided as character string data). It is not possible to perform a de-hash process (un-hash) on the hash value to obtain the transaction data. The hashing process may ensure that even slight changes in the transaction data result in an entirely different hash value. Further, as described above, the hash value has a fixed length. That is, the length of the hash value is fixed regardless of the size of the transaction data. The hash process includes processing the transaction data through a hash function to generate a hash value. Examples of hash functions include, but are not limited to, Secure Hash Algorithm (SHA) -256, which outputs a 256-bit hash value.

Transaction data for a plurality of transactions is hashed and stored in a block. For example, hash values for two transactions are provided, and themselves are hashed to provide another hash value. This process is repeated until a single hash value is provided for all transactions to be stored in the block. This hash value is called a Merkle root hash value and is stored in the chunk header. Any change in a transaction causes its hash value to change and ultimately the Merkle root hash value to change.

The blocks are added to the block chain by a consensus protocol. A plurality of nodes in a blockchain network participate in a consensus protocol and perform work to add a block to a blockchain. Such nodes are referred to as consensus nodes. The PBFT introduced above serves as a non-limiting example of a consensus protocol. The consensus node performs a consensus protocol to add transactions to the blockchain and updates the overall state of the blockchain network.

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

Typically, PBFT provides a practical byzantine state machine replication that is tolerant of byzantine errors (e.g., failed nodes, malicious nodes). This is achieved by assuming in the PBFT that a failure will occur (e.g., assuming there is an independent node failure and/or a manipulated message sent by a consensus node). In PBFT, the consensus nodes are provided in a sequence comprising a primary consensus node and a backup consensus node. The master consensus node is changed periodically. The transaction is added to the blockchain by agreeing on the global state of the blockchain network by all consensus nodes within the blockchain network. In this process, messages are transmitted between the consensus nodes, and each consensus node proves that the message was received from a designated peer node and verifies that the message was not modified during transmission.

In PBFT, the consensus protocol is provided in multiple phases with all consensus nodes starting in the same state. First, a client sends a request to a master consensus node to invoke a service operation (e.g., perform a transaction within a blockchain network). In response to receiving the request, the primary consensus node multicasts the request to the standby consensus node. The backup consensus node executes 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 fault-aware nodes that can be tolerated within the blockchain network. The end result is that a sufficient number of consensus nodes agree on the order of records to be added to the blockchain and that record is either accepted or rejected.

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

Asymmetric encryption uses key pairs, each key pair comprising a private key and a public key, the private key being known only to the respective node, and the public key being known to any or all other nodes in the blockchain network. A node may encrypt data using a public key of another node, and the encrypted data may be decrypted using a private key of the other node. For example, referring again to fig. 2, participant a may encrypt data using participant B's public key 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 the node's private key.

Asymmetric encryption is used to provide a digital signature that enables a participant in a transaction to confirm the other participants in the transaction and the validity of the transaction. For example, a node may digitally sign a message, and another node may confirm that the message was sent by the node based on the digital signature of participant a. Digital signatures may also be used to ensure that messages are not tampered with during transmission. For example, referring again to fig. 2, participant a will be sending 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 as 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 did indeed come from participant A and has not been tampered with.

In some embodiments, nodes of and/or in communication with a blockchain network are capable of operating using a Trusted Execution Environment (TEE). At a higher level, a TEE is a trusted execution environment within 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, the TEE is a separate, secure area of the processor that ensures 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 a so-called Trusted Application (TA) executes within the trusted execution environment and has access to the processor and memory. With TEE, the TA can be protected from attacks by other applications running in the main OS. Furthermore, the TEE encrypts and isolates TAs from each other inside the TEE.

Examples of TEEs include the software protection extension (SGX) provided by intel corporation of santa clara, california. Although SGX is discussed herein by way of example, it is contemplated that any suitable TEE may be used to implement embodiments herein.

SGX provides hardware-based TEE. In SGX, trusted hardware is the core of a Central Processing Unit (CPU), and a portion of physical memory is isolated to protect selected code and data. The isolated portion of memory is called an enclave (enclave). More specifically, the enclave is provided as an Enclave Page Cache (EPC) in memory and mapped to the application address space. The memory (e.g., DRAM) includes a reserved random access memory (PRM) for the SGX. Random access memory is a contiguous memory space in the basic input/output system level and cannot be accessed by any software. Each EPC is a memory set (e.g., 4KB) allocated by the OS to load application data and code in the PRM. 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 may use multiple EPCs, with the EPCs dedicated to a single enclave.

During execution of the TA, the processor operates in a so-called enclave mode when accessing data stored in the enclave. Operation in enclave mode may perform an additional hardware check for each memory access. In SGX, trusted applications are compiled into a trusted part and an untrusted part. For example, the OS, BIOS, privileged system code, Virtual Machine Manager (VMM), System Management Mode (SMM), etc. cannot access the trusted section. In operation, the TA runs in the PRM of memory and creates an enclave. Trusted functions executed by trusted portions within the enclave are called by untrusted portions, and code executing within the enclave treats the data as clear data (unencrypted) and denies external access to the data. The trusted part provides an encrypted response to the call and the TA continues execution.

An authentication process may be performed to verify that a desired node (e.g., a trusted portion of a trusted application) is executing securely within a trusted execution environment provided by the SGX. Typically, the authentication process includes the trusted application receiving an authentication request from a challenger (e.g., another node in the blockchain network, a Key Management System (KMS) of the blockchain network). In response, the trusted application requests that it generate a remote authentication, also referred to as a quote, in-flight. Generating the remote authentication includes the local authentication being sent from the enclave to a so-called quote enclave, which verifies the local authentication and converts the local authentication to the remote authentication by signing the local authentication using the asymmetric authentication key. Remote authentication (quote) is provided to the challenger (e.g., the key management system of the blockchain network).

The challenger verifies the remote authentication using the authentication verification service. For SGX, intel provides Intel Authentication Service (IAS), which receives remote authentication from a challenger and verifies the remote authentication. More specifically, the 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, an error may be indicated. If verified (the expected code is securely executed in the trusted execution environment), the challenger can start or continue to interact with the trusted application. For example, in response to authentication, the key management system (as a challenger) can issue (e.g., via a key exchange process, such as elliptic curve Diffie-hellman (ecdh)) an asymmetric cryptographic key (e.g., a public and private key pair) to a node executing a trusted execution environment to enable the node to securely communicate with other nodes and/or clients. Additional details of trusted execution environment techniques are described, for example, in PCT application PCT/CN2019/081180, filed 2019, 4, 3, the contents of which are incorporated herein by reference.

Fig. 3 is a swim lane diagram illustrating an example of a message flow 300 according to embodiments herein. At a higher level, message flow 300 is transmitted downstream from transport insurance service platform 302 through a federation blockchain network to insurance provider 318 and upstream back to 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 vendors or e-commerce platforms (e.g., ALIBABA, EBAY, or AMAZON), delivery service providers (e.g., FEDEX, DHL, or SFEXPRESS), shipping insurance brokers, insurance providers 318, and so forth. The data services may be based on blockchain techniques implemented on a federated blockchain network. The federated blockchain network may include nodes owned by the service platform 302 and one or more of the other service providers.

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

In some embodiments, the purchase order may also include a selection of a shipping insurance payment to be paid by the buyer. In some examples, the transportation insurance payment is included in the purchase order and may be considered a transportation insurance order. In some examples, a transit insurance order document separate from a purchase order document may be created and provided by a transit insurance broker or insurer. In some embodiments, the shipping document may be provided to service platform 302 by a delivery service provider.

At 304, service platform 302 may send a transportation insurance-related document to a block link point 306 associated with service platform 302. Blockchain node 306 may be a node of a blockchain network.

In some embodiments, some or all of the transport insurance-related document may be encrypted by an encryption key to protect the privacy of the document owner. The document owner may determine which users of service platform 302 may be allowed to access the clear text version of the document and request a system administrator of service platform 302 to set access rights for the document. In some embodiments, the document owner may also provide a list of users that are allowed to access the clear text version of the document in addition to the document owner itself. For example, for a shipping document, the list of users allowed to view the cleartext document may be the service platform 302 and the insurance provider 318.

In some examples, the encryption key used to encrypt the document may be a symmetric key. To set access rights for a user, a system administrator may encrypt the symmetric key using the user's public key. An encrypted version of the symmetric key may be stored in the smart contract. A user with access to the document may retrieve an encrypted version of the symmetric key from the smart contract and decrypt the encrypted version of the symmetric key using its corresponding private key. After decrypting the symmetric key, the user can use it to decrypt the encrypted document.

The service platform 302 includes an Application Programming Interface (API) layer that includes a plurality of APIs that can be invoked by a user to provide services associated with transportation insurance. These APIs may be accessed from a computing device (e.g., a smartphone) through a software Application (APP). In some examples, the API may interact with services including one or more of a transportation insurance-related document registration service, a document data update service, a query service, an insurance history generation service, a premium distribution history service, and the like.

At 308, the block chain link point may invoke the smart contract 310 to store the document as a transaction to the block chain. Transactions added to the blockchain may be verified and agreed upon by the blockchain link points in the blockchain network through consensus based on a consensus algorithm. Exemplary consensus algorithms may include proof of workload (PoW), proof of rights (PoS), PBFT, and the like. Once added, the transaction will become untrustworthy and can be verified by any of the blockchain nodes of the blockchain network.

At 312, smart contract 310 may be executed to generate and store event messages. The event message may include a document event indicating that a new document is recorded on the blockchain and an insurance order event indicating that a new insurance order is valid. Intelligent contracts 310 may also be stored on blockchains as special types of transactions. In some embodiments, intelligent contracts 310 may be invoked 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 nexus associated with an e-commerce platform and a delivery service provider may make API calls to invoke blockchain storage functionality. A blockchain storage function may be invoked to store the purchase order document and the transportation insurance order document 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 invoked to validate and approve the shipping insurance order.

In some embodiments, the service platform 302 may also make API calls to invoke event management functions to generate or perform other management functions for 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 approving the insurance order via the insurance order review function, the event management function can generate an insurance order event indicating that the shipping insurance order is valid.

In some embodiments, the event message may be used to flag or notify events associated with the transport insurance service that require a timely response. By generating event messages, parties involved in the transport insurance service can more easily identify time-sensitive event messages from a large amount of blockchain data.

In some embodiments, the service platform 302 may invoke an insurance order review function to review whether the document satisfies one or more predetermined rules. For example, to generate an event message for the insurance provider 318 indicating that a shipping insurance order is valid, the one or more predetermined rules may include an underwriting range for the declared value of the purchase order, the items covered by the shipping insurance, the insurance limit of the purchase order, and/or a premium allocation plan. Accordingly, the shipping insurance order is validated after invoking the insurance order review function to verify that the declared value of the purchase order is within the coverage, that the items covered by the shipping insurance are insured, and that the insurance amount of the purchase order is below the insurance limit.

In some embodiments, the event message may be stored as an event log on the blockchain. To retrieve the event messages stored in the event log, the block chain nodes associated with different service providers may retrieve the event log periodically or as needed. In some embodiments, after event messages associated with a service are generated, they may be automatically sent to other blockchain nodes to reach consensus. After storing the event message on the blockchain, the event message may be sent to or retrieved by its dedicated service provider. For example, after an event message indicating that the transport insurance order is valid is stored on the blockchain, the insurance provider 318 may retrieve the event message through the blockchain node 314 or send the event message to the insurance provider 318 by the blockchain node 314 at 316.

At 320, the insurance provider 318 can generate and send the service provider agreed premium assignments to the blockchain node for storage on the blockchain. At 322, blockchain node 314 may make an API call to invoke intelligent contract 310 to perform insurance order review functions and verify that the premium distribution conforms to the premium distribution plan agreed to by the service provider. If so, the blockchain storage function of intelligent contract 310 may be invoked to store the premium assignment onto the blockchain.

At 324, intelligent contracts 310 may be executed to generate and store premium assignment event messages. In some embodiments, premium assignment event messages may be generated by invoking event management functions. After the premium assignment event message is generated, it may be sent to other blockchain nodes to reach consensus. After the premium assignment event message is stored on the blockchain, the premium assignment event message may be retrieved 326 by the service platform 302 so that the service platform 302 may notify the e-commerce platform to assign the insurance premium to the eligible service provider accordingly.

Fig. 4 is a diagram illustrating an example of an internal system 400 of a service provider of a transportation insurance service according to embodiments herein. 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 connectivity 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 comprising a plurality of blockchain nodes (for illustrative purposes only blockchain node 410 and blockchain node 412 are shown in fig. 4, it being understood that the blockchain network 409 may comprise many additional blockchain nodes). For example, block link points 410 and 412 may be block link points 306 and 314, depicted in fig. 3, that serve service platform 302 and the insurance provider, respectively.

The APP 402 may be software programming for carrying an API of a service platform to provide data services associated with transportation insurance. The APP 402 may be an interface between a user of the service platform and the internal system 400 of the service platform. For example, the APP 402 may be used to receive input including user profile information, login information, transportation insurance-related service data, and the like. In some embodiments, data related to the transport insurance service may be stored in database 404. Database 404 may include any memory or database module and may 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. The database 404 may store various objects or data, including classes, frames, applications, backup data, business objects, tasks, web pages, web page templates, database tables, repositories storing business or dynamic data, and any other suitable information including any parameters, variables, algorithms, instructions, rules, constraints, or references thereto associated with the use of the APP 402 or the internal system 400.

Exemplary data may include order data, logistics data, tracking data, insurance payment data, premium data, templates, encryption keys, and the like. Further, database 404 may include any other suitable data, such as VPN applications, firmware logs and policies, firewall policies, security or access logs, print or other reporting files, and other files. In some examples, the APP 402 may retrieve data from the database 404 through a database API.

The APP 402 may communicate information related to the transportation insurance service with the computing and connection component 408. In some embodiments, the computing and connecting component 408 may include a trusted computing module 420, a trusted time module 422, and a trusted identity module 424. The 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 a digital signature, and/or zero knowledge proof 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 the one or more processors and configured to provide enhanced privacy and integrity to code and loaded data executing within the one or more data processors.

In some embodiments, the trusted computing module 420 may be configured to record data associated with the transportation insurance service according to privacy laws. For example, the trusted computing module 420 may generate a hash value of a record (i.e., a transaction hash value) and add a chunk that includes the record and the hash value to a blockchain associated with the blockchain network 409. As previously described, the document may contain dynamic data and non-modifiable blockchain data stored in the intelligent contract data cache and blockchain database, respectively. For the same document or smart contract transaction, the transaction hash value of the dynamic data may be stored under the same data structure on the blockchain along with the corresponding blockchain data, so that the dynamic data and non-modifiable blockchain data may be linked. Alternatively or additionally, the transaction hash values for the blockchain data may be stored in the intelligent contract data cache along with the corresponding dynamic data so that the data may be linked.

In some embodiments, the trusted computing module 420 may be configured to provide an authenticated record of steps/operations performed by the APP 402 in response to a request for an authenticated record associated with a transportation insurance service document. The trusted computing module 420 may 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 computing result associated with each of the steps/operations performed by the APP 402.

In some embodiments, the encryption keys used to perform encryption and generate digital signatures and certificates 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 encryption 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.

In some embodiments, the trusted time module 422 may 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 may synchronize its maintained time with the global time employed by the blockchain link points in the blockchain network 409 to ensure the accuracy of the timestamps stored on the blockchain.

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

The trusted identity module 424 may be configured to verify the identity of a 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: (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 stream or download account, (vi) a user ID associated with a movie stream or download account, (vii) a user ID associated with a message or chat account, (viii) a user ID associated with an online bank account, (ix) a user ID associated with a car appointment service, (x) a user ID associated with an online food order service, (xi) a social security number, (xii) a driver 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.

In some embodiments, the unique ID may also include a decentralized identification of the user. The decentralized identity may comprise a Uniform Resource Locator (URL) scheme identity, an identity for the decentralized identity method and an identity dedicated to the decentralized identity method. The decentralized identity may point to a corresponding decentralized identity document, which may include descriptive text in a preset format (e.g., JSON-LD) that is relevant to the owner of the decentralized identity and the decentralized identity. The decentralized identity may be used as a Uniform Resource Identity (URI) for locating the decentralized identity document. The decentralized identity document may include various attributes such as context, decentralized identity principal, public key, authentication, authorization and proxy, service endpoint, creation, update, attestation, and extensibility. The decentralized identity document may define or point to a resource that defines a plurality of operations that may be performed with respect to the decentralized identity. In the examples described herein, the decentralized identity complies with standards specified by the world Wide Web Consortium (W3C). However, other decentralized identifications may also be used.

In some embodiments, the unique ID can be used to uniquely identify an insurance applicant or a transportation insurance order. The service provider may embed a unique ID in the transportation insurance data associated with the insurance applicant before the data is recorded on the blockchain. The insurance provider or supervisor 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 a shipping insurance order belongs to the same insurance applicant and that the data is complete for review. Additional information about unique IDs can be found in application PCT/CN2019/095299 filed on 7/9.2019, application PCT/CN2019/103780 filed on 8/30.2019, and application CN201910963431.0 filed on 11.10/2019. The above applications are incorporated herein by reference.

In some embodiments, the trusted identity module 424 may be configured to verify different insurance applicants located in different areas having different insurance policy systems by using different identifications. For example, the trusted identity module 424 may be configured to verify the identity of a first insurance applicant using at least one of a first set of identifications identified by a first insurance policy system associated with the first insurance applicant, and to verify the identity of a second insurance applicant using at least one of a second set of identifications identified 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 regions having different insurance policy systems.

In some examples, the computation and connection component 408 may also include a router 426 that may route information processed by one or more processors to the block link points 410 in the block chain network 409 communicatively coupled to the internal system 400. As previously described, the blockchain node 410 may be a cloud node that may sign and/or verify messages and communicate with other blockchain nodes. Blockchain node 410 may also be a consensus node in blockchain network 409 that participates in consensus processing. In some embodiments, the internal communication of and between internal system 400 and blockchain network 409 may be performed based on a secure communication protocol such as hypertext transfer protocol security (HTTPS) or Transport Layer Security (TLS). For example, the functions performed by the blockchain nodes 410 may be defined in an intelligent contract, where the miners nodes of the blockchain network perform the functions in the intelligent contract and the consensus full nodes of the blockchain network verify the transaction.

The time, identity and content carried by the transport insurance data recorded on the blockchain may be trusted. The blockchain enables the APP 402 providing the transportation insurance service to maintain an authenticated record of information about events (e.g., who, what, and when) that occur during each of multiple steps or key points in time of the service. The record of information is maintained in compliance with (or more in compliance than previous systems with) predetermined rules. For example, when the order is to be insured by a Chinese insurance provider, the predetermined rule may be "the insurance Law of the people's republic of China".

Fig. 5 is a relationship diagram illustrating an example of relationships between sub-models of a transportation insurance data model 500 according to embodiments herein. The transportation insurance data model 500 may be a computer-implemented model used by one or more APPs of a service platform, such as the service platform discussed in the description of fig. 3 and 4, to process transportation 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.

Service platform user sub-model 502 may be used to model attributes of user accounts that are allowed to access services provided by the service platform. Such a user account may be associated with a user such as a shipping insurance applicant or a customer placing a purchase order. Service platform user sub-model 502 may have a Primary Key (PK) that includes a user account ID and a user name. Each user account may correspond to one or more credit insurance orders modeled under the credit insurance order submodel 504. Each credit insurance order may have a PK with a unique order ID, and one or more Foreign Keys (FKs). FK may include account ID, order amount, and order status. The account ID contained in FK may link the corresponding order to the user account. In this way, the corresponding user account may be found when looking up a credit insurance order.

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

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

Fig. 6 is a swim lane diagram illustrating an example of a process 600 of providing message feedback according to embodiments herein. As discussed in the description of fig. 3, various event messages for different services may be generated to facilitate transport insurance generation and premium distribution. As purchase orders, transportation insurance, and logistics documents accumulate, the amount of data communicated within or through the blockchain network may be high. In some cases, packet loss may occur, especially when data surges occur during busy hours. To avoid losing important event messages, a message feedback process may be implemented.

At 612, the service platform 602 may send one or more of the transport document and the transport insurance order to the blockchain node 604 associated with the service platform. At 614, blockchain link point 604 may invoke an intelligent contract by agreeing with other blockchain nodes of the blockchain network to store the document on blockchain 606. In some embodiments, block link point 604 may be part of service platform 602. In some embodiments, block link point 604 may be a computing device or system that remotely services service platform 602.

In some examples, the smart contract may generate an event message to notify the blockchain link point 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 memory at block chain link point 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.

At 616, the smart contract may determine whether the insurance order is valid based on the transportation insurance order and the transportation documents. For example, in response to a document event, the intelligent contract may invoke an insurance order review function, as discussed in the description of FIG. 3, to validate and approve the shipping insurance order. After an insurance order is approved by the insurance order review function, the intelligent contract may invoke the event management function to generate an insurance order event message indicating that the shipping insurance order is valid.

At 618, the blockchain node 608 associated with the 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, block link point 608 may be a computing device or system that remotely services service platform 602. In some examples, the event message may be automatically sent to blockchain node 608 after generation. In some examples, the event message may be retrieved by blockchain node 608.

At 620, block link point 608 can determine whether an insurance order event message has been received. If so, at 622, the insurance order event message can be forwarded to the insurance provider 610. Otherwise, at 624, a feedback message may be sent by block link point 608. In some cases, the smart contract may invoke event management functions to periodically generate event messages until an Acknowledgement (ACK) to receive feedback is received at 624.

In some cases, the feedback message may be a Negative Acknowledgement (NACK) if it is determined that the event message was not correctly received or not received within the predetermined time period at 620. 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, the event message may be deleted after receiving the ACK from block chain node 608.

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 order validity. In response to receiving the feedback message, an intelligent contract may be executed to retrieve the transport insurance order document from the blockchain 606 to the blockchain link point 608. In some examples, the particular instructions may include sending the event messages in a range of message numbers or in a particular order. In response to receiving the feedback message, the smart contract may be executed to resend the event message in accordance with the scope or order provided by the feedback message.

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

At 632, the blockchain node 608 may execute the intelligent contract to invoke an insurance order review function to verify that the premium distribution conforms to the premium distribution plan agreed to by the service provider. If so, an intelligent contract may be executed to generate and store premium assignment event messages by invoking event management functions. After generating the premium distribution event message, the premium distribution event message may be sent to other blockchain nodes to reach consensus. After agreement is reached, the premium allocation event message is stored on the blockchain. At 634, the block link point 604 associated with the service platform 602 and the block link point 608 associated with the insurance provider 610 may then be notified of the event message.

At 636, block chain node 608 may determine whether a premium assignment 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 the block chain node 608. At 638, block chain node 604 may determine whether a premium allocation event message is received. If so, the event message may be forwarded to the service platform 602. Otherwise, a feedback message may be sent by block-link point 604 at 642. In some examples, the feedback message sent at 640 or 642 by block-linked point 604 or block-linked point 608, respectively, may be similar to the feedback message sent at 624.

In some cases, the smart contract may invoke event management functions to periodically generate event messages until an ACK is received. In some cases, the feedback message may be a NACK if it is determined that the event message was not correctly received or not received within a predetermined time period. In this case, at 644, it may be determined that the event message needs to be resent. Upon receiving the premium assignment event message, the service platform 602 may notify the e-commerce platform to assign a premium to the service provider. In some examples, the service platform 602 may forward the event message to other service providers, such as e-commerce platforms and transportation insurance brokers.

Fig. 7 illustrates an example of a system for implementing a blockchain-based transportation insurance service platform 700 to enable safe and efficient processing of transportation insurance documents according to embodiments herein. The platform 700 provides an integrated interface that allows a user to manage information used in various stages of the transport insurance generation and premium distribution process. Service platform 700 provides services related to the various stages of processing a shipping insurance document. In some embodiments, the service platform 700 provides services to the insurance broker 706 so that transportation insurance services handled by the insurance broker 706 can be recorded in a secure manner, such as stored in a blockchain database and intelligent contract data cache. In some embodiments, service platform 700 may also provide services to other entities associated with the purchase order or credit insurance order, such as 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 platform 712 or online vendors, one or more insureds 714, and one or more administrators 716, over a network 718 such as the internet.

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

One feature of service platform 700 is that the platform is capable of linking multiple types of documents associated with a purchase order or linking multiple purchase orders so that insurance provider 702 can more easily review information recorded in multiple documents associated with a purchase order and can therefore more easily detect inconsistencies or anomalies indicative of potentially fraudulent activity in the documents. Another feature of the service platform 700 is that the platform provides cryptographic services for encrypting private information to protect the privacy of the user. Another feature of the service platform 700 is that the transportation information, insurance terms and conditions, and insurance premium assignment information are recorded in a blockchain database through consensus of blockchain nodes 734 of the blockchain network 732, which can be easily verified and trusted by parties having access to the blockchain database. A further feature of service platform 700 is that the platform can be extended by using a pool of intelligent contracts so that service platform 700 can handle large volumes of transportation insurance data.

Insurance broker 706 may be, for example, a professional that prepares and submits documents to obtain transportation insurance from insurance provider 702. Insurance broker 706 can be an online or network-based system maintained by one or more insurance brokers, for example, 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 bank or payment company 708, delivery service company 710, e-commerce platform 712, and insured 714, and provides the collected information to insurance broker 706, which then submits the documents to insurance provider 702. The insurance broker 706 sends a copy of the document to the service platform 700 to save the record, for example, by storing the document in the blockchain database 740 and/or the intelligent contract data cache 742.

In some embodiments, insurance broker 706 submits the document to service platform 700, and service platform 700 notifies insurance provider 702 that the information has been recorded. Insurance provider 702 then accesses the information recorded by service platform 700 to evaluate and collect insurance premiums associated with the purchase orders and detect fraudulent activity.

The bank or payment company 708 sends insurance payments 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 payment information, for example, relating to purchase orders.

Delivery services company 710 receives a package comprising goods from e-commerce platform 712, generates a delivery document comprising shipping tracking information associated with the purchase order. Delivery service company 710 provides delivery documents related to the purchase order to electronic commerce platform 712 and insurance broker 706. Delivery service company 710 transports and delivers the commodity package to insured life 714. The delivery service company 710 provides updated delivery information, such as updated shipping tracking information, to the insurance broker 706. Delivery services company 710 also interacts with service platform 700 to provide shipping tracking information, for example, relating to purchase orders.

The e-commerce platform 712 provides information about the purchase order, such as order data, invoice information, shipping insurance orders, and shipping tracking numbers to the insurance broker 706. In some examples, e-commerce platform 712 may also act as insurance broker 706.

Insured person 714 places an order for the goods and shipping insurance, pays for the goods and insurance, and initiates delivery of the goods. Insured life 714 can provide relevant information to insurance broker 706. Insured person 714 can also interact with 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.

Administrator 716 is responsible for controlling which members or participants have access to which information and controlling the authorization level of users of service platform 700 to ensure that the privacy of the users is protected.

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

Service platform 700 interacts with blockchain network 732, which includes a plurality of blockchain nodes 734, to securely record information related to transportation insurance in blockchain database 740 and intelligent contract data cache 742. The intelligent contract data cache 742 may store variable data in the form of intelligent contract data, while the blockchain database 740 may store incremental, immutable, persistent blockchain data. This provides a good balance between processing efficiency and storage cost of the blockchain data.

Service platform 700 is configured to provide tools (e.g., network (web) based ports and interfaces, APIs, and intelligent contracts) that enable insurance providers 702, insurance brokers 706, bank 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 purchase orders, as well as an interface that facilitates recording information related to transportation insurance in one or more blockchain databases 740 and intelligent contract data caches 742.

For example, service platform 700 may provide tools to implement processes 300 and 500 of fig. 3 and 5 for processing transportation insurance data. In some examples, 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 an intelligent contract service module 730. API layer 334 includes APIs (described above in connection with fig. 3) that a user may call to invoke the services of modules 720, 722, 724, 726, 728, and 730, respectively.

Service platform 700 includes a notification service 348 (described above in connection with fig. 3-5), which notification service 348 enables block link points 734 of a block chain network 732 to notify service platform 700 and/or a user of updates regarding document events and user events.

Many of the functions provided by the service platform 700 related to recording or accessing information stored in the blockchain database 740 and the intelligent contract data cache 742 relate to the use of intelligent contracts. In some embodiments, the intelligent contracts are developed by software programmers and/or persons familiar with the transportation insurance generation or insurance premium assignment process, and administrator 716 registers the intelligent contracts with the blockchain network through service platform 700.

For example, service platform 700 may provide an API (e.g., createconnect < contract id, body >) that may be used to register for intelligent contracts with blockchain networks. Administrator 716 invokes an API provided by service platform 700 to establish a new intelligent contract using the blockchain network. The service platform 700 sends a request to establish a new intelligent contract to the blockchain network. After the blockchain network registers the intelligent contracts on the blockchain, the blockchain network sends a message to the service platform 700 indicating that a new intelligent contract has been registered on the blockchain. Service platform 700 then sends a message to administrator 716 indicating that a new intelligent contract has been registered on the blockchain.

Using the above-described process, administrator 716 may deploy intelligent contracts on blockchains without interacting with blockchain network 732. Different blockchain networks 732 may have different protocols for deploying smart contracts, and the protocols may not be intuitive to those unfamiliar with these blockchain networks 732. Service platform 700 provides an easy-to-use and consistent application programming interface to enable administrator 716 to deploy intelligent contracts without having to learn the protocols of each blockchain network used to deploy the intelligent contracts.

In some examples, service platform 700 includes a smart contract generator 736, which smart contract generator 736 includes customizable smart contract templates that allow persons familiar with transportation insurance processing, but not computer programming experts, to generate smart contracts suitable for processing transportation insurance data. The person may invoke the functionality of intelligent contract generator 736 by calling an API in API layer 334 to generate an intelligent contract for processing a particular type of transportation insurance-related document for a particular phase of the insurance generation or insurance premium allocation process. The person may invoke the functionality of intelligent contract deployment module 738 by calling an API in API layer 334 to deploy a new intelligent contract on the blockchain. Intelligent contract deployment module 738 may include information regarding the protocol used to deploy the intelligent contract on reliable blockchain network 732.

Fig. 8 depicts an example of a process 800 that may be performed in accordance with embodiments herein. For convenience, process 800 will be described as being performed by a system of one or more computers located at one or more locations and suitably programmed according to the present disclosure. For example, a suitably programmed internal computer system, such as internal system 400 of FIG. 4, may perform process 800.

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

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

At 806, in response to determining that the transportation insurance order is valid, the computer system initiates a consensus algorithm to record the transportation data and the transportation insurance order data on the blockchain. 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 claim value for the purchase order, or an insurance contained in the purchase order.

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

At 810, the computer system receives transportation insurance premium assignment data indicating an assignment of a transportation insurance premium associated with the transportation insurance order to one or more service providers.

At 812, the computer system determines that the allocation of the shipping insurance premium is legitimate by executing a second intelligent contract based on one or more second predetermined rules. In some cases, the one or more first predetermined rules include one or more of an coverage of an declared value for the purchase order, an item covered by the transportation insurance, or an insurance limit for the purchase order, and wherein the transportation insurance order is valid when the purchase order satisfies the one or more first predetermined rules.

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 distribution plan agreed to by the service system, the transportation insurance service platform, or the insurance provider.

At 814, the computer system initiates a consensus algorithm of the blockchain network to record the transportation insurance premium assignment data on the blockchain. In some cases, the consensus algorithm is one of proof of workload (PoW), proof of entitlement (PoS), or Practical Byzantine Fault Tolerance (PBFT).

At 816, the computer system generates a second event message that notifies the allocation of the transportation insurance premium according to the transportation insurance premium allocation data by executing the second intelligent contract. In some cases, the first event message and the second event message are stored as transactions on the blockchain.

In some cases, the first event message is included in a plurality of event messages for the 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.

In some cases, the service system withholds the transportation insurance premium in response to determining that the transportation insurance order is valid, and allocates the insurance premium to the service system, the transportation insurance service platform, and the insurance provider according to one or more second predetermined rules in response to determining that allocation of the transportation insurance premium is legitimate.

Fig. 9 is a diagram of an example of modules of an apparatus 900 according to embodiments herein. Apparatus 900 may be an example of an embodiment of a computer system configured to provide message services. The apparatus 900 may correspond to the above-described embodiments, and the apparatus 900 comprises the following: a receiving module 902 that receives transportation data and transportation insurance order data associated with a purchase order; a determination module 904 that determines whether a transport insurance order corresponding to the transport insurance order data is valid by executing a first intelligent contract based on the transport data and one or more first predetermined rules; an initiating module 906 that initiates a consensus algorithm to record the transportation data and the transportation insurance order data on the blockchain; a generation module 908 that generates a first event message by executing the first intelligent contract, the first event message including a notification that the transportation insurance of the purchase order is valid; a receiving module 902 that receives transportation insurance premium allocation data indicating an allocation of transportation insurance premiums associated with the transportation insurance order to one or more service providers; a determination module 904 that determines that the allocation of the shipping insurance premium is legitimate by executing a second intelligent contract based on one or more second predetermined rules; an initiating module 906 that initiates a consensus algorithm of the blockchain network to record the transportation insurance premium assignment data on the blockchain; a generating module 908 that generates a second event message notifying the allocation of the transportation insurance premium according to the transportation insurance premium allocation data by executing the second intelligent contract.

In an alternative embodiment, the first event message and the second event message are stored as transactions on the blockchain.

In an alternative embodiment, the first event message is included in a plurality of event messages for the 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 an alternative embodiment, the second event message is included in a plurality of event messages for one or more service providers. In an alternative embodiment, the shipping data is received from the delivery service provider and the purchase order is certified for shipment by the delivery service provider.

In an alternative embodiment, the one or more first predetermined rules include one or more of an coverage of an declared value for the purchase order, an item covered by the transportation insurance, or an insurance limit for the purchase order, and wherein the transportation insurance order is valid when the purchase order satisfies the one or more first predetermined rules.

In an alternative embodiment, the shipping insurance order is received from a shipping insurance services platform or an e-commerce platform, and wherein the shipping insurance order indicates one or more of an insurance item, an insurance premium, a claim value for the purchase order, or an insurance contained in the purchase order.

In an alternative embodiment, the consensus algorithm is one of Pow, PoS, or PBFT. In alternative 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 an alternative embodiment, the one or more second predetermined rules provide a transportation insurance premium distribution plan agreed to by the service system, the transportation insurance service platform or the insurance provider.

In an alternative embodiment, the service system withholds the insurance premium in response to determining that the transportation insurance order is valid, and allocates the insurance premium to the service system, the transportation insurance service platform and the insurance provider according to one or more second predetermined rules in response to determining that allocation of the transportation insurance premium is legal.

Fig. 10 is a flow diagram of another example of a process 1000 according to embodiments herein. For convenience, process 1000 will be described as being performed by a block-linked point, which may comprise a system of one or more computers located at one or more locations and suitably programmed according to the disclosure. For example, a suitably programmed computer system, such as computer system 100 of FIG. 1, may perform process 1000.

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

At 1004, the block link point determines whether the transport insurance order associated with the transport insurance data is valid by executing an intelligent contract based on the transport data and one or more predetermined rules. In some cases, the shipping insurance order indicates one or more of an insurance item, an insurance premium, an declared value for the purchase order, or an insurance contained by the purchase order.

At 1006, in response to determining that the transport insurance order is valid, the block link points generate event messages dedicated to notifying the insurance provider that the transport insurance for the purchase order is valid by executing the intelligent contracts.

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

At 1012, the block chain node processes the event message in response to receiving a feedback message from the block chain node associated with the insurance provider. In some cases, the feedback message indicates that the event message was received by a block chain 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 delete the event message from the hardware cache.

In some cases, when the feedback message indicates that the event message was not correctly received or was not received within the predetermined time period, processing the event message includes resending the event message to the block chain node associated with the insurance provider.

In some cases, the event message is a first event message, the intelligent contract is a first intelligent contract, the feedback message is a first feedback message, and the blockchain node further receives a second event message for the one or more service providers from a blockchain node associated with the insurance provider, wherein the second event message informs of 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.

In some examples, the blockchain node further sends a second feedback message to the blockchain linked point associated with the insurance provider indicating correct receipt of the second event message, the allocation of the transportation insurance premium being determined to be legitimate by executing a second intelligent contract based on one or more second predetermined rules. In some examples, the block link point further stores the second event message on the block chain based on a consensus algorithm; and sending a second event message to the one or more service providers.

In some cases, in response to transmitting the first event message to the insurance provider, the blockchain node also receives a transportation insurance premium assignment from a blockchain link point associated with the insurance provider; the transportation insurance premium allocation is stored on the blockchain based on a consensus algorithm.

In some cases, the one or more second predetermined rules provide an insurance premium distribution plan agreed to by the service system, the transportation insurance service platform, or the transportation insurance provider.

In some cases, the one or more first predetermined rules include one or more of an coverage of an declared value for the purchase order, an item covered by the transportation insurance, or an insurance limit for the purchase order, and wherein the transportation insurance order is valid when the purchase order satisfies the one or more first predetermined rules.

Fig. 11 is a diagram of another example of modules of an apparatus 1100 according to embodiments herein. Apparatus 1100 may be an example of an embodiment of a blockchain node. The apparatus 1100 may correspond to the embodiments described above, and the apparatus 1100 comprises the following: a storage module 1102 that stores transportation data and transportation insurance order data associated with the purchase order on a blockchain based on initiating a consensus algorithm by a blockchain node associated with the service system; a determination module 1104 that determines whether a transportation insurance order associated with the transportation insurance data is valid by executing an intelligent contract based on the transportation data and one or more predetermined rules; a generation module 1106 that generates an event message dedicated to notifying an insurance provider that the transportation insurance of the purchase order is valid by executing the smart contract; a storage module 1102 that stores the event message into a hardware cache managed by the service system; a sending module 1108 that sends an event message to a block chain node associated with an insurance provider; and a processing module 1110 that processes the event message in response to receiving the feedback message from the block chain node associated with the insurance provider.

In an alternative embodiment, the feedback message indicates that the event message was received by a block chain node associated with the insurance provider, and processing the event message comprises: storing the event message on the blockchain based on executing the consensus algorithm; and delete the event message from the hardware cache.

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

In an alternative 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, the apparatus 1100 is further configured to: receiving a second event message for the one or more service providers from the block link point associated with the insurance provider, wherein the second event message informs of an allocation of the transport insurance premium associated with the transport insurance order to the one or more service providers; sending a second feedback message to a block link point associated with the insurance provider indicating correct receipt of the second event message; determining that the allocation of the transportation insurance premium is legitimate by executing a second intelligent contract based on one or more second predetermined rules; storing the second event message on the blockchain according to a consensus algorithm; and sending a second event message to the one or more service providers.

In an alternative embodiment, the apparatus 1100 is further configured to: receiving transportation insurance premium allocation data from a block chain node associated with the insurance provider in response to transmitting the first event message to the insurance provider; the transportation insurance premium assignment data is stored on the blockchain based on a consensus algorithm.

In alternative 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 an alternative embodiment, the one or more second predetermined rules provide an insurance premium distribution plan agreed to by the service system, the transport insurance service platform or the transport insurance provider.

In an alternative embodiment, the one or more first predetermined rules include one or more of an coverage of an declared value for the purchase order, an item covered by the transportation insurance, or an insurance limit for the purchase order, and wherein the transportation insurance order is valid when the purchase order satisfies the one or more first predetermined rules.

In an alternative embodiment, the shipping insurance order indicates one or more of an insurance item, an insurance premium, an declared value for the purchase order, or an insurance contained by the purchase order. In an alternative embodiment, the consensus algorithm is one of Pow, PoS, or PBFT.

The systems, apparatuses, modules or units shown in the foregoing embodiments may be implemented by using a computer chip or entity, or may be implemented by using an article having a specific function. Typical embodiment devices are computers, which may be personal computers, laptop computers, cellular phones, camera phones, smart phones, personal digital assistants, media players, navigation devices, email receiving and sending devices, game consoles, tablets, wearable devices, or any combination of these devices.

For the implementation of the functions and actions of each module in the device, reference may be made to the implementation of the corresponding steps in the aforementioned methods. Details are omitted here for simplicity.

As the apparatus embodiments substantially correspond to the method embodiments, reference may be made to the relevant description in the method embodiments for the relevant components. The device implementations described above are merely examples. Modules described as separate components may or may not be physically separate, and components shown as modules may or may not be physical modules, may be located in one location, or may be distributed across multiple network modules. Some or all of the modules may be selected based on actual needs to achieve the goals of the present solution. One of ordinary skill in the art will understand and appreciate embodiments of the present application without undue inventive effort.

Referring again to fig. 8 and 10, they may be interpreted as illustrating the internal functional modules and structure of a computer system or block link point. In essence, the execution subject may be an electronic device comprising: one or more processors; one or more computer-readable memories configured to store executable instructions for the one or more processors. In some embodiments, the one or more computer-readable memories are coupled to the one or more processors and have stored thereon programming instructions that are executable by the one or more processors to perform the algorithms, methods, functions, processes, procedures, 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 that, when executed by the one or more processors, cause the one or more processors to perform operations in accordance with embodiments of the methods provided herein.

Also provided herein are systems for implementing the methods 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, cause the one or more processors to perform operations in accordance with method embodiments provided herein.

Embodiments of the subject matter, the acts, and the operations described herein may be implemented in digital electronic circuitry, tangibly embodied computer software or firmware, computer hardware, or combinations of one or more thereof, including the structures disclosed herein and their structural equivalents. Embodiments of the subject matter described herein may be implemented as one or more computer programs, e.g., one or more modules of computer program instructions, encoded on a computer program carrier for execution by, or to control the operation of, data processing apparatus. For example, the computer program carrier may include one or more computer-readable storage media having instructions encoded or stored thereon. The carrier may be a tangible, non-transitory computer-readable medium such as a magnetic, magneto-optical disk or an optical disk, a solid state drive, Random Access Memory (RAM), Read Only Memory (ROM), or other media types. Alternatively or additionally, the carrier may be an artificially generated propagated signal, e.g., a machine-generated electrical, optical, or electromagnetic signal, that is generated to encode information for transmission to suitable receiver apparatus for execution by the data processing apparatus. The computer storage medium may be or be partially a machine-readable storage device, a machine-readable storage substrate, a random or serial access memory device, or a combination of one or more of them. Computer storage media is not a propagated signal.

A computer program can also be referred to or described as a program, software application, app, module, software module, engine, script, or code and can be written in any form of programming language, including compiled or interpreted languages, or declarative or procedural languages; which can 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 interconnected by a data communications network in one or more locations.

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

Processors for the execution of a computer program include, by way of example, both general and special purpose microprocessors, and any one or more processors of any kind of digital computer. Typically, a processor will receive data from a non-transitory computer-readable medium coupled to the processor and instructions of a computer program for execution.

The term "data processing apparatus" encompasses all types of apparatus, devices, and machines for processing data, including by way of example a programmable processor, a computer, or multiple processors or computers. The data processing device may comprise special purpose logic circuitry, e.g., an FPGA (field programmable gate array), an ASIC (application specific integrated circuit), or a GPU (graphics processing unit). The apparatus can include, in addition to hardware, code that creates an execution environment for the computer program, e.g., code that constitutes processor firmware, a protocol stack, a database management system, an operating system, or a combination of one or more of them.

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, and in particular by, special purpose logic circuitry, e.g., an FPGA, an ASIC, or a GPU, or by a combination of special purpose logic circuitry and one or more programmed computers.

A computer suitable for executing a computer program may be based on a general and/or special purpose microprocessor, or any other kind of central processing unit. Generally, a 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 can be supplemented by, or integrated in, special purpose logic circuitry.

Generally, a computer will also include or be operatively coupled to receive data from or transfer data to one or more storage devices. The storage device may be, for example, a magnetic, magneto-optical disk or optical disc, a solid state drive, or any other type of non-transitory computer readable medium. However, a computer need not have such devices. Thus, a computer may be coupled to one or more storage devices, e.g., one or more memories located locally and/or remotely. For example, a computer may include one or more local memories as an integrated component of the computer, or the 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, e.g., a mobile telephone, 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, to name a few.

Components may be "coupled" to one another by being connected in communication with one another either directly or through one or more intermediate components, e.g., 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 storage component integrated into a processor, such as an L2 cache component, is "coupled" to the processor.

For interacting 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, e.g., an LCD (liquid crystal display) monitor, for displaying information to the user and an input device, e.g., a keyboard and a pointing device, through which the user may provide input to the computer, e.g., a mouse, trackball, or touch pad. Other types of devices may also be used to provide for interaction with a user; for example, feedback provided to the user can be any form of sensory feedback, such as visual feedback, auditory feedback, or tactile feedback; and may receive any form of input from the user, including acoustic, speech, or tactile input. Further, the computer may interact with the user by sending and receiving documents to and from the device used by the user; for example, by sending a web page to a web browser on the user device in response to a request received from the web browser, or by interacting with an application (app) running on the user device, such as a smartphone or electronic tablet. Computers may also interact with users by sending text messages or other forms of messages to personal devices, such as smartphones running messaging programs, and receiving response messages from users.

The term "configured" is used herein in relation to systems, devices, and computer program components. For a system of one or more computers configured to perform particular operations or actions, it is meant that the system has installed thereon software, firmware, hardware, or a combination thereof that, when executed, causes the system to perform the operations or actions. For one or more computer programs configured to perform specific operations or actions, it is meant that the one or more programs include instructions, which when executed by a data processing apparatus, cause the apparatus to perform the operations or actions. By dedicated logic circuitry configured to perform a particular operation or action is meant that the circuitry has electronic logic to perform the operation or action.

Although this document contains many specific implementation details, these should not be construed as limitations on the scope of what may be claimed, but rather as descriptions of features specific to particular embodiments, as defined by the claims themselves. Certain features that are described herein in the context of separate embodiments can also be implemented in combination in a single embodiment. Conversely, various features that are described in the context of a single embodiment can also be implemented in multiple embodiments separately or in any suitable subcombination. Furthermore, although features may be described above as acting in certain combinations and even initially claimed as such, one or more features from a claimed combination can in some cases be excised from the combination, and the claimed combination may be directed to a subcombination or variation of a subcombination.

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

Specific embodiments of the present subject matter have been described. Other embodiments are 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 desirable results. As one example, the processes depicted in the accompanying figures do not require the particular order shown, or sequence, to achieve desirable results. In some cases, multitasking parallel processing may be advantageous.

Claims (13)

1. A computer-implemented method performed by a service system for providing a blockchain-based message service, the method comprising:

receiving transportation data and transportation insurance order data associated with the purchase order;

determining whether a transport insurance order corresponding to the transport insurance order data is valid by executing a first intelligent contract based on the transport data and one or more first predetermined rules;

initiating a consensus algorithm to record the transportation data and the transportation insurance order data on a blockchain in response to determining that the transportation insurance order is valid;

generating a first event message by executing the first intelligent contract, the first event message comprising a notification that the shipping insurance of the purchase order is valid;

receiving transport insurance premium allocation data indicating an allocation of transport insurance premiums associated with the transport insurance order to one or more service providers;

determining that the allocation of the transportation insurance premium is legitimate by executing a second intelligent contract based on one or more second predetermined rules;

initiating the consensus algorithm of a blockchain network to record the transportation insurance premium allocation data on a blockchain; and

generating a second event message by executing the second intelligent contract, the second event message notifying that the transportation insurance premium is allocated according to the transportation insurance premium allocation data.

2. The computer-implemented method of claim 1, wherein the first event message and the second event message are stored as transactions on the blockchain.

3. The computer-implemented method of any of the preceding claims,

the first event message is included in a plurality of event messages for an insurance provider and is transmitted to the insurance provider by a blockchain node associated with the insurance provider, and

receiving the transportation insurance premium in response to transmitting the first event message to the insurance provider.

4. The computer-implemented method of any preceding claim, wherein the second event message is included in a plurality of event messages for the one or more service providers.

5. The computer-implemented method of any preceding claim, wherein the shipping data is received from a delivery service provider and evidences that the purchase order was shipped by the delivery service provider.

6. The computer-implemented method of any of the preceding claims,

the one or more first predetermined rules include one or more of an coverage of an declared value of the purchase order, an item covered by the transportation insurance, or an insurance limit of the purchase order, and

the shipping insurance order is valid when the purchase order satisfies the one or more first predetermined rules.

7. The computer-implemented method of any of the preceding claims,

the shipping insurance order is received from a shipping insurance service platform or an electronic commerce platform, and

the shipping insurance order indicates one or more of an insurance item, an insurance premium, a claim value for the purchase order, or an insurance contained in the purchase order.

8. The computer-implemented method of any preceding claim, wherein the consensus algorithm is one of a workload proof PoW, a rights-of-interest proof PoS, or a practical Byzantine fault tolerant PBFT.

9. The computer-implemented method of any preceding claim, wherein the one or more service providers comprise one or more of the service system, a transportation insurance service platform, or an insurance provider.

10. The computer-implemented method of any preceding claim, wherein the one or more second predetermined rules provide a transportation insurance premium distribution plan agreed by the service system, a transportation insurance service platform or an insurance provider.

11. The computer-implemented method of any of the preceding claims,

in response to determining that the transport insurance order is valid, the service system withholds the transport insurance premium, and

in response to determining that the allocation of the transportation insurance premium is legitimate, allocating the transportation insurance premium to the service system, transportation insurance service platform and insurance provider according to the one or more second predetermined rules.

12. A system for providing a blockchain based message service, comprising:

one or more processors; and

one or more computer-readable memories coupled to the one or more processors and having instructions stored thereon that are executable by the one or more processors to perform the method of any of claims 1-11.

13. An apparatus for providing a blockchain based message service, the apparatus comprising a plurality of modules for performing the method of any of claims 1 to 11.