Blockchain-based trusted platform

Abstract

A blockchain-based trusted platform is provided to improve the trustworthiness of data generated by an application that provides a service such as legal services. The trusted platform includes an application layer having at least one blockchain-based application configured to perform a plurality of steps to provide the service, and a trusted service layer having a trusted time module, a trusted identity module, and a trusted computing module. For each of at least some of the plurality of steps, the application is configured to obtain a verified timestamp from the trusted time module, a verified identity from the trusted identity module, and / or a computing result based on processing of blockchain data using the trusted computing module. The trusted computing module is configured to record in the blockchain information related to the respective step performed by the application and at least one of the verified timestamp, the verified identity, or the computing result.

Description

Technical Field

[0001] This article relates to a blockchain-based trusted platform for enabling trusted digital transactions. Background Technology

[0002] Distributed ledger systems (DLS), also known as consensus networks and / or blockchain networks, enable participating entities to store data securely and immutably. Without referencing any specific use case, DLS is often simply referred to as a blockchain network. Examples of blockchain network types can include public blockchain networks, private blockchain networks, and consortium blockchain networks. Consortium blockchain networks are provided for a selected group of entities that control the consensus process, and they include an access control layer.

[0003] Digital networks enable people around the world to easily and efficiently find information and communicate with each other. 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 on a wide variety of products and pay electronically to purchase products from businesses around the world. News websites provide users with up-to-date information on events happening around the world. Media platforms offer users a vast library of music and movies for online download or streaming. Users can search for legal services online. Ride-hailing platforms enable passengers to easily find transportation and pay for rides using their mobile phones. As more people use the internet and conduct more transactions digitally, the number of deceptive online activities and disputes between parties in digital transactions is also increasing.

[0004] The aim is to allow users to conveniently submit evidence related to online digital transactions to the court system. Summary of the Invention

[0005] This document describes techniques for enabling trusted transactions. These techniques typically involve: a blockchain-based trusted platform providing services to a user in multiple steps; for each of the multiple steps, performing at least one of the following: obtaining a verified timestamp from a trusted time module of the trusted platform; obtaining a verified identity from a trusted identity module of the trusted platform, or obtaining a computation result from a trusted computing module of the trusted platform; and recording data associated with the service provided to the user and at least one of the verified timestamp, the verified identity, or the computation result associated with the step in the blockchain.

[0006] This document also describes techniques for facilitating the service of subpoenas. These techniques typically involve: receiving a request generated by a blockchain application for delivering a notice related to legal proceedings from a servicer to a recipient, wherein the request includes an identity associated with the servicer and an identity associated with the recipient; determining that the servicer is a registered user of the blockchain application based on a match between the servicer's identity and an identity contained in the servicer's registration information recorded on the blockchain; recording the time of receipt of the request on the blockchain; determining whether the recipient is a registered user of the blockchain application based on the identity associated with the recipient; in response to determining that the recipient is a registered user, identifying one or more methods for delivering the notice based on the servicer's registration information and the available communication methods contained in the recipient's registration information; and delivering the notice to the recipient based on at least one of the methods.

[0007] This document also describes techniques for legal document processing. These techniques typically involve: receiving a request from an account of a user associated with a blockchain-based application, the request providing services, wherein the request includes an identity associated with the user; determining the user as a registered user of the blockchain-based application based on a match between the identity and an identity contained in the user's registration information recorded on the blockchain; identifying one or more forms to be filled out and submitted in multiple steps for providing the service; in each of the multiple steps: generating a unique identifier (ID) based on the time of execution of the step and the digital content on the form at that time; recording the unique ID, the time, and the digital content on the blockchain; embedding the unique ID into the digital content at that time by changing one or more attributes associated with the digital content to represent the unique ID, wherein the embedding generates digital content that allows retrieval of the time and the digital content from the blockchain based on the unique ID; and recording the embedded information in the digital content on the blockchain.

[0008] This document also describes techniques for dispute resolution. These techniques typically involve: at a blockchain-based application, receiving a request to resolve a dispute between at least a first party and a second party, wherein the request includes a first identity associated with the first party and a second identity associated with the second party; determining that the first party and the second party are registered users of the blockchain-based application based on a match between the first identity and an identity contained in the first party's registration information recorded on the blockchain, and a match between the second identity and an identity contained in the second party's registration information recorded on the blockchain; recording the time of receiving the request on the blockchain; receiving one or more potential dispute resolution solutions from one or more dispute resolution providers registered in the blockchain-based application; receiving a first option from the first party and a second option from the second party, wherein the first option includes a first group of one or more potential dispute resolution solutions, and the second option includes a second group of one or more potential dispute resolution solutions; recording the time of receiving the first option on the blockchain and recording the time of receiving the second option on the blockchain; and determining (i) that there is at least one common potential dispute resolution solution between the first group of one or more potential dispute resolution solutions and the second group of one or more potential dispute resolution solutions, and / or (ii) that no potential dispute resolution solution is acceptable to both the first party and the second party.

[0009] This article also describes the techniques used to process court judgments. These technologies typically involve: receiving a request associated with an account on a blockchain-based application, the request being for collecting a monetary award issued in a court order, wherein the request includes an identity associated with the account; a trusted identity module determining the authenticity of the order based on a match between the order and an associated hash value recorded on the blockchain; a trusted time module recording a first verified timestamp on the blockchain indicating the time the request was received; invoking the trusted computing module to determine the creditor, debtor, and amount of the monetary award based on parsing the order; determining, based on the trusted identity module and the registration information of the account recorded on the blockchain, that the account is associated with the creditor; invoking the trusted computing module to identify, based on the registration information, the creditor's payment account and one or more of the debtor's payment accounts, the cumulative balance of the debtor's one or more payment accounts being greater than or equal to the amount of the monetary award; invoking the trusted computing module to transfer the amount of the monetary award from the debtor's one or more payment accounts to the creditor's payment account; and the trusted time module recording a second verified timestamp indicating the time the amount of the monetary award was transferred.

[0010] This document also provides a system 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 according to embodiments of the methods provided herein.

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

[0012] Details of one or more embodiments herein are set forth in the accompanying drawings and the following description. Other features and advantages of this document will become apparent from the specification, drawings, and claims. Attached Figure Description

[0013] Figure 1 This is a diagram illustrating an example environment that can be used to perform the embodiments described herein.

[0014] Figure 2 This is a diagram illustrating an example of an architecture according to embodiments of this document.

[0015] Figure 3 This is a diagram illustrating an example of a blockchain-based trusted platform according to embodiments of this document.

[0016] Figure 4 This is a diagram illustrating an example of a system for collecting evidence according to embodiments of this document.

[0017] Figure 5 This is a diagram illustrating an example of a system for providing reliable time according to embodiments of this document.

[0018] Figure 6 This is a diagram illustrating an example of a system for providing trusted identity according to embodiments of this document.

[0019] Figure 7 This is a diagram illustrating an example of a system for providing service of summonses according to embodiments of this document.

[0020] Figure 8 This is a diagram illustrating another example of a system for providing service of summonses according to embodiments of this article.

[0021] Figure 9 This is a flowchart illustrating an example of a process according to embodiments of this document.

[0022] Figure 10 This is a diagram illustrating an example of a system for providing legal document processing according to embodiments of this article.

[0023] Figure 11 This is a flowchart illustrating another example of the processing according to embodiments of this article.

[0024] Figure 12 This is a diagram illustrating an example of a system for providing dispute resolution according to embodiments of this document.

[0025] Figure 13 This is a flowchart illustrating yet another example of the processing according to embodiments of this article.

[0026] Figure 14 This is a diagram illustrating an example of a system for executing a judgment according to embodiments of this document.

[0027] Figure 15 This is a flowchart illustrating yet another example of the processing according to embodiments of this article.

[0028] Figure 16 This is a flowchart illustrating yet another example of the processing according to embodiments of this article.

[0029] Figure 17 Examples of modules of a device according to embodiments herein are depicted.

[0030] Figure 18 An example of a module of another apparatus according to embodiments herein is depicted.

[0031] Figure 19 An example of a module of another apparatus according to embodiments of this document is described.

[0032] Figure 20 An example of a module of another apparatus according to embodiments of this document is described.

[0033] Figure 21 An example of a module of another apparatus according to embodiments of this document is described.

[0034] The same reference numerals and names in the various figures denote the same elements. Detailed Implementation

[0035] This document describes techniques for enabling trusted transactions. These techniques typically involve: a blockchain-based trusted platform providing services to a user in multiple steps; for each of the multiple steps, based on the processing of blockchain data using a trusted computing module of a trusted computing platform, performing at least one of the following: obtaining a verified timestamp from a trusted time module of the trusted platform; obtaining a verified identity from a trusted identity module of the trusted platform, or obtaining a calculation result from a trusted computing module of the trusted platform; and recording data associated with the service provided to the user and at least one of the verified timestamp, the verified identity, or the calculation result associated with the step in the blockchain.

[0036] This document also describes techniques for facilitating the service of subpoenas. These techniques typically involve: receiving a request generated by a blockchain application for delivering a notice related to legal proceedings from a servicer to a recipient, wherein the request includes an identity associated with the servicer and an identity associated with the recipient; determining that the servicer is a registered user of the blockchain application based on a match between the servicer's identity and an identity contained in the servicer's registration information recorded on the blockchain; recording the time of receipt of the request on the blockchain; determining whether the recipient is a registered user of the blockchain application based on the identity associated with the recipient; in response to determining that the recipient is a registered user, identifying one or more methods for delivering the notice based on the servicer's registration information and the available communication methods contained in the recipient's registration information; and delivering the notice to the recipient based on at least one of the methods.

[0037] This document also describes techniques for legal document processing. These techniques typically involve: receiving a request from an account of a user associated with a blockchain-based application, the request for providing services, wherein the request includes an identity associated with the user; determining the user as a registered user of the blockchain-based application based on a match between the identity and an identity contained in the user's registration information associated with the blockchain-based application, recorded on the blockchain; identifying one or more forms to be filled out and submitted in multiple steps for providing the service; in each of the multiple steps: generating a unique identifier (ID) based on the time of execution of the step and the digital content on the form at that time; recording the unique ID, the time, and the digital content on the blockchain; embedding the unique ID into the digital content at that time by changing one or more attributes associated with the digital content to represent the unique ID, wherein the embedding generates digital content that allows retrieval of the time and the digital content from the blockchain based on the unique ID; and recording the digital content of the embedded information on the blockchain.

[0038] This document also describes techniques for dispute resolution. These techniques typically involve: at a blockchain-based application, receiving a request to resolve a dispute between at least a first party and a second party, wherein the request includes a first identity associated with the first party and a second identity associated with the second party; determining that the first party and the second party are registered users of the blockchain-based application based on a match between the first identity and an identity contained in the first party's registration information recorded on the blockchain, and a match between the second identity and an identity contained in the second party's registration information recorded on the blockchain; recording the time of receiving the request on the blockchain; receiving one or more potential dispute resolution solutions from one or more dispute resolution providers registered in the blockchain-based application; receiving a first option from the first party and a second option from the second party, wherein the first option includes a first group of one or more potential dispute resolution solutions, and the second option includes a second group of one or more potential dispute resolution solutions; recording the time of receiving the first option on the blockchain and recording the time of receiving the second option on the blockchain; and determining that (i) there is at least one common potential dispute resolution solution between the first group of one or more potential dispute resolution solutions and the second group of one or more potential dispute resolution solutions, and / or (ii) no potential dispute resolution solution is acceptable to both the first party and the second party.

[0039] This document also describes techniques for processing court judgments. These techniques typically involve: receiving a request associated with an account on a blockchain-based application, the request for collecting a monetary ruling issued in a court order, wherein the request includes an identity associated with the account; a trusted identity module determining the authenticity of the order based on a match between the command and a hash value associated with the command recorded on the blockchain; a trusted time module recording a first verified timestamp on the blockchain indicating the time the request was received; invoking the trusted computing module to determine the creditor, debtor, and amount of the monetary ruling based on parsing the command; determining, based on the trusted identity module and the registration information of the account recorded on the blockchain, that the account is associated with the creditor; invoking the trusted computing module to identify, based on the registration information, the creditor's payment account and one or more payment accounts of the debtor, the cumulative balance of the debtor's one or more payment accounts being greater than or equal to the amount of the monetary ruling; invoking the trusted computing module to transfer the amount of the monetary ruling from the debtor's one or more payment accounts to the creditor's payment account; and the trusted time module recording a second verified timestamp indicating the time the amount of the monetary ruling was transferred.

[0040] To provide further background for the embodiments described herein, as mentioned above, a distributed ledger system (DLS), which may also be referred to as a consensus network (e.g., composed of peer-to-peer nodes) and a blockchain network, enables participating entities to securely and immutably transact and store data. Although the term “blockchain” is often associated with a specific network and / or use case, this document uses “blockchain” to generally refer to DLS without referring to any specific use case.

[0041] A blockchain is a data structure that stores transactions in an immutable manner. Therefore, transactions recorded on a blockchain are reliable and trustworthy. A blockchain consists of one or more blocks. Each block in the chain is linked to the preceding block by a cryptographic hash contained within it. Each block also includes a timestamp, its own cryptographic hash, and one or more transactions. Transactions verified by nodes in the blockchain network are hashed and encoded into a Merkle tree. A Merkle tree is a data structure where data at the leaf nodes is hashed, and all hashes in each branch are concatenated at the root of that branch. This process continues along the tree to the root, where hashes representing all data in the tree are stored. A hash value can be quickly verified as belonging to a transaction stored in the tree by determining whether it matches the tree's structure.

[0042] A blockchain is a decentralized or at least partially decentralized data structure used to store transactions, and a blockchain network is a network of computing nodes that manage, update, and maintain one or more blockchains through broadcasting, verifying, and confirming transactions. As mentioned above, blockchain networks can be provided as public, private, or consortium blockchain networks. This document describes the embodiments described herein in more detail with reference to consortium blockchain networks. However, it is contemplated that the embodiments described herein can be implemented in any suitable type of blockchain network.

[0043] Typically, consortium blockchain networks are private among the participating entities. In a consortium blockchain network, the consensus process is controlled by an authorized set of nodes, often referred to as consensus nodes, which are operated by their respective entities (e.g., financial institutions, insurance companies). For example, a consortium of 10 entities (e.g., financial institutions, insurance companies) can operate a consortium blockchain network, with each entity operating at least one node within the network.

[0044] In some examples, within a consortium blockchain network, the global blockchain is provided as a blockchain replicated across all nodes. That is, all consensus nodes are in full state consensus relative to the global blockchain. To achieve consensus (e.g., agreeing to add a block to the blockchain), a consensus protocol is implemented within the consortium blockchain network. For example, a consortium blockchain network can implement Practical Byzantine Fault Tolerance (PBFT) consensus, which will be described in further detail below.

[0045] Figure 1 This is a diagram illustrating an example of an environment 100 that can be used to perform the embodiments described herein. In some examples, environment 100 enables entities to participate in a consortium blockchain network 102. Environment 100 includes computing devices 106, 108 and a network 110. In some examples, 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 can be accessed via wired and / or wireless communication links. In some examples, network 110 enables communication with or within the consortium blockchain network 102. Typically, network 110 represents one or more communication networks. In some cases, computing devices 106, 108 may be nodes of a cloud computing device (not shown), or each computing device 106, 108 may be a separate cloud computing device comprising multiple computers interconnected via a network and used as a distributed processing system.

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

[0047] Figure 2 An example of architecture 200 according to embodiments herein is depicted. The exemplary conceptual architecture 200 includes participant systems 202, 204, and 206, respectively corresponding to participant A, participant B, and participant C. Each participant (e.g., a user, enterprise) participates in a blockchain network 212 provided as a peer-to-peer network, which includes multiple nodes 214, at least some of which immutably record information in a blockchain 216. As further detailed in the figures, 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.

[0048] In the depicted example, each participant system 202, 204, and 206 is provided by or represents participants A, B, and C, respectively, and functions as their respective nodes 214 in the blockchain network. As used herein, a node typically refers to an individual system (e.g., a computer, a server) connected to the blockchain network 212 and enabling the corresponding participant to participate in the blockchain network. Figure 2 In the example, a participant corresponds to each node 214. However, it is expected that a participant can operate multiple nodes 214 within the blockchain network 212, and / or multiple participants can share a single node 214. In some examples, participant systems 202, 204, 206 communicate with or through the blockchain network 212 using protocols (e.g., Hypertext Transfer Protocol Security (HTTPS)) and / or using Remote Procedure Calls (RPC).

[0049] Node 214 can have different levels of participation within the blockchain network 212. For example, some nodes 214 may participate in consensus processing (e.g., as miner nodes adding blocks to blockchain 216), while other nodes 214 may not participate in this consensus processing. As another example, some nodes 214 may store a complete copy of blockchain 216, while other nodes 214 may store only a partial copy of blockchain 216. For example, data access privileges can restrict the amount of blockchain data that a given participant can store within their respective system. Figure 2 In the example, participant systems 202, 204, and 206 store corresponding complete copies 216', 216”, and 216”' of blockchain 216.

[0050] Blockchain (e.g., Figure 2A blockchain (216) consists of a series of blocks, each storing data. Examples of data include transaction data representing a transaction between two or more participants. Although this document uses the term "transaction" by way of non-limiting example, it is expected that any suitable data can be stored in the blockchain (e.g., documents, images, videos, audio). Examples of transactions can include, but are not limited to, the exchange of things of value (e.g., assets, products, services, currency). Transaction data is stored immutably in the blockchain. That is, transaction data cannot be changed.

[0051] Before transaction data is stored in a block, it is hashed. Hash processing is the process of converting transaction data (provided as string data) into a fixed-length hash value (also provided as string data). It is impossible to dehash the hash value to obtain the transaction data. Hash processing ensures that even slight changes to the transaction data will result in a completely different hash value. Furthermore, as mentioned 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. Hash processing involves processing the transaction data using a hash function to generate a hash value. Examples of hash functions include, but are not limited to, the Secure Hash Algorithm (SHA)-256, which outputs a 256-bit hash value.

[0052] Transaction data from multiple transactions is hashed and stored in a block. For example, two transactions are provided with hashes, and then they themselves are hashed to provide another hash. This process is repeated until a single hash is provided for all transactions to be stored in a block. This hash is called the Merkle root hash and is stored in the block header. Any change in a transaction will cause its hash to change, and ultimately, the Merkle root hash will change.

[0053] Blocks are added to the blockchain via a consensus protocol. Multiple nodes in the blockchain network participate in the consensus protocol and perform the work of adding blocks to the blockchain. Such nodes are called consensus nodes. PBFT, introduced above, serves as a non-restricted example of a consensus protocol. Consensus nodes execute the consensus protocol to add transactions to the blockchain and update the overall state of the blockchain network.

[0054] More specifically, consensus nodes generate block headers, hash all transactions within a block, and combine the resulting hashes in pairs to generate further hashes until a single hash (the Merkle root hash) is provided for all transactions in the block. This hash is then added to the block header. Consensus nodes also determine the hash of the most recent block in the blockchain (i.e., the last block added to the blockchain). Consensus nodes also add a nonce value and a timestamp to the block header.

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

[0056] In PBFT, the consensus protocol is provided in multiple phases, assuming all consensus nodes start in the same state. First, the client sends a request to the primary consensus node to invoke a service operation (e.g., execute a transaction within the blockchain network). Upon receiving the request, the primary consensus node multicasts the request to backup consensus nodes. The backup consensus nodes execute the request and each send a response to the client. The client waits until it receives a threshold number of responses. In some examples, the client waits to receive f+1 responses, where f is the maximum number of faulty consensus nodes that the blockchain network can tolerate. The end result is that a sufficient number of consensus nodes agree on the order in which records are added to the blockchain, either accepted or rejected.

[0057] In some blockchain networks, cryptography is used to maintain transaction privacy. For example, if two nodes want to keep transaction privacy so that other nodes in the blockchain network cannot see the details of the transaction, these two nodes can encrypt the transaction data. Examples of cryptography 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 can be used by multiple nodes, so each node can encrypt / decrypt the transaction data.

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

[0059] Asymmetric encryption is used to provide digital signatures, which allows participants in a transaction to verify the other participants and the validity of the transaction. For example, a node can digitally sign a message, and another node can verify that the message was sent by participant A based on that digital signature. Digital signatures can also be used to ensure that messages are not tampered with during transmission. For example, see again... Figure 2 Participant A will send a message to Participant B. Participant A generates a hash value for the message and then encrypts the hash value using its private key to provide a digital signature for the encrypted hash value. Participant A appends this digital signature to the message and sends the digitally signed message 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 originate from Participant A and has not been tampered with.

[0060] In some embodiments, nodes in a blockchain network and / or nodes communicating with the blockchain network may operate using a Trusted Execution Environment (TEE). At a higher level, a TEE is a trusted execution environment isolated within hardware (one or more processors, memory) from the hardware's operating environment (e.g., operating system (OS), basic input / output system (BIOS)). More specifically, a TEE is a separate, secure area within the processor that ensures the privacy and integrity of code execution and data loaded on the main processor. Within the processor, the TEE runs in parallel with the OS. At least a portion of a so-called Trusted Application (TA) executes within the TEE and has access to the processor and memory. The TEE protects the TA from attacks by other applications running on the main OS. Furthermore, the TEE cryptographically isolates the TAs from each other within the TEE.

[0061] Examples of TEEs include Software Protection Extensions (SGX) provided by Intel Corporation of Santa Clara, California, USA. Although SGX is discussed by way of example in this paper, it is expected that any suitable TEE can be used to implement the embodiments described herein.

[0062] SGX provides a hardware-based TEE. In SGX, the trusted hardware is the core of the central processing unit (CPU), and a portion of physical memory is isolated to protect selected code and data. This isolated portion of memory is called an enclave. More specifically, enclaves are provided as enclave page caches (EPCs) in memory and mapped to the application address space. Memory (e.g., DRAM) includes reserved random access memory (PRM) for SGX. The PRM is the lowest contiguous storage space at the BIOS level, inaccessible to any software. Each EPC is a set of storage (e.g., 4KB) allocated by the OS to load application data and code into the PRM. EPC metadata (EPCM) is the entry address of each EPC and ensures that each EPC can only be shared by one enclave. That is, a single enclave can use multiple EPCs, while an EPC is dedicated to a single enclave.

[0063] During TA execution, the processor operates in a so-called enclave mode when accessing data stored in an enclave. Operation in enclave mode performs additional hardware checks on each memory access. In SGX, the TA is compiled with trusted and untrusted parts. For example, the trusted part cannot be accessed by the OS, BIOS, privileged system code, Virtual Machine Manager (VMM), System Management Mode (SMM), etc. In operation, the TA runs in the PRM of memory and creates the enclave. Trusted functions executed by the trusted part within the enclave are called by the untrusted part, and the code executing within the enclave treats the data as plaintext (unencrypted) and denies external access to that data. The trusted part provides an encrypted response to the call, and the TA continues execution.

[0064] A proof process can be performed to verify that the desired code (e.g., the trusted part of the TA) has been securely executed within the TEE providing the SGX. Typically, the proof process involves the TA receiving a proof request from a challenger (e.g., another node in the blockchain network, the blockchain network's key management system (KMS)). In response, the TA requests its enclave to generate a remote proof, also known as a proof. Generating a remote proof involves sending the local proof from the enclave to a so-called proof enclave, which verifies the local proof and converts it into a remote proof by signing it using an asymmetric proof key. The remote proof (proof) is then provided to the challenger (e.g., the blockchain network's KMS).

[0065] The challenger uses a proof verification service to verify the remote proof. For SGX, Intel provides Intel Authentication Service (IAS), which receives the remote proof from the challenger and verifies it. More specifically, the IAS processes the remote proof and provides a report (e.g., a Proof Verification Report (AVR)) indicating whether the remote proof has been verified. If not verified, an error may be indicated. If verified (the expected code has been securely executed in the TEE), the challenger can begin or continue interacting with the TA. For example, in response to the verification, the KMS (as the challenger) can publish asymmetric encryption keys (e.g., a public and private key pair) to the node executing the TEE (e.g., via a key exchange process such as Elliptic Curve Diffie-Hellman (ECDH)) to enable the node to communicate securely with other nodes and / or clients. Additional details of the TEE technology are described, for example, in PCT application PCT / CN2019 / 081180 filed on April 3, 2019, the contents of which are incorporated herein by reference.

[0066] The aforementioned blockchain and TEE technologies can be used to generate highly reliable records related to online transactions. Online transactions typically involve multiple steps. Instead of empirical records that generate the final result of a transaction (e.g., hashes of data generated at the end of the transaction), the novel system described herein uses data generated during multiple events occurring in the multiple steps of a transaction to generate records that can be used to verify the transaction. Empirical records derived from data of events associated with multiple steps of a transaction are far more reliable than empirical records based solely on the final result of the transaction. In some embodiments, for each piece of data that needs to be verified, not only is each piece of data itself verified, but the process that generates each piece of data is also verified. The process of generating a piece of data may involve multiple steps, and each step of that process is verified. This ensures that the final data is highly reliable because the probability of each step of the process being fraudulently modified is very low. In some embodiments, a tool for collecting evidence in the form of digital data is provided. For each piece of evidence that needs to be verified, not only is the evidence itself verified, but the process that collects or generates each piece of evidence is also verified. The process of collecting or generating an piece of evidence may involve multiple steps, and each step of that process is verified. This ensures that the evidence collected or generated at the end of the process is highly reliable, as the probability of someone deceptively modifying the data at each step of the process is extremely low.

[0067] Reference Figure 3This document describes the technology used to implement a blockchain-based trusted platform 300 (which may be a trusted online platform) that enhances trust between users and provides various legal services or processing tools to allow users to conduct legal proceedings or transactions related to legal services in an efficient manner. The legal service tools provided by the blockchain-based trusted platform 300 include, for example, a blockchain-based subpoena service tool 302, a blockchain-based dispute resolution tool 304, a blockchain-based legal document processing tool 306, and a blockchain-based judgment enforcement tool 308. The subpoena service tool 302 allows the plaintiff to digitally serve notice (e.g., service of a subpoena or other relevant documents) to the defendant in accordance with the legal requirements for subpoena service. The dispute resolution tool 304 allows two or more disputing parties to conveniently find one or more potential (or candidate) solutions from multiple dispute resolution providers (e.g., dispute mediators). The legal document processing tool 306 allows users to digitally complete and submit legal documents in accordance with applicable legal requirements. The judgment enforcement tool 308 allows the plaintiff to enforce a court judgment in accordance with applicable legal requirements, such as digitally issuing a court order to collect a bank charge against the defendant's bank. Tools 302, 304, 306, and 308 are provided in the trusted application layer 322 of the trusted platform 300. The trusted platform 300 also includes a trusted service layer 324, which includes, for example, a trusted time module 310, a trusted identity module 312, and a trusted computing module 314, to support the operation of various legal service tools in the trusted application layer 322.

[0068] The advantage of conducting legal transactions digitally online lies in the speed and efficiency of execution, partly because there is no need to fill out legal documents or deliver them in person or by mail. However, the ephemeral nature of digital data also makes it difficult to authenticate or verify transactions completed digitally online in accordance with court rules of evidence. Unlike altering printed content on paper, which typically leaves traces of modification—such as changes in paper fibers or ink molecules—modifying digital documents usually leaves no trace. Furthermore, digital documents can be corrupted by hardware errors, such as failures in storage systems like disk drives, solid-state drives, and / or storage devices. As a result, the content of digital documents, the identity of the users associated with them, and the time associated with them can be questionable.

[0069] Technologies exist for authenticating digital documents exchanged between two parties, such as calculating a hash value for the digital document and sharing that hash value with both parties. Technologies exist for authenticating the identity of the parties associated with a digital document, such as using verified digital signatures. However, while such technologies can be used in limited circumstances to verify the content of individual documents and / or the identity of the parties associated with them, legal disputes often arise in the absence of agreed-upon hash values ​​or verified digital signatures.

[0070] For example, Party A (e.g., the author of copyrighted material) accuses Party B (e.g., an online publisher) of hosting web pages that contain content infringing on Party A's copyright. Party A files a lawsuit and submits a copy of the web page allegedly containing the copyright-infringing content to the court. Party B denies ever hosting such copyright-infringing material on its web page and claims that Party A modified the content or URL of the web page used as evidence to support this false accusation. Party A claims that after learning of the lawsuit, Party B modified the web page posted on its website and removed the copyright-infringing content. Party B claims that the person who filed the lawsuit is not Party A, but someone else who is not qualified to file a lawsuit. In this case, the evidence and identity of both parties are in question. As another example, Party C (e.g., the seller) claims that Party D (e.g., the buyer) ordered a product on an online flea market but never paid for it. Party C files a lawsuit and submits a copy of the digital order to the court. Party D denies ever placing the order and claims that the order was placed by someone else pretending to be Party D. As yet another example, Party E and Party F negotiate an agreement, make some modifications to an early draft of the agreement, and eventually sign the final version of the agreement. The entire process was completed online, without the exchange of any paper documents. Later, E filed a lawsuit, claiming that F had not complied with certain terms of the agreement. F asserted that it complied with all terms of the agreement and countered that E had fraudulently modified the agreement after digitally signing it. E and F ended up with two different versions of the final digitally signed agreement. To give another example, F signed the agreement but delivered it to the wrong email address before delivering it to E's correct email address, only to discover it several days later. E then relied on the delivery date to enforce the agreement, while F relied on the date the contract was signed. When the court receives such a lawsuit, it may find it difficult to properly adjudicate the dispute due to the difficulty in verifying the authenticity of the evidence provided by the parties.

[0071] In some cases, parties can hire lawyers to collect evidence and submit affidavits to the court to prove its authenticity. However, hiring and coordinating with lawyers can be both expensive and time-consuming. In some situations, the dispute has already occurred, relevant digital documents have been altered, and even lawyers may struggle to collect the necessary evidence.

[0072] The blockchain-based trusted platform 300 solves the above problems by providing a suite of legal service applications that utilize the functions of the trusted time module 310, trusted identity module 312, and trusted computing module 314 to authenticate documents and / or user identities in a manner that conforms to (or conforms to) relevant evidence rules more readily than previous systems.

[0073] Some court systems and government agencies allow citizens to file legal proceedings online. For example, the Internet Court in Hangzhou, China, accepts lawsuits and filings electronically and conducts trials via live streaming. The British Columbia Civil Resolution Tribunal is an online court in Canada that can resolve certain types of disputes online. For instance, Trusted Platform 300 can connect to court systems and provide an integrated user interface, allowing users to conveniently file lawsuits and submit evidence.

[0074] In some embodiments, the novelty of the blockchain-based trusted platform 300 lies in that the platform provides trusted time, trusted identity, and trusted computation, enabling applications providing legal services to maintain verified records of information (e.g., who, what, and when) related to events occurring at each step or key point in time within a multi-step process of the service, in a manner consistent with (or more consistent than previous systems) of evidence rules. These records can be added to the blockchain through consensus among blockchain nodes associated with legal institutions, law enforcement agencies, or dispute resolution bodies. Once added, these records become immutable and can be trusted by courts or parties as evidence of the relevant legal services or procedures.

[0075] For example, some tools offer hashing and digital signature capabilities, allowing users to digitally sign data so that other users can verify that the data has not been altered since it was signed and to verify the identity of the user who signed it. However, there is still a possibility that digitally signed data may contain errors. For example, the data may have been corrupted or tampered with before being signed without the signer's knowledge, or the original digitally signed data may have been intercepted by hackers during transmission and replaced with forged digitally signed data. Based solely on digitally signed data, it may be difficult to prove or refute the authenticity and accuracy of the data. Therefore, it may be difficult to use digitally signed data in legal proceedings to prove its authenticity and accuracy without further evidence, such as testimony from a notary public or licensed lawyer. The technical problem to be solved is how to improve the credibility of data generated by online applications providing legal services.

[0076] A blockchain-based trusted platform 300 enhances the credibility of data generated by applications providing legal services over the network and reduces the probability of forgery or tampering by capturing snapshots of each step (or several key time points) in the process of providing the legal services. Each snapshot includes information provided by a trusted time module 310 and / or a trusted identity module 312, and the snapshots are stored in the blockchain using a trusted computing module 314 to process the blockchain data. The snapshots may include information such as the people, time, and content associated with events occurring in the corresponding step or time point. The probability of forgery or tampering at each step (or each time point) in multiple steps is much lower than the probability of forgery or tampering at a single step (or time point). The trusted time module 310 provides a trusted or verified timestamp, the trusted identity module 312 provides trusted or verified identity information, and the trusted computing module 314 ensures the credibility of the data recorded in the relevant blockchain.

[0077] In some embodiments, the functions of modules 310, 312, and 314 can be invoked by one or more blockchain-based applications or smart contracts executing in the TEE. The TEE is hosted by one or more data processors isolated from the operating systems of one or more data processors and is configured to provide enhanced confidentiality and integrity for the code executed in the one or more data processors and the data loaded thereon. In some examples, applications or smart contracts can invoke the functions of the modules via an application programming interface (API).

[0078] The blockchain-based trusted platform 300 produces the following technical effects: Data related to legal services provided by legal service applications supported by the blockchain-based trusted platform 300 has a high degree of trustworthiness (compared to previous systems). Data verifying the identities of parties involved in legal services has a high degree of trustworthiness. Data verifying the actions performed by parties has a high degree of trustworthiness. Data verifying the timing of events occurring during the provision of legal services has a high degree of trustworthiness. Data verifying the documents displayed, provided, or edited by parties involved in legal services at each step or point in time in multiple steps has a high degree of trustworthiness. A highly reliable record of the transaction history occurring during the provision of legal services can be maintained, including the history of document modifications and responses from parties.

[0079] In some embodiments, the trusted service layer 324 may include additional modules, such as a trusted location module, providing verified location information indicating where a transaction occurred. For example, the trusted location module can be used to prove that an infringement occurred in a specific geographic area and that a lawsuit can be brought in a court with jurisdiction. For example, the trusted location module may be based on information connected to client terminal 404 (… Figure 4The verified location information is generated using data provided by a validated GPS receiver.

[0080] The trusted platform 300 includes additional applications, such as a first application 316, a second application 318, ..., and an Nth application 320, which utilize the functionality of the trusted time module 310, the trusted identity module 312, and the trusted computing module 314. The first application 316 is described below as providing an "Internet Evidence Collection Web Browser" 424 that can be used to collect evidence on the Internet. Figure 4 Examples of ).

[0081] refer to Figure 4 In some embodiments, the trusted platform 300 can be accessed via a network 400, such as the Internet. User 402 accesses the trusted platform 300 using a client terminal 404, which can be, for example, a mobile phone, a personal computer, or any computing device that can connect to the network 400. In some examples, the trusted platform 300 provides limited functionality to users who have not yet registered with the platform. The platform 300 provides users who have already registered with the platform with more (e.g., full) functionality of tools 302, 304, 306, 308, applications 316, 318, 320, and modules 310, 312, 314.

[0082] When registering on platform 300, a user is assigned a user identifier (ID) to identify the user 402 when using the tools and services of platform 300. Each registered user has an account associated with platform 300 and can access the functionality of platform 300 after logging into that account. In some examples, a user can register on platform 300 by providing personal information such as the user's phone number and email address. In some examples, a user can register on platform 300 by providing biometric information such as one or more fingerprints, one or more voiceprints, or iris information provided by a fingerprint sensor, microphone, or iris scanner communicatively coupled to modules 310, 312, 314. When a user accesses the functionality of trusted platform 300, the user can provide additional information to trusted platform 300, and trusted platform 300 associates this additional information with the user's account.

[0083] For example, user 402 can provide a mobile phone number so that user 402 can receive messages from trusted platform 300 on a mobile phone. User 402 can provide payment account information so that user 402 can pay for services on trusted platform 300. For example, a user account may include one or more of the following information, which can be used to verify the identity of user 402: (i) mobile phone number, (ii) credit card number, (iii) user ID associated with an online payment system, (iv) user ID associated with an online shopping account, (v) user ID associated with a music streaming or download account, (vi) user ID associated with a movie streaming or download account, (vii) user ID associated with a messaging or chat account, (viii) user ID associated with an online banking account, (ix) user ID associated with a ride-hailing service, (x) user ID associated with an online food ordering service, (xi) social security number, (xii) driver's license number, (xiii) passport number, (xiv) user ID associated with an online gaming service, (xv) ID issued by a government entity, (xvi) one or more fingerprints, (xvii) one or more voiceprints, or (xviii) iris information.

[0084] exist Figure 4 In the example, user 402 accesses an internet evidence-gathering web browser 424 to search for and view web pages on the internet 400. A client component of the web browser (not shown) executes at client terminal 404 and provides a user interface for displaying web pages to user 402 and receiving user instructions for processing the web pages (e.g., clicks for controlling navigation between web pages). Similarly, in some embodiments, when user 402 accesses tools 302, 304, 306, or 308, or applications 318 or 320, corresponding client components execute at user terminal 404 and provide corresponding user interfaces for interacting with user 402.

[0085] For example, user 402 uses web browser 424 to access webpage 406 (including, for example, webpages 406a and 406b) hosted on a publisher's web server 408. User 402 can initially provide the URL of the publisher's homepage and then click a web link to browse the webpage hosted on web server 408. In some embodiments, when user 402 browses the webpage using internet evidence-gathering web browser 424, web browser 424 invokes trusted identity module 312 to verify user 402's identity. For example, trusted identity module 312 can use any amount of information associated with a user account to verify user 402's identity. For example, the trusted identity module 312 may use one or more of the following information to verify the identity of user 402: (i) mobile phone number, (ii) credit card number, (iii) user ID associated with an online payment system, (iv) user ID associated with an online shopping account, (v) user ID associated with a music streaming or download account, (vi) user ID associated with a movie streaming or download account, (vii) user ID associated with a messaging or chat account, (viii) user ID associated with an online bank account, (ix) user ID associated with a ride-hailing service, (x) user ID associated with an online food ordering service, (xi) social security number, (xii) driver's license number, (xiii) passport number, (xiv) user ID associated with an online gaming service, (xv) ID issued by a government entity, (xvi) one or more fingerprints, (xvii) one or more voiceprints, or (xviii) iris information.

[0086] For example, whenever a predetermined type of event occurs in relation to user 402's use of web browser 424, web browser 424 invokes trusted time module 310 to obtain an empirical timestamp about when the event occurred. The predetermined type of event may include, for example, receiving input from user 402, providing output to user 402, and performing a predetermined type of action or calculation. Receiving input from user 402 may include, for example, receiving a webpage URL, receiving a click command or selection command from user 402, receiving an editing command such as a copy command from user 402, or receiving a file command such as a save command from user 402. Providing output to user 402 may include, for example, displaying the content of a webpage to user 402, playing an audio file to user 402, or playing a video file to user 402.

[0087] Therefore, whenever an event occurs, web browser 424 executes the action requested by user 402 and also invokes trusted time module 310 to obtain a verified timestamp indicating the time the action was performed or the time the event occurred, in which user 402 performs a predetermined type of action, such as providing a URL to web browser 424, clicking a web link on webpage 406, copying text or an image from webpage 406, or downloading content from webpage 406. Web browser 424 invokes trusted computing module 314 to generate a snapshot of the event, which may be in a format containing the following records: user 402's identity, a description of the event (e.g., a description of the performed action), a verified timestamp indicating when the event occurred (e.g., when the action was performed), and information about the webpage associated with the action (e.g., the URL). Trusted computing module 314 generates a hash value for the record and adds a block including the record and the hash value to blockchain 410, which stores records associated with user 402.

[0088] For example, the following events can be associated with user 402's browsing activity.

[0089] a. Event 1: User 402 provides the URL of the publisher's first webpage 406a to web browser 424.

[0090] b. Event 2: Web browser 424 retrieves the first webpage 406a from web server 408 and displays webpage 406a to user 402.

[0091] c. Event 3: User 402 clicks a link pointing to the second webpage 406b.

[0092] d. Event 4: Web browser 424 retrieves the second webpage 406b from web server 408 and displays webpage 406b to user 402.

[0093] e. Event 5: User 402 saved photo 422 on the second webpage 406b with the note: "Found a copyrighted photo on the webpage with URL xxx of publisher X".

[0094] f. Event 6: User 402 exits web browser 424.

[0095] Upon each event, web browser 424 invokes trusted time module 310 to obtain an empirical timestamp indicating the time of the event. Web browser 424 then invokes trusted computing module 314 to update blockchain 410, thereby adding a record containing information about the event. In this example, block 412a stores a record containing information about event 1, block 412b stores a record containing information about event 2, block 412c stores a record containing information about event 3, and so on.

[0096] Trusted platform 300 is associated with one of the nodes 414 in blockchain network 416, where blockchain 410 is replicated across blockchain network 416. For example, one of the nodes 414 may be associated with court computer server 418 that maintains a version of blockchain 410. If user 402 files a lawsuit in court alleging copyright infringement by the publisher of webpage 406b, court staff can access the records in blockchain 410 maintained on court computer server 418 to retrieve the aforementioned information regarding events 1 through 6. Court staff can determine that user 402 viewed a second webpage 406b and saved photo 422 on the second webpage 406b with the following note: "A copyrighted photo was found on a webpage with URL xxx by publisher X." Because the records in blockchain 410 have high credibility, the court accepts the information provided by the records in blockchain 410 as evidence submitted by user 402.

[0097] refer to Figure 5 In some implementations, the trusted time module generates a verified timestamp based on Coordinated Universal Time (UTC) 500 allocated by a national standards body or time information generated by a Global Positioning System (GPS) receiver 502, wherein the GPS receiver 502 obtains time information from positioning systems such as the BeiDou Navigation Satellite System maintained by China, the Global Positioning System maintained by the United States, the Galileo Global Navigation Satellite System maintained by the European Union, the Global Orbital Navigation Satellite System (GLONASS) maintained by Russia, and / or the Quasi-Zenith Satellite System maintained by Japan.

[0098] In some embodiments, users in many countries around the world can access Trusted Platform 300. Different countries may have different requirements or preferences regarding the time information acceptable in legal proceedings. For example, courts in Beijing may accept time information obtained from UTC time provided by the National Time Service Center or from the BeiDou Navigation Satellite System. Courts in New York may accept time information obtained from UTC time provided by the National Institute of Standards and Technology or from the U.S. Global Positioning System. Trusted Platform 300 is configured to determine the legal jurisdiction of a user's place of residence and use a time base acceptable to the corresponding court system when generating timestamps for activities associated with the user. In some examples, Trusted Platform 300 allows users to choose which time base to use.

[0099] refer to Figure 6 In some embodiments, the trusted identity module 312 maintains a user account database 600 that includes information about the registered user provided by the registered user themselves. The trusted identity module 312 also accesses other databases to verify the account information provided by the user. For example, the trusted identity module 312 may access a government ID database 602 to verify the accuracy of a government ID provided by the user. For example, if the trusted identity module 312 determines that a government ID provided by the user matches the name or phone number of another user listed in the government ID database 602, the trusted identity module 312 may generate an alert message indicating a potentially fraudulent identity. Upon receiving an alert message from the trusted identity module 312, a tool (e.g., 302, 304, 306, or 308) or application (e.g., 316, 318, or 320) may request additional information from the user to verify the user's identity.

[0100] In some embodiments, the trusted platform 300 may provide online banking services and maintain a database 604 of user accounts accessing the online banking services. The trusted platform 300 may provide online payment services, such as Alipay, which allows users to digitally pay for services offered on the trusted platform 300. The trusted platform 300 may maintain a database 606 of user accounts using the online payment services offered on the trusted platform 300. The trusted platform 300 may provide social media services that allow users to connect with family members, relatives, friends, colleagues, and / or fans. The trusted platform 300 may maintain a database 608 of user accounts using the social media services offered on the trusted platform 300. The trusted platform 300 may provide communication services that allow users to communicate with others, such as instant messaging or chat services. The trusted platform 300 may maintain a database 610 of user accounts using the communication services offered on the trusted platform 300. The trusted platform 300 may enter into contracts with mobile phone companies, whereby the mobile phone companies assist in verifying whether the mobile phone numbers and other account information provided by users to the trusted platform 300 during registration match the corresponding information registered with the mobile phone companies.

[0101] Trusted platform 300 can provide online shopping services that allow users to purchase products online. Trusted platform 300 can maintain a database 612 of user accounts for using the online shopping services provided on trusted platform 300. Trusted platform 300 can provide online shopping services that allow users to purchase products online. Trusted platform 300 can maintain a database 612 of user accounts for using the online shopping services provided on trusted platform 300. Trusted platform 300 can provide online entertainment services, allowing users to listen to music or watch movies by downloading or streaming music or movies. Trusted platform 300 can maintain a database 614 of user accounts for using the online entertainment services provided on trusted platform 300. Trusted platform 300 can maintain a biometric database 616, which stores biometric information provided by users during registration, such as one or more fingerprints, one or more voiceprints, or iris information.

[0102] In some embodiments, the various databases 600, 602, 604, 606, 608, 610, 612, 614, and 616 can be maintained independently of each other. For example, a user can modify information in an online banking account without modifying information in an online shopping account. Users can update information in different accounts at different times. The same user can use different usernames or aliases for different services. Multiple users can share the same account; for example, family members can share the same movie streaming account. The same user can open multiple accounts for a single service; for example, a user can have multiple mobile phone numbers, multiple email addresses, and / or multiple messaging IDs. Therefore, information based on a single database may be insufficient to accurately verify a user's identity. However, by combining information from multiple databases, user identity can be verified more reliably.

[0103] The trusted platform 300 is characterized by a trusted identity module 312 that attempts to verify a user's identity using multiple databases, thus increasing the credibility of the verified identity information provided by the trusted identity module 312. The trusted identity module 312 can access one or more of the following as part of the user identity verification process: government ID database 602, online bank account database 604, online payment account database 606, social media account database 608, mobile communication account database 610, online shopping account database 612, online entertainment account database 614, and biometric database 616. For example, if the name and email address provided by the user during registration do not match the name and email address in the online bank account database 604 and / or the online payment account database 606, the trusted identity module 312 can generate an alert message indicating a potentially fraudulent identity, and the trusted platform 300 may request additional information from the user to verify their identity.

[0104] In some embodiments, when a tool or application invokes the trusted identity module 312 to verify a user's identity, the tool or application sends the user's ID and other information to the trusted identity module 312, and the trusted identity module 312 compares the user's ID and other information provided by the tool or application with user information stored in the user account database 600 and other databases 602, 604, 606, 608, 610, 612, 614, and 616. If the user information provided by the tool or application matches the user information stored in the databases, the trusted identity module 312 verifies the user's identity. On the other hand, if the user information provided by the tool or application does not match the user information stored in one or more databases, the trusted identity module 312 generates an alarm message indicating that the user's identity cannot be verified.

[0105] In some embodiments, the trusted identity module 312 can generate a trust score along with the verified identity. For example, if a user accesses one of the tools or applications on the trusted platform 300 and the account associated with that user has been inactive for many years, the trusted identity module 312 can generate a low trust score for that user's identity because the stale data in the database may not be entirely accurate. On the other hand, if a user is very active on the trusted platform 300, uses many services provided by the trusted platform 300, and the account information associated with that user in most or all of the databases is consistent with each other, the trusted identity module 312 can generate a high trust score for the user's identity because the probability that most or all of the account information in the databases is always fraudulent is very low.

[0106] The following describes an example of using the subpoena service tool 302 to serve a notice. (See reference) Figure 7 In some embodiments, a first user 708 (who may be, for example, the plaintiff or a lawyer representing the plaintiff) accesses the trusted platform 300 using a client terminal 710, which may be, for example, a mobile phone, a personal computer, or any computing device that can connect to the network 400. In this example, the first user 708 has previously registered on the trusted platform 300. After logging into the trusted platform 300, the first user 708 can access the subpoena service tool 302.

[0107] In some embodiments, the subpoena service tool 302 may require a user to open an account and follow additional registration processes to provide additional personal information in order to verify the user's identity. For example, the user account associated with the subpoena service tool 302 may include one or more of the following information that can be used to verify the user's identity: (i) mobile phone number, (ii) credit card number, (iii) user ID associated with an online payment system, (iv) user ID associated with an online shopping account, (v) user ID associated with a music streaming or download account, (vi) user ID associated with a movie streaming or download account, (vii) user ID associated with a messaging or chat account, (viii) user ID associated with an online banking account, (ix) user ID associated with a ride-hailing service, (x) user ID associated with an online food ordering service, (xi) social security number, (xii) driver's license number, (xiii) passport number, (xiv) user ID associated with an online gaming service, (xv) ID issued by a government entity, (xvi) one or more fingerprints, (xvii) one or more voiceprints, or (xviii) iris information.

[0108] Assume that the first user 708 has previously registered in the subpoena service tool 302. During the login process, the subpoena service tool 302 can invoke the trusted identity module 312 to verify the identity of the first user 708. After the trusted identity module 312 verifies the identity of the first user 708, the subpoena service tool 302 can grant access permissions to the first user 708. The first user 708 can access the subpoena service tool 302 to serve court-issued documents (such as subpoenas or summonses) to another user 712 (the second user 712), who may be, for example, the defendant 714 or the defendant's lawyer. The client component of the subpoena service tool 302 (not shown in the figure) can be executed at the client terminal 710 and provides a user interface for interacting with the first user 708.

[0109] For example, whenever a predetermined type of event occurs in connection with the use of the subpoena service tool 302 by the first user 708, the subpoena service tool 302 invokes the trusted time module 310 to obtain an empirical timestamp regarding when the event occurred. The predetermined type of event may include, for example, receiving input from the first user 708, providing output to the first user 708, sending a document to the second user 712, confirming the second user 712's receipt of the document, and performing a pre-specified type of action or calculation. Receiving input from the first user 708 may include, for example, receiving a user ID or other personal information associated with the second user 712 who should receive a notification, and receiving uploaded files (such as a court summons or summons) from the first user 708. Providing output to the first user 708 may include, for example, displaying evidence that a document has been served on the second user 712, or displaying a message indicating that the second user 712 cannot be contacted.

[0110] As described above, the subpoena delivery tool 302 can invoke services from the trusted service layer 324. In some embodiments, whenever an event occurs, such as when user 708 (plaintiff) enters identity information through the subpoena delivery tool 302, the subpoena delivery tool 302 can invoke the trusted time module 310 to record a verified timestamp indicating the time that triggered the event. In some embodiments, the subpoena delivery tool 302 can invoke the trusted computing module 314 to generate a snapshot of the event. For example, the snapshot may include the identity of user 708 or 712, a description of the event (e.g., notification of legal proceedings sent via email), a verified timestamp indicating the time that triggered the event, and supplementary information (e.g., document format), etc. In some embodiments, the trusted computing module 314 may further generate hash values ​​corresponding to the records generated by the trusted modules 310, 312, and 314. The hash values ​​can then be recorded on the blockchain 700 so that they can be used by users of the trusted platform 300 to verify the authenticity of the records.

[0111] For example, the following events can be associated with the subpoena service activity of the first user 708.

[0112] a. Event 1: First user 708 provides the second user 712's user ID, address, and phone number to the subpoena delivery tool 302.

[0113] b. Event 2: The first user 708 uploads the document to be delivered (e.g., a subpoena or message) to the subpoena delivery tool 302.

[0114] c. Event 3: Subpoena delivery tool 302 determines all communication methods that can be used to send the document to the second user 712. For example, communication methods may include one or more email accounts, instant messaging accounts, or mobile messaging accounts for sending the document to the second user 712.

[0115] d. Event 4: Subpoena 302 sends the document to the second user 712 using all available communication methods supported by Subpoena 302.

[0116] e. Event 5: The subpoena delivery tool 302 receives confirmation that the document has been sent to the second user 712. For example, a mobile phone messaging system may indicate that the second user 712 is online and has received the document.

[0117] f. Event 6: Alternatively, the subpoena delivery tool 302 may not have received any confirmation that the second user 712 has received the document, and may have determined that the second user 712 is offline and cannot be contacted.

[0118] g. Event 7: Subpoena delivery tool 302 notifies first user 708: The document has been delivered to second user 712, or second user 712 could not be contacted.

[0119] Upon each event, the subpoena delivery tool 302 may invoke the trusted time module 310 to obtain a verified timestamp indicating the time of the event. The subpoena delivery tool 302 then invokes the trusted computing module 314 to update the blockchain 700, thereby adding a record containing information about the event. In this example, block 702a stores a record containing information about event 1, block 702b stores a record containing information about event 2, block 702c stores a record containing information about event 3, and so on. In some embodiments, multiple events may be combined and stored in a single block within the blockchain 700.

[0120] The subpoena service tool 302 is associated with one of the nodes 706 in the blockchain network 704, where blockchain 700 is replicated across blockchain network 704. For example, one of the nodes 706 may be associated with a court computer server 418 that maintains a version of blockchain 700. If user 708 notifies the court that the subpoena or summons has been served on a second user 712, court staff can access the records in blockchain 700 maintained on court computer server 418 to retrieve the aforementioned information regarding events 1 through 7. Court staff can determine that the first user 708 has served the subpoena or summons on the second user 712. Because the records in blockchain 700 have a high degree of credibility, the court accepts the information provided by the records in blockchain 700 as evidence that the notice of service has been properly served on the second user 712.

[0121] The subpoena service tool 302 is characterized by its ability to identify multiple communication methods that can be used to send documents to the second user 712. For example, when a user registers on the trusted platform 300, the trusted platform 300 may request the user to provide two or more contact methods (e.g., one or more email addresses, one or more phone numbers (e.g., home, office, and mobile phone numbers) and / or contact information for one or more messaging applications) to verify the user's identity. The subpoena service tool 302 may use the contact methods provided by the second user 712 to the trusted platform 300 during registration to serve legal notices to the second user 712. Furthermore, when the second user 712 uses one or more services provided on the trusted platform 300, the second user 712 may provide updated contact information to those services from time to time, thereby allowing the trusted platform 300 to have the second user 712's updated contact information.

[0122] In some embodiments, when the subpoena service tool 302 attempts to deliver legal notice to a second user 712, the subpoena service tool 302 may first detect whether the second user 712 is currently logged into the trusted platform 300 and using one or more services provided by the trusted platform 300, and determine the most efficient method to send the legal notice to the second user 712. For example, if the trusted platform 300 detects that the second user 712 is currently using a messaging service provided on the trusted platform 300, the subpoena service tool 302 may use the messaging service to send the court order document to the second user 712. In some embodiments, the messaging service may have a built-in read receipt function indicating that the message has been read, and may send the read receipt back to the subpoena service tool 302. In some embodiments, the subpoena service tool 302 requests the second user 712 to manually acknowledge receipt and verify identity. The second user 712 may verify identity by providing one or more identification information, and the subpoena service tool 302 invokes the trusted identity module 312 to verify the identity of the second user 712, thereby ensuring that the person receiving the court order document is indeed the intended recipient. The subpoena delivery tool 302 also invokes the trusted time module 310 to generate a timestamp that indicates the time of a read receipt from the messaging application or the time of receipt acknowledgement by the second user 712.

[0123] For the first user 708, using the subpoena service tool 302 is advantageous because tool 302 can communicate with the second user 712 using communication methods that the first user 708 may not be aware of. For example, the first user 708 may only have the second user 712's mailing address, which may or may not be up-to-date. By using the subpoena service tool 302, the first user 708 can more effectively serve notices to the second user 712 using the second user 712's most up-to-date contact information available to the trusted platform 300. In some embodiments, when a user registers with the trusted platform 300, the trusted platform 300 obtains the user's consent to use the communication methods provided by the user during registration to serve legal notices.

[0124] Another embodiment of the summons delivery tool is described below. Figure 8This is a diagram illustrating an example of system 800 according to embodiments of this document. System 800 implements subpoena service based on a blockchain network. Generally, subpoena service is a procedure in which one party to a lawsuit issues an appropriate initial notice of legal proceedings to another party (e.g., the defendant), a court, or an administrative agency with the intention of exercising jurisdiction over that party, thereby enabling that person to respond to the proceedings before a court, agency, or other tribunal. For example, system 800 may be implemented to enable the delivery of legal notices (e.g., notice 820) from a first party (e.g., user 802a operating on client terminal 804a) to a second party (e.g., user 802b operating on client terminal 804b).

[0125] As an example, system 800 includes client terminals 804a and 804b (used by users 802a and 802b respectively), a blockchain-based trusted platform 300, and a blockchain network 816. As shown, the blockchain-based trusted platform 300 includes a subpoena delivery tool 302, application programming interfaces (APIs) 810, 812, and 814, a trusted time module 310, a trusted identity module 312, and a trusted computing module 314. Note that the blockchain-based trusted platform 300 is shown as including the subpoena delivery tool 302 for illustrative purposes only. The blockchain-based trusted platform 300 may include any suitable number of tools, such as dispute resolution tools (e.g., Figure 3 Dispute resolution tools 304, legal document processing tools (e.g., legal document processing tool 306), and judgment enforcement tools (e.g., judgment enforcement tool 308), etc. In some embodiments, the trusted platform 300 is associated with one of the nodes 818 in a blockchain network 816, wherein the blockchain (e.g., blockchain 810) is replicated across the blockchain network 816.

[0126] In one example, user 802a can use client terminal 804a to send a network service request to blockchain network 816 (e.g., a request to deliver legal notice 820 to user 802b). A trusted platform 300 implemented on blockchain network node 818 in blockchain network 816 can process and fulfill the network service request (e.g., delivering notice 820 to user 802b via client terminal 804b).

[0127] Client terminals 804a and 804b may include, for example, any suitable computer, module, server, or computing element programmed to perform the methods described herein. In some embodiments, client terminals 804a and 804b may include a web browser or software application for providing various functionalities of client terminals 804a and 804b.

[0128] The trusted time module 310 can be configured to generate timestamps based on national standard time information (e.g., Greenwich Mean Time (GMT), UTC) or time information obtained from the Global Positioning System.

[0129] In some embodiments, the trusted time module 310 can be configured to generate timestamps associated with different users using different standard times for court systems in different regions. For example, the trusted time module 310 can generate timestamps associated with a first user using a first standard time recognized by a first court system associated with a first user, and generate timestamps associated with a second user using a second standard time recognized by a second court system associated with a second user, wherein the first user and the second user reside in different regions with different court systems.

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

[0131] In some embodiments, the trusted identity module 312 may be configured to verify different users residing in different areas with different court systems by using different identifiers. For example, the trusted identity module 312 may be configured to verify the identity of a first user using at least one of a first set of identifiers recognized by a first court system associated with a first user, and to verify the identity of a second user using at least one of a second set of identifiers recognized by a second court system associated with a second user, wherein the first user and the second user reside in different areas with different court systems.

[0132] In some embodiments, the Trusted Computing Module 314 may include one or more data processors having a TEE that is isolated from the operating system of the one or more data processors and configured to provide enhanced confidentiality and integrity for code executed and data loaded in the one or more data processors.

[0133] In some embodiments, the trusted computing module 314 may be configured to record information associated with a user in accordance with privacy laws. For example, the trusted computing module 314 may generate a hash value for the record and add a block including the record and the hash value to a blockchain 820 that stores records associated with user 802a.

[0134] In some embodiments, the trusted computing module 314 may be configured to provide, in response to a request for a verified record associated with delivering the notification to the intended party, a verified record of the steps / operations performed by the subpoena service tool 302. The trusted computing module 314 may also provide a verified timestamp, verified identity, and / or calculation result associated with each step / operation performed by the subpoena service tool 302.

[0135] In some embodiments, the subpoena service tool 302 may allow the serving party (e.g., the plaintiff, such as user 802a) to serve a notice (e.g., service of a subpoena or other related document, such as notice 820) to the party to be served digitally (e.g., the defendant, such as user 802b) in accordance with the legal requirement of subpoena service. In some embodiments, the subpoena service tool 302 may obtain and record verified timestamps, verified identities, and / or calculation results for each of the multiple steps performed by the subpoena service tool 302 for subpoena service. The subpoena service tool 302 may obtain verified timestamps from the trusted time module 310, verified identities from the trusted identity module 312, and calculation results from the trusted calculation module 314.

[0136] In some embodiments, the subpoena service tool 302 may include a trusted component (not shown) configured to execute and record the steps performed by the subpoena service tool 302 in a trusted execution environment, and to record the verified timestamps, verified identities, and / or calculation results associated with each step of the steps. In some embodiments, the trusted component may include a hash calculation component configured to generate a hash value representing the data of the steps performed by the subpoena service tool based on a hash algorithm.

[0137] In some embodiments, the subpoena delivery tool 302 may be configured to invoke the functions of the trusted time module 310, trusted identity module 312, or trusted computing module 314 through corresponding application programming interfaces (APIs) (e.g., APIs 810, 812, and 814) associated with the trusted time module 310, trusted identity module 312, or trusted computing module 314. In some embodiments, APIs 810, 812, and 814 may include any suitable API, such as a Representational State Transfer (REST) ​​web API (or a RESTful API) or a Simple Object Access Protocol (SOAP) based web API.

[0138] In some embodiments, the subpoena delivery tool 302 may, upon receiving a request to deliver a notification from a first party (e.g., user 802a) to a second party (e.g., user 802b), invoke the trusted identity module 312 to verify the identities of the first and second parties. The subpoena delivery tool 302 may further invoke the trusted time module 310 to verify the time the user placed the order, and invoke the trusted computing module 314 to update the blockchain 820, which includes data representing activities associated with subpoena delivery.

[0139] In some embodiments, the subpoena delivery tool 302 may be configured to invoke the trusted identity module 312 to verify that the second party is indeed the party that received the notification after delivery of the notification to the second party is completed. The subpoena delivery tool 302 may be further configured to invoke the trusted time module 310 to verify the time when the second party received the notification, and to invoke the trusted computing module 314 to update the blockchain 820, which includes data representing activities associated with the subpoena delivery.

[0140] In some embodiments, the subpoena delivery tool 302 may be configured to determine a method for delivering a notification to a second party based on one or more communication methods associated with one or more accounts of a second party registered on the system, such as by using one or more email addresses, one or more phone numbers, or one or more message delivery applications of the second party.

[0141] exist Figure 8In some embodiments, as shown in the examples, user 802a can log in to trusted platform 300, and trusted platform 300 can provide a menu of available services or display a desktop with icons representing available tools and applications. User 802a can use the menu or icons to select one of the services, such as subpoena service, and execute subpoena service tool 302 on it. User 802a can use subpoena service tool 302 to deliver documents. Trusted platform 300 can be associated with blockchain 816, and subpoena service tool 302 can invoke trusted computing module 314 to process blockchain data and record relevant data in blockchain 816. Subpoena service tool 302 can be used to deliver documents other than court order notices.

[0142] Figure 9 This is a flowchart illustrating an example of a process 900 according to an embodiment of this document. For convenience, process 900 will be described as being executed by a system of one or more computers located in one or more locations and appropriately programmed according to this document. For example, such as Figure 8 A properly programmed distributed system can perform 800 processes.

[0143] In step 902, a request is received at the blockchain-based application for delivering a notice related to legal proceedings (e.g., notice 820) from the servicer (e.g., user 802a) to the recipient (e.g., user 802b). In some embodiments, the blockchain-based application is supported by a blockchain-based platform. For example, the blockchain-based application could be a subpoena service tool 302, and the blockchain-based platform could be a blockchain-based trusted platform 300. In some embodiments, user 802a generates the request by selecting a function of the blockchain-based application for delivering legal notices. In some embodiments, the request may include the identity associated with the servicer and the identity associated with the recipient. The request may also include the recipient's contact information.

[0144] In step 904, it is determined whether the recipient is a registered user of a blockchain-based application or a blockchain-based platform. In some embodiments, the blockchain-based application may invoke a trusted identity module (e.g., trusted identity module 312) to verify the recipient's identity, thereby determining whether the recipient is a registered user of a blockchain-based application or a blockchain-based platform. In some embodiments, this determination may be based on matching the recipient's identity with the identity included in the recipient's registration information recorded on the blockchain (e.g., blockchain 810). In some embodiments, the registration information of users (e.g., users 802a and 802b) recorded on the blockchain may include the user's identity information. The identity information may include the user ID of the account associated with the user, biometric identity information (e.g., fingerprint, facial data, retinal pattern), and a digital key associated with the user, etc.

[0145] In some embodiments, registration information may include available communication methods associated with the user. Available communication methods may include at least one of the following: email, telephone call, or instant messaging. For example, user 802a's registration information may include an email address associated with user 802a, a phone number associated with user 802a, and / or an instant messaging account associated with user 802a. In some embodiments, the identity information and available communication methods in the registration information may be verified for the user during registration to determine their authenticity.

[0146] In some embodiments, a blockchain-based application may invoke a trusted computing module (e.g., trusted computing module 314) to update the blockchain, which includes data representing events or activities associated with processing 900. For example, a blockchain-based application may invoke the trusted computing module to record data of one or more computation results determined in step 904 in the blockchain.

[0147] If it is determined that the recipient is not a registered user of the blockchain application, process 900 proceeds to step 906, where a notification is sent to the recipient indicating that the recipient is not a registered user of the blockchain application. If it is determined that the recipient is a registered user of the blockchain application, process 900 proceeds to step 908.

[0148] In step 908, the time the request was received is recorded on the blockchain. In some embodiments, the blockchain application may invoke a trusted time module (e.g., trusted time module 310) to generate a timestamp associated with the request. In some embodiments, trusted time module 310 may use a standard time (e.g., UTC) recognized by the court system associated with the service of process to generate a timestamp associated with the request from the servicer (e.g., user 802a). In some embodiments, trusted time module 310 may generate a timestamp based on time information obtained from a Global Positioning System (GPS).

[0149] In some embodiments, time and a time-based digital signature may be added to the notification. In some embodiments, the digital signature may include the time of signing using the private key associated with the sender.

[0150] In step 910, it is determined whether the recipient is a registered user of the blockchain-based application. In some embodiments, the blockchain-based application may invoke a trusted identity module (e.g., trusted identity module 312) to verify the identity of the recipient, thereby determining whether the recipient is a registered user of the blockchain-based application. In some embodiments, this determination may be based on matching the identity of the recipient with the identity included in the recipient's registration information recorded on the blockchain (e.g., blockchain 810). If it is determined that the recipient is not a registered user of the blockchain-based application, process 900 proceeds to step 912, where a notification is sent to the sender indicating that the recipient is not a registered user of the blockchain-based application. If it is determined that the recipient is a registered user of the blockchain-based application, process 900 proceeds to step 914.

[0151] In 914, if the recipient is determined to be a registered user of a blockchain-based application, one or more methods of delivering the notification are identified. In some embodiments, this identification may be based on one or more available communication methods contained in the recipient's registration information. For example, a blockchain-based application may determine that the recipient's available communication methods include email, telephone calls, and / or instant messaging, and identify the email address, phone number, and instant messaging account associated with the recipient.

[0152] At step 916, after delivering the notification to the recipient, it is determined whether the recipient is logged into an account registered in the blockchain-based application. If it is determined that the recipient is not logged into the account, process 900 proceeds to step 918, where a notification is sent to the sender to inform that the recipient is offline. In some embodiments, the notification may be sent to an account associated with the sender to inform that the recipient is offline. In some embodiments, if it is determined that the recipient is not logged into the account, the blockchain-based application may attempt to deliver the notification to the recipient at another time. If it is determined that the recipient is logged into the account, process 900 proceeds to step 920.

[0153] In step 920, the notification is delivered to the recipient. In some embodiments, if the recipient logs into an account on a blockchain-based application or a blockchain-based platform using a service with built-in communication methods, the application attempts to deliver the notification to the recipient using the built-in communication methods. For example, if at 918 the application determines that the recipient has logged into an instant messaging account provided by the platform, the application may deliver the notification to the recipient's instant messaging account. In some embodiments, the notification may be delivered to the recipient based on at least one of one or more notification delivery methods determined in step 914. In some embodiments, the notification may be delivered to the recipient simultaneously or in parallel using the communication methods identified in step 914. For example, the notification may be delivered to the recipient by simultaneously sending the notification to the recipient's email address, calling the recipient's phone number, and sending an instant message to the recipient's instant messaging account.

[0154] In some embodiments, the notification can be delivered to the recipient by invoking a smart contract (not shown) executed on a blockchain node (e.g., blockchain node 818) where the blockchain application resides. The smart contract may include defined functions or operations to retrieve, generate, store, or otherwise manipulate or manage blockchain data. In some embodiments, the smart contract may execute automatically when certain predetermined execution conditions are met. For example, when one or more methods of delivering the notification are identified in step 914, the smart contract may self-execute using available communication methods and deliver the notification to the recipient.

[0155] In step 922, an acknowledgment of acceptance of the notification is received from the recipient. For example, if the notification is delivered to the recipient's instant messaging account, the instant messaging program can generate a read receipt when the recipient reads the message containing the notification. In some embodiments, the notification requests the recipient to manually acknowledge receipt by, for example, clicking a button in the message indicating that the notification has been received or sending a reply message confirming receipt.

[0156] In step 924, after receiving confirmation of acceptance of the notification from the recipient, a notification is sent to the sender to inform them that the notification has been delivered. In some embodiments, the notification may be sent to an account associated with the sender to inform them that the notification has been delivered. In some embodiments, the confirmation may be delivered to the sender based on available communication methods contained in the sender's registration information.

[0157] In some embodiments, the time of receipt of the confirmation can be recorded on a blockchain. For example, a blockchain-based application can invoke the trusted time module 310 to verify the time of receipt of the confirmation and record the time of receipt of the confirmation based on the verification.

[0158] In some embodiments, a blockchain-based application may invoke the trusted identity module 312 to verify that the recipient is indeed the party that actually received the notification. For example, the blockchain-based application may verify the identity information or digital signature included in the confirmation to determine whether the confirmation was received from the recipient.

[0159] In some embodiments, a blockchain-based application may invoke a trusted computing module to update the blockchain, which includes data representing the data associated with processing 900. For example, a blockchain-based application may invoke trusted computing module 314 to record the computation results of any of steps 902-924 in the blockchain.

[0160] The following describes an example where a user fills out an electronic form using legal document processing tool 306. In this example, each step of filling out the form is recorded on the blockchain and is verifiable. A unique ID is generated at each step and embedded in the digital content of the form. The unique ID can be used to retrieve the record for each step.

[0161] Examples of legal document processing tools enable users and service providers to complete electronic forms, such as legal documents required as part of the process of providing services to users. One problem with traditional technologies is that the digital content of electronic forms is easily tampered with. It is also difficult to verify identity and time when filling out digital forms. Therefore, some legal document processing requires users and / or service providers to fill out one or more paper forms, which typically requires the user and / or service provider to meet and complete the forms together. Completing paper forms offline makes the service inefficient and makes it difficult to preserve the paper forms.

[0162] The techniques described herein produce several technical effects. In some embodiments, the system records each step of filling out a form for the service, such as the form filled out by the user at each step, the time at each step, and the numerical content of the form at each step. This recording enables verification of each step in filling out the form, thereby preventing users from tampering with the form's content, forging the form, or providing deceptive information when filling it out. The data integrity and security of the forms required for the service can be enhanced. With enhanced data integrity and security, the form can replace the paper forms previously required to complete the service using existing technologies.

[0163] In some embodiments, a unique ID is generated at each step and embedded in the digital content of the spreadsheet. This unique ID can be extracted from the spreadsheet to retrieve the spreadsheet's time and digital content from the blockchain at each step. Therefore, the status of the spreadsheet at each step can be queried and verified, further enhancing the authenticity of the spreadsheet.

[0164] Figure 10 This is a diagram illustrating an example of a system 1000 for providing legal document processing according to embodiments of this document. System 1000 implements a legal document processing procedure based on a blockchain network. Typically, a legal document processing procedure is a process by which a user and / or service provider completes one or more electronic forms of legal documents corresponding to the services provided by the service provider.

[0165] As an example, system 1000 includes client terminals 1004a and 1004b (used by user 1002 and service provider 1004, respectively), a blockchain-based trusted platform 300, and a blockchain network 1016. As shown in the figure, the blockchain-based trusted platform 300 includes a legal document processing tool 306, APIs 810, 812, and 814, a trusted time module 310, a trusted identity module 312, and a trusted computing module 314. Note that the blockchain-based trusted platform 300 is shown as including the legal document processing tool 306 for illustrative purposes only. The blockchain-based trusted platform 300 may include any suitable number of tools, such as subpoena service tools (e.g., Figure 3 Subpoena service instrument 302), dispute resolution instrument (e.g., Figure 3 Dispute resolution tools (302) and judgment enforcement tools (e.g., judgment enforcement tool 308), etc. In some embodiments, the trusted platform 300 is associated with one of the nodes 1014 in a blockchain network 1016, wherein the blockchain (e.g., blockchain 1010) is replicated across the blockchain network 1016.

[0166] In one example, user 1002 can use client terminal 1004a to send a service request (e.g., a request to fill in legal documents for a service) to blockchain network 1016. A trusted platform 300 implemented on blockchain network node 1014 in blockchain network 1016 can process and fulfill the service request (e.g., a request to fill in legal documents for a service).

[0167] In some embodiments, the legal document processing tool 306 may be configured to employ the SM2 algorithm, an elliptic curve-based public-key cryptography algorithm, to encrypt data communications and verify identity. In some embodiments, access levels can be specified for the content recorded by the legal document processing tool 306. Certain recorded content can only be accessed by personnel with specified access levels.

[0168] Client terminals 1004a and 1004b may include, for example, any suitable computer, module, server, or computing element that performs the methods described herein. In some embodiments, client terminals 1004a and 1004b may include web browsers and software applications for providing various functionalities of client terminals 1004a and 1004b.

[0169] The trusted time module 310 can be configured to obtain time from time sources such as the National Time Service Center (NTSC), UTC, GPST, GLONASS Time (GLONASST), Galileo System Time (GST), or BeiDou Time (BDT). In some embodiments, the blockchain network can obtain time from a single source, enabling all blockchain nodes in the blockchain network to be synchronized to the same time.

[0170] In some embodiments, the trusted time module can be configured to generate timestamps based on (i) national standard time information and / or (ii) time information obtained from the Global Positioning System.

[0171] In some embodiments, the trusted time module 310 can be configured to generate timestamps associated with different users using different standard times for court systems in different regions. For example, the trusted time module 310 can generate timestamps associated with a first user using a first standard time recognized by a first court system associated with a first user, and generate timestamps associated with a second user using a second standard time recognized by a second court system associated with a second user, wherein the first user and the second user reside in different regions with different court systems.

[0172] The trusted identity module 312 can be configured to verify the identity of a user (e.g., user 1002) or a service provider (e.g., service provider 1004) based on one or more identifiers associated with the user or service provider. In some embodiments, the identifier may include at least one of the following: (i) a mobile phone number, (ii) a credit card number, (iii) a user ID associated with an online payment system, (iv) a user ID associated with an online shopping account, (v) a user ID associated with a music streaming or download account, (vi) a user ID associated with a movie streaming or download account, (vii) a user ID associated with a messaging or chat account, (viii) a user ID associated with an online banking account, (ix) a user ID associated with a ride-hailing service, (x) a user ID associated with an online food ordering service, (xi) a social security number, (xii) a driver's license number, (xiii) a passport number, (xiv) a user ID associated with an online gaming service, or (xv) an ID issued by a government entity.

[0173] In some embodiments, the trusted identity module 312 may be configured to verify different users residing in different areas with different court systems by using different identifiers. For example, the trusted identity module 312 may be configured to verify the identity of a first user using at least one of a first set of identifiers recognized by a first court system associated with a first user, and to verify the identity of a second user using at least one of a second set of identifiers recognized by a second court system associated with a second user, wherein the first user and the second user reside in different areas with different court systems.

[0174] In some embodiments, the Trusted Computing Module 314 may include one or more data processors having a TEE that is isolated from the operating system of the one or more data processors and configured to provide enhanced confidentiality and integrity for code executed and data loaded in the one or more data processors.

[0175] In some embodiments, the trusted computing module 314 may be configured to record information associated with a user in accordance with privacy laws. For example, the trusted computing module 314 may generate a hash value of the record and add a block including the record and the hash value to the blockchain 1010 that stores records associated with user 1002.

[0176] In some embodiments, the legal document processing tool 306 may be configured to perform multiple steps to process information for performing services, and for each of at least some of the multiple steps, the legal document processing tool 306 may be configured to invoke a trusted computing module to process blockchain data, thereby updating the blockchain to record information including a verified timestamp generated by a trusted time module and / or a verified identity determined by a trusted identity module, wherein the verified timestamp represents the time of an event in the information processing for performing services, and the verified identity represents the identity of a user.

[0177] In some embodiments, the trusted computing module 314 may be configured to provide, in response to a request for verification records associated with legal document processing, verification records of steps / operations performed by the legal document processing tool 306. The trusted computing module 314 may also provide verification timestamps, verified identities, and / or calculation results associated with each step / operation performed by the legal document processing tool 306.

[0178] In some embodiments, the legal document processing tool 306 may allow a user to complete electronic legal documents according to the legal requirements of the legal document processing procedure. In some embodiments, the legal document processing tool 306 may obtain and record verified timestamps, verified identities, and / or calculation results for each of the multiple steps performed by the legal document processing tool 306 for the legal document processing procedure. The legal document processing tool 306 may obtain verified timestamps from the trusted time module 310, verified identities from the trusted identity module 312, and calculation results from the trusted calculation module 314.

[0179] In some embodiments, the legal document processing tool 306 may include a trusted component (not shown) configured to execute in a trusted execution environment and to record the steps performed by the legal document processing tool 306 and the verified timestamps, verified identities, and / or calculation results associated with each step. In some embodiments, the trusted component may include a hash calculation component configured to generate hash values ​​representing the data of the steps performed by the legal document processing tool based on a hash algorithm.

[0180] In some embodiments, the legal document processing tool 306 may be configured to invoke the functions of the trusted time module 310, trusted identity module 312, or trusted computing module 314 via corresponding APIs (e.g., APIs 810, 812, and 814) associated with the trusted time module 310, trusted identity module 312, or trusted computing module 314. In some embodiments, APIs 810, 812, and 814 may include any suitable API, such as a REST web API (or RESTful API) or a SOAP-based web API.

[0181] In some embodiments, the legal document processing tool 306 may invoke the trusted identity module 312 to verify the identity of a user (e.g., user 1002) upon receiving a request for service from an account of a user associated with a blockchain-based application. The legal document processing tool 306 may further identify one or more forms completed and submitted in the multiple steps of providing the service.

[0182] In some embodiments, at each of the multiple steps, the legal document processing tool 306 may invoke the trusted time module 310 to generate the time of execution of that step, and generate a unique identifier (ID) based on the time of execution and the digital content on the spreadsheet at that time. The legal document processing tool 306 may further invoke the trusted computing module to record the unique ID, time, and digital content on the blockchain. The legal document processing tool 306 can then embed the unique ID into the digital content at that time by changing one or more attributes associated with the digital content, thereby producing digital content that allows retrieval of the embedded information of the time and digital content from the blockchain based on the unique ID. The legal document processing tool 306 may further invoke the trusted computing module to record the embedded information of the digital content on the blockchain.

[0183] Figure 11 This is a flowchart illustrating an example of a process 1100 that can be performed according to embodiments of this document. Process 1100 can be performed by one or more blockchain nodes or a computing device communicatively coupled to one or more blockchain nodes. For clarity, the following description, in conjunction with other accompanying drawings, generally describes process 1100. However, it should be understood that process 1100 can be suitably performed, for example, by any system, environment, software, and hardware, or a combination of systems, environments, software, and hardware. In some embodiments, the various steps of process 1100 can be run in parallel, combined, cyclically, or in any order.

[0184] At 1102, a request for a service is received. This service can be a public service provided by a government agency or a business service provided by a business service provider. For example, the service could be a driver's license renewal service, tax registration service, marriage registration service, bank account opening service, residence permit service, apartment rental service, etc. In some embodiments, a user can initiate a service request through their user account on the legal document processing tool 306 or through another blockchain-based application access trusted platform 300 that hosts the legal document processing tool 306. For example, a user can open the legal document processing tool 306 on their client terminal and log in to their account. Available services can then be displayed on the user's client terminal, and the user can initiate a request by selecting the desired service.

[0185] In some embodiments, a second request for processing a user's service request can be initiated from the account of the service provider associated with the legal document processing tool 306. The second request for processing the user's request may include examining the user's paperwork, making a decision on the user's paperwork, endorsing the user's signature, sending a request for supplementary documents after examining the user's paperwork, etc.

[0186] At 1104, verify identity. The identity can be that of a user or a representative of a service provider. In some embodiments, the identity can be included in the request for the service.

[0187] In some embodiments, the legal document processing tool 306 invokes the trusted identity module 312 to verify the identity of a user or service provider representative. In some embodiments, the user or representative may register using biometric information. When a user or representative accesses the legal document processing tool 306, they may be required to verify their identity using fingerprint, voice, iris, or facial recognition. After the corresponding biometric information is input via a sensor, the trusted identity module 312 can match the biometric information with registration information stored in memory to verify whether the user or representative is authorized to use the legal document processing tool 306.

[0188] In 1106, one or more electronic forms are identified as to be filled out and submitted to provide the service. These electronic forms can be digital documents required by the service provider to provide the service. For example, an electronic form can be an application form, a service agreement, a membership renewal form, a lease agreement, a purchase order, etc. An electronic form may include one or more online pages.

[0189] At 1108, it is determined whether there are additional steps to be performed on the spreadsheet. In some embodiments, filling out a spreadsheet may include multiple steps. For example, filling out a lease agreement may include signing each page of the lease agreement. Signing each signature or initial may be a separate step in filling out the agreement. These steps may be performed by the user and / or the service provider. For example, a user may sign a page of the spreadsheet in one step, while in another step, the service provider may sign on the same page to endorse the user's signature. In some embodiments, both the user and the service provider may access the legal document processing tool 306 to interactively perform steps; for example, one party may remain logged in to wait for the other party to complete his / her signature before the other party can endorse or countersign. In some embodiments, the user and the service provider may log in separately to perform steps of their own information document processing procedures. If there are additional steps to be performed, process 1100 proceeds to 1110. Otherwise, process 1100 proceeds to 1116.

[0190] At step 1110, a unique ID is generated based on the time of the execution step and the digital content on the spreadsheet at that time. This unique ID can be used to uniquely identify the user. In some embodiments, the unique ID may include the user's identity information digitally signed using the user's private key. The user can then be identified by decrypting the digital signature using the public key corresponding to the user, and verified by comparing the decrypted information with the user's trusted identity recorded in the blockchain. In some embodiments, the unique ID may be generated based on the time and the digital content the user fills in on the spreadsheet at that time. In some embodiments, the unique ID may be generated based on the time and the spreadsheet.

[0191] In some embodiments, the unique ID may be embedded in the digital content entered by the user. In some embodiments, a second unique ID may be generated based on the time of performing the second step and the digital content entered by the service provider on the spreadsheet at that time. This second unique ID may be embedded in the digital content entered by the service provider.

[0192] In some embodiments, the timing of the execution step and at least a portion of the numerical content on the spreadsheet at that time can be used to generate a unique ID, for example, by generating a hash value based on the portion of the content. In some embodiments, the content used to generate the unique ID also includes the identity of the user or service provider.

[0193] In some embodiments, the unique ID can be encrypted or hashed to enhance robustness and security. For example, encryption can be performed using a user's or service provider's public key based on public-key cryptography. In some embodiments, encryption can also be performed based on an encryption scheme such as Arnold scrambling encryption, to suit the embedding technology used. By performing encryption, if an attacker does not know the encryption scheme or encryption key, even if the attacker extracts the digital watermark, they cannot decrypt the associated unique ID.

[0194] At 1112, a unique ID, time, and digital content are recorded on the blockchain. In some embodiments, the unique ID, time, and digital content can be recorded on the blockchain as key-value pairs, where the key is the unique ID and the value includes the time and digital content. The unique ID can then be used to retrieve the value including the time and digital content. In some embodiments, the blockchain network may employ a content-addressed tree structure such as a Merkel-Patricia tree or a fixed-depth Merkel tree. In some embodiments, each blockchain node in a blockchain network associated with a trusted platform may store a portion of block data or state data. For example, a blockchain node may be a light node that stores only the unique ID and time, without storing the digital content, compared to a full node that stores the unique ID, time, and digital content. In some embodiments, the blockchain network may include one or more shared storage nodes that store historical state data, while other regular blockchain nodes only store current state data to save storage space.

[0195] In step 1114, a unique ID is embedded in the digital content. In some embodiments, each step corresponds to a page of a spreadsheet. A unique ID can be embedded in each page of the spreadsheet. In some embodiments, the unique ID can be represented by changing one or more attributes associated with the digital content, wherein the embedding produces digital content capable of retrieving embedded information of the time and digital content from the blockchain based on the unique ID. In some embodiments, the unique ID can be embedded invisiblely. If such an addition is not obvious or visible to the naked eye, the embedded unique ID can be considered invisible. In other words, if the visual difference between the digital content before and after embedding the unique ID is not obvious to the naked eye, the unique ID can be considered invisible. The unique ID can be embedded in the digital content, the foreground of the digital content, or the background of the digital content. The foreground of the digital content can be a film or screen attached to or integrated into the platform displaying the digital content. The foreground of the digital content can also be a layer containing the unique ID, which is configured not to be presented by the viewing application. The background of the digital content can be the background of the electronic document containing the digital content presented on the display.

[0196] Invisible embedding of digital content can be performed based on digital watermarking. Digital watermarking is a technique that embeds a unique ID into a data carrier. The data carrier can include text, images, or electronic media. The unique ID can be embedded in the data carrier as an invisible digital watermark. When querying digital content, the unique ID can be extracted from the data carrier to retrieve the digital content corresponding to that unique ID.

[0197] Digital watermarking techniques can include background brightness masking, illumination masking, texture masking, spatial masking, and frequency masking. Different techniques can be based on different digital watermarking algorithms. In some embodiments, digital watermark embedding can be based on human visual system (HVS) characteristics to achieve visual imperceptibility or invisibility. For example, the human eye is more sensitive to changes in low-intensity pixels than changes in high-intensity pixels. In illumination masking, pixels in digital content can be scanned to identify pixels with high intensity levels. High-intensity pixels can be used to embed digital watermarks. Modifications to high-intensity pixels are difficult for the human eye to detect, making the digital watermark virtually invisible. Using illumination masking, digital watermarks can be embedded in the entire digital content or a portion of it. For example, if the digital content is text content, the digital watermark can be embedded in words, phrases, sentences, or even the entire text content.

[0198] As another example, in texture masking, the more complex the texture, the harder it is for the human eye to discern the variations. Therefore, digital watermarks can be embedded in a portion of a digital image or the background of digital content with more complex textures, making them less noticeable to the human eye.

[0199] As another example, digital watermarking can be performed by converting digital content into frequency domain coefficients based on mathematical transformations such as Discrete Cosine Transform (DCT), Discrete Wavelet Transform (DWT), or Arnold Transform, using frequency masking. In frequency masking, mid-frequency or low-frequency coefficients are typically modified according to the watermark information. These frequency ranges have minimal impact on the presentation of the original content. The digital watermark (i.e., a unique ID) can be in the form of a string. The string can be converted into a single binary string. Each bit can be embedded to adjust the low-frequency coefficients according to the transformation technique used. In frequency masking, the digital watermark can be distributed throughout the digital content, which can increase robustness and invisibility. Other exemplary mathematical transformations for performing digital watermarking can include DWT and Singular Value Decomposition (DWT-SVD), Least Significant Bit (LSB), or Highly Undetectable Steganography (HUGO).

[0200] In some embodiments, multiple layers of digital watermarking can be embedded into a data carrier using one or more digital watermarking processing techniques. In this case, an index of the digital watermark layers can also be generated and embedded into the data carrier. This index can be used to more easily extract the digital watermark from the data carrier. In some embodiments, the unique ID can be randomized or mixed with a random signal before embedding into the data carrier.

[0201] In some examples, the digital content can be text content. If the embedded unique ID does not substantially change the content, it can be considered invisible. If the embedded information does not change the meaning of the text, the content can be considered not substantially changed. For example, the original text is "he becomes a monster after seven years," and the embedded information is "he has become a 'monster' after seven years." Because the meaning of the text remains unchanged, the embedded information in the added text is not considered a substantial change to the original text. In this example, according to the techniques described herein, the unique ID can be embedded in quotation marks or the auxiliary verb "has." In some embodiments, the unique ID can be embedded in spaces or function words such as articles, prepositions, conjunctions, and auxiliary verbs, which generally do not change the substantial meaning of the text content.

[0202] In some embodiments, multiple unique IDs can be used to track updates to text content. For example, one or more unique IDs can be generated based on timestamps recorded on the blockchain corresponding to one or more updates to digital content. When content updates are performed and recorded on the blockchain, a unique ID, including the corresponding timestamp, can be embedded in at least a portion of the updated content. The timestamps in the unique IDs extracted from the digital content can form a timeline of the creation and update history of the digital content. This timeline can be used as evidence of the content development process and compared with the update history recorded on the blockchain to authenticate the authorship of the text content.

[0203] In some embodiments, a unique ID can be embedded in feature information of text or image content. Exemplary feature information may include the color, brightness, and transparency of the text or image. For example, the colors of the text or image can be encoded based on the Red-Green-Blue (RGB) color model. A unique ID can be embedded to slightly alter the combination of RGB values, a change imperceptible to the naked eye. As another example, a unique ID can be embedded in text or images in the format YCbCr, where Y represents the brightness signal, Cb represents the chromaticity blue signal, and Cr represents the chromaticity red signal. The brightness signal is relatively insensitive to information embedding and can be preferably used to embed a unique ID imperceptibly.

[0204] In some embodiments, a unique ID can be embedded in the punctuation marks of the text content. For example, in the text “after seven years, he becomes a ‘monster’,”, the unique ID can be embedded in the encoding of commas and quotation marks.

[0205] In some embodiments, a unique ID can be embedded in the font used by the text content. The font can be encoded using, for example, Unicode (UTF-8). UTF-8 is based on variable-width character encoding and uses one to four 8-bit bytes. Embedding a unique ID in certain bits may slightly alter the pixel position, size, angle, font shape, or punctuation, changes that are not visible to the naked eye. For example, redundancy can be used to encode pixels for text fonts and punctuation. Redundancy is typically added to pixels for error checking in data communication. Redundancy, such as a check bit, can be used to check the integrity of data at the receiving end. If the check bit arrives at the receiver inconsistent with the rest of the information in the carrying pixel, the receiver can request the sender to retransmit the content. The unique ID can be embedded randomly in redundant pixels or in redundant pixels at fixed locations. It should be understood that a unique ID can also be embedded imperceptibly in other hidden features of the font or punctuation.

[0206] In some embodiments, a unique ID may be embedded in or contained within digital content, or in a form or table containing digital content. These embodiments are particularly suitable for the authentication of rights to text or images inserted in online forms or tables. For example, an online form may be a form defined in the Hypertext Markup Language (HTML) definition of a webpage (e.g., using "..."). <form>The webpage is rendered by the browser program that displays it. Similarly, an online form can be a table defined in the Hypertext Markup Language (HTML) definition of a webpage (e.g., using a `<form>` tag) and rendered by the browser program that displays the webpage.

[0207]

[0208]

[0209] Figure 12

[0210] Figure 3

[0211]

[0212]

[0213]

[0214]

[0215]

[0216]

[0217]

[0218]

[0219]

[0220] Figure 13 Figure 12

[0221]

[0222]

[0223]

[0224]

[0225]

[0226]

[0227]

[0228]

[0229]

[0230]

[0231]

[0232]

[0233]

[0234]

[0235]

[0236]

[0237]

[0238]

[0239] Figure 14

[0240] Figure 3

[0241]

[0242]

[0243]

[0244]

[0245]

[0246]

[0247]

[0248]

[0249]

[0250]

[0251]

[0252]

[0253]

[0254]

[0255]

[0256]

[0257]

[0258]

[0259]

[0260]

[0261]

[0262] Figure 15

[0263]

[0264]

[0265]

[0266]

[0267]

[0268]

[0269]

[0270]

[0271]

[0272]

[0273]

[0274]

[0275]

[0276]

[0277]

[0278]

[0279]

[0280]

[0281]

[0282]

[0283]

[0284]

[0285]

[0286]

[0287]

[0288]

[0289]

[0290]

[0291]

[0292]

[0293]

[0294]

[0295]

[0296]

[0297]

[0298]

[0299]

[0300]

[0301]

[0302]

[0303]

[0304]

[0305]

[0306]

[0307]

[0308]

[0309]

[0310]

[0311]

[0312]

[0313]

[0314]

[0315]

[0316]

[0317] Figure 16

[0318]

[0319]

[0320]

[0321]

[0322]

[0323]

[0324]

[0325]

[0326]

[0327]

[0328]

[0329]

[0330] Figure 17

[0331]

[0332]

[0333]

[0334]

[0335]

[0336]

[0337]

[0338]

[0339]

[0340]

[0341]

[0342]

[0343]

[0344]

[0345]

[0346]

[0347]

[0348]

[0349]

[0350]

[0351] Figure 18

[0352]

[0353]

[0354]

[0355]

[0356]

[0357]

[0358] Figure 18

[0359]

[0360]

[0361]

[0362]

[0363]

[0364]

[0365]

[0366]

[0367] Figure 19

[0368]

[0369]

[0370]

[0371]

[0372]

[0373] Figure 19

[0374]

[0375]

[0376]

[0377]

[0378]

[0379]

[0380]

[0381] Figure 20

[0382]

[0383]

[0384]

[0385]

[0386]

[0387]

[0388]

[0389]

[0390]

[0391] Figure 20

[0392]

[0393]

[0394]

[0395]

[0396]

[0397]

[0398]

[0399]

[0400]

[0401]

[0402]

[0403] Figure 21

[0404]

[0405]

[0406]

[0407]

[0408] Figure 21

[0409]

[0410]

[0411]

[0412]

[0413]

[0414]

[0415]

[0416]

[0417]

[0418]

[0419]

[0420]

[0421]

[0422]

[0423]

[0424]

[0425]

[0426]

[0427]

[0428]

[0429]

[0430]

[0431] The unique ID (label) is displayed by the browser program that shows the webpage. It can be invisiblely embedded in values ​​associated with color, shadow, cell size, or other attributes of a form or table. In some cases, the unique ID can be embedded in electronic media that can be used to display or publish digital content. For example, a unique ID can be embedded in a webpage or in media such as Microsoft Word, PowerPoint, or Adobe. The background texture of the PDF electronic document. At 1116, the digital content of the embedded information is recorded to the blockchain. In some embodiments, a correlation can be established between a unique ID and the digital content of the embedded information, and the digital content of the embedded information can be retrieved from the blockchain based on a query for the unique ID. A figure is shown illustrating an example of a system 1200 for providing dispute resolution according to embodiments herein. System 1200 implements a dispute resolution based on a blockchain network. Generally, system 1200 allows two or more disputing parties to conveniently find one or more potential solutions from multiple dispute resolution providers (e.g., dispute mediators). As an example, system 1200 includes client terminals 1204a and 1204b (used by users 1202a and 1202b, respectively), a blockchain-based trusted platform 300, and a blockchain network 1216. System 1200 communicates with several dispute resolution providers 1206a-1206m. As shown, the blockchain-based trusted platform 300 includes a dispute resolution tool 304, an API... 810, 812, and 814, trusted time module 310, trusted identity module 312, and trusted computing module 314. Note that the blockchain-based trusted platform 300 is shown as including dispute resolution tool 304, for illustrative purposes only. The blockchain-based trusted platform 300 may include any suitable number of tools, such as subpoena service tools (e.g., subpoena service tool 302), legal document processing tools (e.g., legal document processing tool 306), and judgment enforcement tools (e.g., judgment enforcement tool 308), etc. In some embodiments, the trusted platform 300 is associated with one of the nodes 1214 in a blockchain network 1216, wherein the blockchain (e.g., ...) Blockchain 1210 is replicated across blockchain network 1216. In one example, user 1202a can use client terminal 1204a to send a network service request (e.g., a request to resolve a legal dispute) to blockchain network 1216. A trusted platform 300 associated with blockchain network node 1214 in blockchain network 1216 can process and fulfill the network service request (e.g., providing a dispute resolution to user 1202a via client terminal 1204b). As another example, users 1202a and 1202b can jointly submit a legal dispute involving users 1202a and 1202b to trusted platform 300.Trusted platform 300 can invite multiple dispute resolution providers 1206a-1206m to provide dispute resolutions and identify one or more dispute resolutions agreed upon by users 1202a and 1202b. Client terminals 1204a and 1204b can include, for example, any suitable computer, module, server, or computing element programmed to perform the methods described herein. In some embodiments, client terminals 1204a and 1204b can include web browsers and software applications for providing various functionalities of client terminals 1204a and 1204b. In some embodiments, dispute resolution tool 304 can provide one or more potential solutions for disputes between at least a first party (e.g., user 1202a) and a second party (e.g., user 1202b). In some embodiments, dispute resolution tool 304 can invoke a trusted identity module (e.g., trusted identity module 312) to verify the identity of the first party, the identity of the second party, and the identities of multiple dispute resolution providers (e.g., dispute resolution providers 1206a-1206m). Dispute resolution tool 304 can further send dispute-related information to multiple dispute resolution providers. In some embodiments, the dispute resolution tool 304 may receive potential solutions to the dispute from multiple dispute solution providers 1206a-1206m and send the potential solutions to a first party and a second party. In some embodiments, the dispute resolution tool 304 may receive responses from the first party and the second party and determine, based on the responses, whether the parties accept at least one solution. For example, the dispute resolution tool 304 may receive a first set of potential dispute solutions from the first party and a second set of potential dispute solutions from the second party. The dispute resolution tool 304 may determine whether there is at least one common dispute solution between the first and second sets. If it is determined that there is no common dispute solution, the dispute resolution tool 304 may determine that no potential solution is acceptable to both the first party and the second party. In some embodiments, the dispute resolution tool 304 may update a blockchain (e.g., blockchain 1210) to record data associated with the services provided by the dispute resolution tool 304. For example, the dispute resolution tool 304 may update blockchain 1210 to record data representing the dispute between parties 1202a and 1202b and data on potential solutions provided by dispute solution providers 1206a-1206m. Dispute resolution tool 304 can update blockchain 1210 to record data representing the identities of the disputing parties 1202a and 1202b, as well as the identities of the dispute resolution providers 1206a-1206m.In some embodiments, the dispute resolution tool 304 may update the blockchain 1210 to record data representing a first timestamp and data representing a second timestamp, wherein the first timestamp indicates when information about the dispute was sent to dispute resolution providers 1206a-1206m, and the second timestamp indicates when each dispute service provider 1206a-1206m provided a potential dispute resolution. In some embodiments, the dispute resolution tool 304 may update the blockchain 1210 to record data representing a first timestamp, data representing a second timestamp, data representing a third timestamp, and data representing a fourth timestamp; wherein the first timestamp indicates when a potential dispute resolution was sent to a first party 1202a, the second timestamp indicates when a potential dispute resolution was sent to a second party 1202b, the third timestamp indicates when the first party 1202a provided a response to the potential dispute resolution, and the fourth timestamp indicates when the second party 1202b provided a response to the potential dispute resolution. In some embodiments, dispute resolution tool 304 may receive a first response from first party 1202a indicating that first party 1202a can accept at least a first set of potential dispute solutions, and a second response from second party 1202b indicating that second party 1202b can accept at least a second set of potential dispute solutions. Dispute resolution tool 304 may determine, based on the first and second responses, whether at least one common dispute solution exists. For example, dispute resolution tool 304 may determine at least one final potential solution based on one or more potential solutions acceptable to both first party 1202a and second party 1202b. In some embodiments, dispute resolution tool 304 may provide assets to at least one of the dispute solution providers 1206a-1206m that facilitated at least one final potential solution acceptable to both first party 1202a and second party 1202b. In some embodiments, dispute resolution tool 304 may be configured to invoke the functions of trusted time module 310, trusted identity module 312, or trusted computing module 314 via corresponding APIs (e.g., APIs 810, 812, and 814) associated with trusted time module 310, trusted identity module 312, or trusted computing module 314. In some embodiments, APIs 810, 812, and 814 may include any suitable API, such as a REST web API (or RESTful API) or a SOAP-based web API. A flowchart illustrating an example of a process 1300 for implementing dispute resolution, which may be executed according to embodiments herein. For convenience, process 1300 will be described as being executed by a system of one or more computers located in one or more locations and appropriately programmed according to this document. For example, a distributed system such as system 1200, appropriately programmed, may execute process 1300.At 1302, a request for resolving a dispute between at least a first party (e.g., user 1202a) and a second party (e.g., user 1202b) is received at a blockchain-based application (e.g., dispute resolution tool 304). In some embodiments, the request for resolving the dispute may include virtual assets. In some embodiments, virtual assets are representations of digital assets, which may be defined as a medium of exchange or property with value in a specific environment such as a financial trading environment. In some embodiments, virtual assets may be offered to dispute resolution providers (e.g., dispute resolution providers 1206a-1206m) as a reward to incentivize them to research the dispute and propose informed dispute resolution solutions. In some embodiments, the blockchain-based application may receive a first request from the first party for resolving the dispute. The first request may include a first virtual asset with a first value. The blockchain-based application may receive a second request from the second party for resolving the dispute. The second request may include a second virtual asset with a second value. In some embodiments, the blockchain-based application may determine the virtual asset based on the virtual asset with the higher value of the first and second virtual assets. For example, if the value of the first virtual asset is higher than the value of the second virtual asset, the first virtual asset may be determined as the virtual asset. In some embodiments, the blockchain-based application may store the virtual asset as a deposit. In some embodiments, the blockchain-based application can remove virtual assets from a first account associated with a first party and from a second account associated with a second party, and store the removed virtual assets on the blockchain. Continuing the example above, if the value of the first virtual asset is higher than the value of the second virtual asset, the first virtual asset can be identified as the final virtual asset, and can be withdrawn from the first account associated with the first party. It can also be withdrawn from the second account associated with the second party. The blockchain-based application can store both first virtual assets as the final virtual asset to reward the dispute resolution provider. In step 1304, it is determined whether the first party and the second party are registered users of the blockchain-based application. In some embodiments, this is determined by matching the first identity with the identity contained in the first party's registration information recorded on the blockchain, and matching the second identity with the identity contained in the second party's registration information recorded on the blockchain. In some embodiments, the blockchain-based application can invoke a trusted identity module (e.g., trusted identity module 312) to verify the identities of the first party and the second party. Based on blockchain applications, a trusted identity module can be further invoked to verify the identities of multiple dispute resolution providers (e.g., dispute resolution providers 1206a-1206m).In some embodiments, the blockchain-based application may invoke a trusted computing module (e.g., trusted computing module 314) to record data representing the identities of the parties to the dispute and data representing the identities of the dispute resolution providers. If it is determined that the first party and the second party are not registered users of the blockchain-based application, the process proceeds to step 1306, where a notification is sent to the first party and the second party to inform them that they are not registered users. If it is determined that the first party and the second party are registered users of the blockchain-based application, the process proceeds to step 1308. At 1308, the time when the request was received is recorded on the blockchain. In some embodiments, the blockchain-based application may invoke a trusted time module (e.g., trusted time module 310) to record a timestamp indicating when a first request was received from the first party and a timestamp indicating when a second request was received from the second party. In some embodiments, the blockchain-based application may invoke a trusted computing module (e.g., trusted computing module 314) to record data representing the dispute between the parties. In some embodiments, the blockchain-based application may send information related to the dispute to multiple dispute resolution providers. In some embodiments, the blockchain-based application 300 may invoke trusted time module 310 to record data representing timestamps indicating when information about the dispute was sent to the dispute resolution providers. At 1310, one or more potential dispute solutions are received from one or more dispute solution providers registered on a blockchain-based application (e.g., dispute resolution tool 304). In some embodiments, one or more potential dispute solutions may be requested to be received within a predetermined time window. In some embodiments, the blockchain-based application (e.g., 304) may invoke a trusted time module 310 to record data indicating when each dispute solution provider offers a potential dispute solution. In some embodiments, the blockchain-based application may invoke a trusted computing module 314 to record data indicating the potential solutions offered by the dispute solution providers. In some embodiments, the blockchain-based application may send potential solutions to a first party and a second party. In some embodiments, the blockchain-based application may invoke a trusted time module 310 to record data indicating when a potential dispute solution is sent to the first party and data indicating when a potential dispute solution is sent to the second party. At 1312, a first selection is received from the first party and a second selection is received from the second party. In some embodiments, the first selection includes a first group of one or more potential dispute solutions, and the second selection includes a second group of one or more potential dispute solutions. In some embodiments, the blockchain-based application may invoke a trusted computing module 314 to record data indicating the first selection from the first party and data indicating the second selection from the second party. At 1314, the time when the first choice is received and the time when the second choice is received are recorded on the blockchain.For example, a blockchain application can invoke the trusted time module 310 to record data indicating a timestamp indicating when the first party provided a first option for a potential dispute resolution, and data indicating a timestamp indicating when the second party provided a second option for a potential dispute resolution. At 1316, it is determined whether there is at least one common potential dispute resolution between the first group of one or more potential dispute resolutions and the second group of one or more potential dispute resolutions. If it is determined that there is at least one common potential dispute resolution between the first group of one or more potential dispute resolutions and the second group of one or more potential dispute resolutions, the process proceeds to step 1318. If it is determined that there is no common potential dispute resolution between the first group of one or more potential dispute resolutions and the second group of one or more potential dispute resolutions, the blockchain application can determine that no potential dispute resolution is acceptable to both the first and second parties, and the process proceeds to step 1320. At 1318, virtual assets are sent to at least one dispute resolution provider that provided the common potential dispute resolution. For example, virtual assets can be provided to at least one dispute resolution provider that facilitated at least one common potential solution acceptable to both the first and second parties. At 1320, if it is determined that there is no common potential solution between the first group of one or more potential dispute resolutions and the second group of one or more potential solutions, the dispute resolution can be received from a legally authorized entity. In some embodiments, the legally authorized entity is different from the dispute resolution provider. In some embodiments, a first option is received from a first party and a second option is received from a second party within predetermined time windows. In some embodiments, it is also determined whether the received dispute resolution matches a dispute resolution in a first group of one or more dispute resolutions and a dispute resolution in a second group of one or more dispute resolutions. If it is determined that the dispute resolution most closely matches a dispute resolution in the first group of dispute resolutions selected by the first party, virtual assets withdrawn from the second party's second account can be sent to the dispute resolution provider, which provides the dispute resolution in the first group of dispute resolutions. If it is determined that the dispute resolution most closely matches a dispute resolution in the second group of dispute resolutions selected by the second party, virtual assets withdrawn from the first party's first account can be sent to the dispute resolution provider, which provides the dispute resolution in the second group of dispute resolutions. A diagram illustrating an example of a system 1400 for judgment enforcement according to embodiments herein is provided. System 1400 implements the processing of executing court judgments based on a blockchain network. Typically, system 1400 provides a method for enforcing court judgments, wherein each judgment specifies a debtor, a creditor, and the judgment amount owed by the debtor to the creditor.As an example, system 1400 includes debtor 1402, creditor 1404, one or more payment accounts of debtor 1406, judgment amount 1408, payment account of creditor 1410, court judgment 1412, blockchain-based trusted platform 300, and blockchain network 1416. As shown, the blockchain-based trusted platform 300 includes legal document processing tool 306, APIs 810, 812, and 814, trusted time module 310, trusted identity module 312, and trusted computing module 314. Note that the blockchain-based trusted platform 300 is shown as including judgment enforcement tool 308 for illustrative purposes only. The blockchain-based trusted platform 300 may include any suitable number of tools, such as subpoena service tools (e.g., subpoena service tool 302), dispute resolution tools (e.g., dispute resolution tool 304), and legal document processing tools (e.g., legal document processing tool 306), etc. In some embodiments, the trusted platform 300 is associated with one of the nodes 1414 in a blockchain network 1416, where the blockchain (e.g., blockchain 1410) is replicated across the blockchain network 1416. In one example, the blockchain-based trusted platform 300 implemented on a blockchain network node 1414 in the blockchain network 1416 can process and execute a court judgment 1412. The judgment amount 1408 can then be transferred from one or more payment accounts of the debtor 1406 to the payment account of the creditor 1410. In some embodiments, the judgment execution tool 308 can be configured to employ the SM2 algorithm, which is an elliptic curve-based public-key cryptography algorithm, to encrypt data communications and verify identity. In some embodiments, access levels can be specified for the content recorded by the judgment execution tool 308. Certain recorded content can only be accessed by personnel with specified access levels. In some embodiments, the trusted time module 310 can be configured to generate timestamps based on (i) national standard time information and / or (ii) time information obtained from the Global Positioning System. In some embodiments, the blockchain network can obtain time from a single source, allowing all blockchain nodes in the blockchain network to be synchronized to the same time. For example, the trusted time module 310 can be configured to generate a timestamp associated with the first debtor or creditor using a first standard time recognized by a first court system associated with the first debtor or creditor, and to generate a timestamp associated with the second debtor or creditor using a second standard time recognized by a second court system associated with the second debtor or creditor, wherein the first debtor or creditor and the second debtor or creditor reside in different areas with different court systems.In some embodiments, the trusted identity module 312 may be configured to verify the identity of a debtor or creditor based on one or more identifiers associated with the debtor or creditor, the identifiers including at least one of the following: (i) a mobile phone number, (ii) a credit card number, (iii) a user ID associated with an online payment system, (iv) a user ID associated with an online shopping account, (v) a user ID associated with a music streaming or download account, (vi) a user ID associated with a movie streaming or download account, (vii) a user ID associated with a messaging or chat account, (viii) a user ID associated with an online bank account, (ix) a user ID associated with a ride-hailing service, (x) a user ID associated with an online food ordering service, (xi) a social security number, (xii) a driver's license number, (xiii) a passport number, (xiv) a user ID associated with an online gaming service, or (xv) an ID issued by a government entity. In some embodiments, the trusted identity module 312 may be configured to verify the identity of a first debtor or creditor using at least one of a first set of identifiers recognized by a first court system associated with a first debtor or creditor, and to verify the identity of a second debtor or creditor using at least one of a second set of identifiers recognized by a second court system associated with a second debtor or creditor, wherein the first debtor or creditor and the second debtor or creditor reside in different areas with different court systems. In some embodiments, the trusted computing module 314 includes one or more data processors with a TEE isolated from the operating system of the one or more data processors and configured to provide enhanced confidentiality and integrity for code executed and data loaded in the one or more data processors. In some embodiments, the trusted computing module 314 may be configured to record information associated with debtors and / or creditors in accordance with privacy laws. In some embodiments, the blockchain-based judgment enforcement tool 308 may be configured to enforce court judgments, wherein each judgment specifies a debtor (e.g., debtor 1402), a creditor (e.g., creditor 1404), and a judgment amount owed by the debtor to the creditor (e.g., judgment amount 1408). The judgment enforcement tool 308 may further invoke a trusted time module to generate a first verified timestamp, which indicates the time when the judgment enforcement tool received the court judgment. In some embodiments, the judgment enforcement tool 308 may be configured to identify one or more assets associated with the debtor. The judgment enforcement tool 308 may also collect at least a portion of the judgment amount from the one or more assets associated with the debtor. The judgment enforcement tool 308 may be further configured to send the collected assets to the creditor.In some embodiments, the judgment enforcement tool 308 may be configured to identify one or more payment accounts associated with a debtor, send a court judgment to one or more financial institutions managing the one or more payment accounts associated with the debtor, and request the one or more financial institutions to collect at least a portion of the judgment amount from the payment accounts associated with the debtor. The judgment enforcement tool 308 may further invoke a trusted time module to generate a second verified timestamp indicating when the collected assets were sent to the creditor. The judgment enforcement tool 308 may also invoke a trusted computing module to process blockchain data to add a record to the blockchain, wherein the record includes information relating to the identities of the debtor and creditor, the first and second verified timestamps, and the amount of assets collected from the debtor and sent to the creditor. In some embodiments, the judgment enforcement tool 308 may be configured to perform multiple steps to enforce a court judgment, and for each of at least some of the multiple steps, the judgment enforcement tool 308 may be configured to invoke a trusted computing module to process blockchain data to update the blockchain, thereby recording information including a verified timestamp generated by a trusted time module and / or verified identity determined by a trusted identity module, wherein the verified timestamp represents the time of the event in the enforcement of the court judgment, and the verified identity represents the identity of the creditor or debtor. In some embodiments, the judgment enforcement tool 308 may be configured to process data in the blockchain to provide verified records associated with the multiple steps of enforcing the judgment. In some embodiments, the judgment enforcement tool 308 includes a trusted component configured to execute and record data associated with at least some of the steps performed by the judgment enforcement tool 308 in a TEE. In some embodiments, the trusted component includes a hash computing component configured to generate hash values ​​representing the data associated with the at least some steps performed by the judgment enforcement tool 308 based on a hash algorithm. In some embodiments, the blockchain-based judgment enforcement tool is configured to invoke the functions of the trusted time module, trusted identity module, or trusted computing module through corresponding application programming interfaces (APIs) associated with the trusted time module, trusted identity module, or trusted computing module. In some embodiments, the blockchain-based judgment enforcement tool 308 may include a client component and a server component. The client component may be configured to execute at a client terminal of the debtor or creditor, and the server component may be configured to execute at a computer server of the system. In some embodiments, the judgment enforcement tool 308 may be configured to enable the debtor to access blockchain data to verify that the amount collected from one or more assets associated with the debtor is consistent with the court judgment. In some embodiments, the judgment enforcement tool 308 may be configured to enable the creditor to access blockchain data to verify that the amount has been collected from one or more assets associated with the debtor.In some embodiments, the judgment enforcement tool 308 may be configured to enable a representative of the court to access blockchain data to verify the progress of judgment enforcement. A flowchart illustrating an example of a process 1500 that may be performed according to embodiments herein is provided. Process 1500 may be performed by one or more blockchain nodes or a computing device communicatively coupled to one or more blockchain nodes. For clarity, the following description, in conjunction with other accompanying drawings, generally describes process 1500. However, it should be understood that process 1500 may be suitably performed, for example, by any system, environment, software, and hardware, or a combination of systems, environments, software, and hardware. In some embodiments, the various steps of process 1500 may be run in parallel, in combination, cyclically, or in any order. At 1502, a request is received to collect a monetary ruling issued in a court order. In some embodiments, the request is associated with an account in a blockchain-based application. In some embodiments, the request may include an identity associated with the account. The monetary ruling may be, for example, cash, funds, stocks, bonds, foreign currency, or other types of assets. In some embodiments, the request may be initiated by a court or a creditor. In some embodiments, the request is a first request, and the account is a first account. Before receiving the first request, a second request associated with a second account in a blockchain-based application may be received. This second request is for recording a court order, and includes an identity associated with the second account. Based on the trusted identity module, the association of the second account with the court can be determined based on the identity associated with the second account and the registration information of the second account recorded on the blockchain. A trusted computing module can be invoked to record the order on the blockchain as a hash value of the order. A trusted time module can record a third verified timestamp indicating the time the order was recorded on the blockchain. At 1504, it is determined whether the order is authentic. In some embodiments, this can be determined by the trusted identity module (e.g., trusted identity module 312) based on a match with the hash value associated with the order recorded on the blockchain. At 1506, a first verified timestamp indicating the time the request was received is recorded on the blockchain. In some embodiments, the trusted time module (e.g., trusted time module 310) records the first verified timestamp. At 1508, the order is parsed. In some embodiments, a trusted computing module (e.g., trusted computing module 314) can be invoked to determine the creditor, debtor, and amount of the monetary ruling based on the parsed order. In some embodiments, a trusted computing module may be invoked to determine a deadline for enforcing a monetary ruling based on parsing the command, wherein the trusted computing module is invoked before the deadline to transfer the monetary ruling amount. At step 1510, it is determined whether the account is associated with the creditor. In some embodiments, based on a trusted identity module, the association of the account with the creditor is determined based on the identity and registration information of the account recorded on the blockchain.In step 1512, the payment accounts of the creditor and one or more payment accounts of the debtor are identified. In some embodiments, a trusted computing module is invoked to identify the payment accounts of the creditor and one or more payment accounts of the debtor based on registration information, wherein the cumulative balance of the one or more payment accounts of the debtor is greater than or equal to the amount of the monetary ruling. In some embodiments, the trusted computing module may query all payment accounts of the debtor to identify one or more payment accounts of the debtor whose cumulative balance is greater than or equal to the amount of the monetary ruling, without querying the exact balance of all payment accounts of the debtor. The trusted computing module may query whether the balance of the payment account is greater than a certain amount. The financial institution associated with the payment account may then respond "yes" or "no". For example, assuming the monetary ruling is $20,000, the trusted computing module may initiate by querying each payment account of the debtor whether it has a balance of $20,000. If more than one payment account responds "yes", a payment account may be randomly selected. If no payment account responds "yes", the trusted computing module may reduce the balance query, for example, querying whether the payment account has a balance of $10,000. The trusted computing module can continue to reduce the balance inquiry until one or more payment accounts of the debtor are identified as having a cumulative balance greater than or equal to the monetary ruling amount. At 1514, the monetary ruling amount is transferred. In some embodiments, the trusted computing module can be invoked to transfer the monetary ruling amount from one or more payment accounts of the debtor to the payment account of the creditor. In some embodiments, the trusted computing module can be invoked to transfer the monetary ruling amount based on an alert received from a financial institution associated with one or more payment accounts, wherein the alert indicates that a withdrawal or transfer request is initiated from at least one of the one or more payment accounts. In some embodiments, the trusted computing module can be invoked to transfer the monetary ruling amount when an alert indicates that a withdrawal or transfer amount associated with a withdrawal or transfer request will leave the remaining balance less than the monetary ruling. For example, assuming the monetary ruling is $20,000 and the debtor's payment account balance is $30,000, if the withdrawal or transfer amount is $20,000, the remaining balance in the payment account after the withdrawal or transfer will be $10,000, less than the monetary ruling. An alert can then be triggered to indicate that the withdrawal or transfer amount associated with the withdrawal or transfer request will leave the remaining balance less than the currency ruling, and a trusted computing module can be invoked to transfer the currency ruling amount. In some embodiments, there is a waiting period, such as 24 hours, between the time the withdrawal or transfer request is initiated and the time the financial institution executes the request. An alert from the financial institution can be sent to the trusted computing module when the withdrawal or transfer request is initiated. The trusted computing module can then determine whether the currency ruling amount should be transferred during the waiting period.In 1516, a second verified timestamp is recorded indicating the time of the determined amount of the transferred currency. In some embodiments, the second verified timestamp may be recorded by a trusted time module. Although the invention is defined by the appended claims, it should be understood that the invention may also be defined according to the following embodiments: Embodiment 1: A system comprising: an application layer including at least one blockchain-based application configured to perform multiple steps to provide a service; and a trusted service layer including a trusted time module, a trusted identity module, and a trusted computing module; wherein, for each of at least some of the multiple steps, the application is configured to perform at least one of the following based on processing blockchain data using the trusted computing module: obtaining a verified timestamp from the trusted time module, obtaining a verified identity from the trusted identity module, or obtaining a calculation result, the trusted computing module being configured to record information in the blockchain about the corresponding step performed by the application, and at least one of the verified timestamp, verified identity, or calculation result. Example 2: The system as described in Example 1, wherein the trusted computing module is configured to: in response to a request for verified records associated with the service, provide verified records of multiple steps performed by the application and at least one of verified timestamps, verified identities, or computation results associated with each of the multiple steps. Example 3: The system as described in Example 1 or 2, wherein the trusted computing module includes one or more data processors having a TEE, the TEE being isolated from the operating system of the one or more data processors and configured to provide enhanced confidentiality and integrity for code executed and data loaded in the one or more data processors. Example 4: The system as described in Example 3, wherein the blockchain-based application includes a trusted component configured to: execute and record multiple steps performed by the application in a trusted execution environment and at least one of verified timestamps, verified identities, or computation results associated with each of the multiple steps. Example 5: The system as described in Example 4, wherein the trusted component includes a hash computing component configured to generate hash values ​​representing data of the steps performed by the application based on a hash algorithm. Example 6: A system as described in any one of Examples 1 to 5, wherein the blockchain-based application is configured to invoke the functions of the trusted time module, trusted identity module, or trusted computing module through a corresponding application programming interface (API) associated with the trusted time module, trusted identity module, or trusted computing module. Example 7: A system as described in any one of Examples 1 to 6, wherein the trusted time module is configured to generate timestamps based on (i) national standard time information and / or (ii) time information obtained from the Global Positioning System.Example 8: A system as described in any one of Examples 1 to 7, wherein the trusted time module is configured to generate a timestamp associated with the first user using a first standard time recognized by a first court system associated with the first user, and to generate a timestamp associated with the second user using a second standard time recognized by a second court system associated with the second user, wherein the first user and the second user reside in different areas with different court systems. Example 9: A system as described in any one of Examples 1 to 8, wherein the trusted identity module is configured to verify the user's identity based on one or more identifiers associated with the user, the identifiers including at least one of the following: (i) a mobile phone number, (ii) a credit card number, (iii) a user ID associated with an online payment system, (iv) a user ID associated with an online shopping account, (v) a user ID associated with a music streaming or download account, (vi) a user ID associated with a movie streaming or download account, (vii) a user ID associated with a messaging or chat account, (viii) a user ID associated with an online banking account, (ix) a user ID associated with a ride-hailing service, (x) a user ID associated with an online food ordering service, (xi) a social security number, (xii) a driver's license number, (xiii) a passport number, (xiv) a user ID associated with an online gaming service, (xv) an ID issued by a government entity, (xvi) one or more fingerprints, (xvii) one or more voiceprints, or (xviii) iris information. Example 10: A system as described in any one of Examples 1 to 9, wherein the trusted identity module is configured to verify the identity of a first user using at least one of a first set of identifiers recognized by a first court system associated with a first user, and to verify the identity of a second user using at least one of a second set of identifiers recognized by a second court system associated with a second user, wherein the first user and the second user reside in different areas with different court systems. Example 11: A system as described in any one of Examples 1 to 10, wherein the trusted computing module is configured to record information associated with a user in accordance with privacy laws. Example 12: A system as described in any one of Examples 1 to 11, wherein a blockchain-based application provides a shopping service that enables users to search for information related to products offered by sellers and to place orders for those products, wherein the application is configured to invoke the trusted identity module to verify the user's identity and the seller's identity, and to invoke the trusted time module to verify the time the user placed the order. Example 13: A system as described in Example 12, wherein a blockchain-based application is configured to invoke the trusted computing module to update the blockchain, and the blockchain is configured to include data representing the user's online activity associated with placing orders for products.Example 14: The system as described in Example 13, wherein the blockchain-based application is configured to invoke a trusted computing module to update the blockchain, thereby including data representing information displayed to the user after the user initiates checkout processing, as well as each piece of information provided by the user to the seller, the user's identity, the seller's identity, and the time the order was placed. Example 15: The system as described in Example 14, wherein the information displayed to the user after the user initiates checkout processing includes a description of the ordered product, the price of the product, the seller's identifier, the name of the entity receiving the product, the delivery address, and a message requesting the user to confirm the order. Example 16: The system as described in any one of Examples 1 to 15, wherein the blockchain-based application includes a web browser configured to enable a user to view web pages on the network and save the content of one or more web pages in a storage device, wherein the application is configured to invoke a trusted identity module to verify the user's identity and a trusted time module to verify the time the user viewed and / or saved the web pages. Example 17: A system as described in Example 16, wherein a blockchain-based application is configured to invoke a trusted computing module to update the blockchain, and the blockchain is configured to include data representing the content of web pages viewed and / or saved by users, the URL of the web pages, the user's identity, and a timestamp showing when the user viewed and / or saved the web pages. Example 18: A system as described in any one of Examples 1 to 17, wherein a blockchain-based application provides an online agreement signing service enabling two or more parties to reach agreements online, wherein the application is configured to invoke a trusted identity module to verify the identities of the parties to the agreement, and to invoke a trusted time module to verify the time when the parties signed the agreement. Example 19: A system as described in Example 18, wherein a blockchain-based application invokes a trusted computing module to update the blockchain, and the blockchain is configured to include data representing the online activities of the parties associated with signing the agreement. Example 20: The system as described in Example 18, wherein a blockchain-based application invokes a trusted computing module to update the blockchain, thereby including data representing: (i) the content of the agreement signed by the parties, (ii) any modifications made by the parties to the agreement, (iii) the identities of the parties who signed the agreement, and (iv) a timestamp showing when the parties signed the agreement.Example 21: A method comprising: providing a service to a user in multiple steps on a blockchain-based trusted platform; for each of the multiple steps, performing at least one of the following: obtaining a verified timestamp from a trusted time module of the trusted platform; obtaining a verified identity from a trusted identity module of the trusted platform, or obtaining a computation result from a trusted computing module of the trusted platform; and recording data associated with the service provided to the user and at least one of the verified timestamp, the verified identity, or the computation result associated with the step in the blockchain. Example 22: The method of Example 21, further comprising: in response to a request for verified records associated with the service, providing verified records of multiple steps performed by an application and at least one of the verified timestamp, the verified identity, or the computation result associated with each of the multiple steps. Example 23: The method of Example 21 or 22, further comprising: utilizing a trusted computing module to process blockchain data of a blockchain using one or more data processors having a TEE, the TEE being isolated from the operating system of the one or more data processors and configured to provide enhanced confidentiality and integrity for code executed and data loaded in the one or more data processors. Example 24: The method of Example 23, comprising: executing a trusted component associated with providing a service in a trusted execution environment, and recording multiple steps of the service provided to a user and at least one of a verified timestamp, verified identity, or computation result associated with each of the multiple steps in the blockchain. Example 25: The method of Example 24, wherein executing the trusted component includes calculating a hash value of data associated with the steps of the service provided to the user based on a hash algorithm. Example 26: The method of any one of Examples 21 to 25, comprising: a blockchain-based application of a trusted platform being configured to invoke the functions of the trusted time module, trusted identity module, or trusted computing module through a corresponding application programming interface (API) associated with the trusted time module, trusted identity module, or trusted computing module. Example 27: The method of any one of Examples 21 to 26, comprising: generating a timestamp at the trusted time module based on (i) national standard time information and / or (ii) time information obtained from the Global Positioning System. Example 28: The method as described in any one of Examples 21 to 27, comprising: generating a timestamp associated with a first user at a trusted time module using a first standard time recognized by a first court system associated with a first user, and generating a timestamp associated with a second user using a second standard time recognized by a second court system associated with a second user, wherein the first user and the second user reside in different areas with different court systems.Example 29: The method as described in any one of Examples 21 to 28, comprising: verifying the identity of a user at a trusted identity module based on one or more identifiers associated with the user, the identifiers including at least one of the following: (i) a mobile phone number, (ii) a credit card number, (iii) a user ID associated with an online payment system, (iv) a user ID associated with an online shopping account, (v) a user ID associated with a music streaming or download account, (vi) a user ID associated with a movie streaming or download account, (vii) a user ID associated with a messaging or chat account, (viii) a user ID associated with an online banking account, (ix) a user ID associated with a ride-hailing service, (x) a user ID associated with an online food ordering service, (xi) a social security number, (xii) a driver's license number, (xiii) a passport number, (xiv) a user ID associated with an online gaming service, (xv) an ID issued by a government entity, (xvi) one or more fingerprints, (xvii) one or more voiceprints, or (xviii) iris information. Example 30: The method of any one of Examples 21 to 29, comprising: at a trusted identity module, verifying the identity of a first user using at least one of a first set of identifiers recognized by a first court system associated with a first user, and verifying the identity of a second user using at least one of a second set of identifiers recognized by a second court system associated with a second user, wherein the first user and the second user reside in different areas with different court systems. Example 31: The method of any one of Examples 21 to 30, comprising: at a trusted computing module, recording information associated with a user in accordance with privacy laws. Example 32: The method of any one of Examples 21 to 31, wherein providing the service comprises: providing a shopping service that enables a user to search for information related to products offered by a seller and to place an order for such products, wherein the method comprises invoking a trusted identity module to verify the user's identity and the seller's identity, and invoking a trusted time module to verify the time the user placed the order. Example 33: The method of Example 32, comprising: invoking a trusted computing module to update a blockchain, the blockchain being configured to include data representing a user's online activity associated with placing an order for a product. Example 34: The method as described in Example 33, comprising: invoking a trusted computing module to update the blockchain, thereby including data representing information displayed to the user after the user initiates checkout processing, as well as each piece of information provided by the user to the seller, the user's identity, the seller's identity, and the time the order was placed. Example 35: The method as described in Example 34, wherein the information displayed to the user after the user initiates checkout processing includes a description of the ordered product, the price of the product, the seller's identifier, the name of the entity receiving the product, the delivery address, and a message requesting the user to confirm the order.Example 36: The method of any one of Examples 21 to 35, wherein providing the service includes: providing a web browser configured to enable users to view web pages on the network and save the content of one or more web pages in a storage device, the method including invoking a trusted identity module to verify the user's identity and invoking a trusted time module to verify the time when the user viewed and / or saved the web pages. Example 37: The method of Example 36, comprising: invoking a trusted computing module to update a blockchain, the blockchain being configured to include data representing the content of web pages viewed and / or saved by a user, the URL of the web page, the user's identity, and a timestamp showing when the user viewed and / or saved the web page. Example 38: The method of any one of Examples 21 to 37, wherein providing the service includes: providing an online agreement signing service enabling two or more parties to reach an agreement online, the method including invoking a trusted identity module to verify the identities of the parties to the agreement and invoking a trusted time module to verify the time when the parties signed the agreement. Example 39: The method of Example 38, wherein a blockchain-based application invokes a trusted computing module to update the blockchain, the blockchain being configured to include data representing the online activities of the parties associated with the signing agreement. Example 40: The method as described in Examples 38 or 39 includes: invoking a trusted computing module to update the blockchain to include data representing: (i) the content of an agreement signed by the parties, (ii) any modifications made by the parties to the agreement, (iii) the identities of the parties signing the agreement, and (iv) a timestamp showing when the parties signed the agreement. A flowchart illustrating an example of a process 1600 that can be performed according to embodiments herein is provided. Process 1600 can be performed by one or more blockchain nodes or a computing device communicatively coupled to one or more blockchain nodes. For clarity, the following description generally describes process 1600 in conjunction with other accompanying drawings herein. However, it should be understood that process 1600 can be suitably performed, for example, by any system, environment, software, and hardware, or a combination of systems, environments, software, and hardware. In some embodiments, the various steps of process 1600 can be run in parallel, combined, cyclically, or in any order. At 1602, a service is provided to a user in multiple steps on a blockchain-based trusted platform. In some embodiments, the service includes delivering a notification to another user. In some embodiments, the service includes providing a potential dispute resolution to two or more users with a dispute. In some embodiments, the service includes providing legal document processing. In some embodiments, the service includes enforcing court judgments. At 1604, for each of the plurality of steps, at least one of the following is performed: obtaining a verified timestamp from the trusted time module of the trusted platform, obtaining a verified identity from the trusted identity module of the trusted platform, or obtaining a calculation result from the trusted computing module of the trusted platform.In some embodiments, a trusted computing module is used to process blockchain data using one or more data processors with a TEE (Transmission Equipment), the TEE being isolated from the operating system of the one or more data processors and configured to provide enhanced confidentiality and integrity for code executed and data loaded in the one or more data processors. In some embodiments, a trusted component associated with providing a service is executed in a trusted execution environment, and multiple steps of the service provided to a user and at least one of a verified timestamp, verified identity, or computation result associated with each of the multiple steps are recorded in the blockchain. In some embodiments, executing the trusted component includes calculating a hash value of the data associated with the steps of the service provided to the user based on a hash algorithm. In some embodiments, a blockchain-based application of a trusted platform is configured to provide services to users by invoking the functions of the trusted time module, trusted identity module, or trusted computing module through corresponding APIs associated with the trusted time module, trusted identity module, or trusted computing module. In some embodiments, the trusted time module generates timestamps based on (i) national standard time information and / or (ii) time information obtained from the Global Positioning System. In some embodiments, the trusted time module generates a timestamp associated with the first user using a first standard time recognized by a first court system associated with the first user, and generates a timestamp associated with the second user using a second standard time recognized by a second court system associated with the second user, wherein the first user and the second user reside in different regions with different court systems. In some embodiments, the trusted identity module verifies the user's identity based on one or more identifiers associated with the user, the identifiers including at least one of the following: (i) a mobile phone number, (ii) a credit card number, (iii) a user ID associated with an online payment system, (iv) a user ID associated with an online shopping account, (v) a user ID associated with a music streaming or download account, (vi) a user ID associated with a movie streaming or download account, (vii) a user ID associated with a messaging or chat account, (viii) a user ID associated with an online bank account, (ix) a user ID associated with a ride-hailing service, (x) a user ID associated with an online food ordering service, (xi) a social security number, (xii) a driver's license number, (xiii) a passport number, (xiv) a user ID associated with an online gaming service, (xv) an ID issued by a government entity, (xvi) one or more fingerprints, (xvii) one or more voiceprints, or (xviii) iris information.In some embodiments, the trusted identity module verifies the identity of a first user using at least one of a first set of identifiers recognized by a first court system associated with the first user, and verifies the identity of a second user using at least one of a second set of identifiers recognized by a second court system associated with the second user, wherein the first user and the second user reside in different areas with different court systems. In some embodiments, the trusted computing module records information associated with the user in accordance with privacy laws. At 1606, data associated with the service provided to the user, and at least one of a verified timestamp, verified identity, or calculation result associated with the step, is recorded in a blockchain. Optionally, the process 1600 includes: in response to a request for a verified record associated with the service, providing verified records of multiple steps performed by the application and at least one of a verified timestamp, verified identity, or calculation result associated with each of the multiple steps. In some embodiments, providing the service includes: providing a shopping service that enables a user to search for information related to products offered by a seller and to place an order for the product, invoking the trusted identity module to verify the user's identity and the seller's identity, and invoking the trusted time module to verify the time when the user placed the order. In some embodiments, a trusted computing module is invoked to update a blockchain configured to include data representing a user's online activity associated with placing an order for a product. In some embodiments, the trusted computing module is invoked to update the blockchain to include data representing information displayed to the user after the user initiates checkout processing, as well as each piece of information provided by the user to the seller, the user's identity, the seller's identity, and the time the order was placed. In some embodiments, the information displayed to the user after the user initiates checkout processing includes a description of the ordered product, the price of the product, the seller's identifier, the name of the entity receiving the product, the delivery address, and a message requiring the user to confirm the order. In some embodiments, providing a service includes: providing a web browser configured to enable a user to view web pages on the network and save the content of one or more web pages in a storage device, invoking a trusted identity module to verify the user's identity, and invoking a trusted time module to verify the time when the user viewed and / or saved the web pages. In some embodiments, the trusted computing module is invoked to update the blockchain, which is configured to include data representing the content of web pages viewed and / or saved by the user, the URL of the web page, the user's identity, and a timestamp showing when the user viewed and / or saved the web page. In some embodiments, the service includes: providing an online agreement signing service that enables two or more parties to reach an agreement online, invoking a trusted identity module to verify the identities of the parties to the agreement, and invoking a trusted time module to verify the time when the parties signed the agreement.In some embodiments, a blockchain-based application invokes a trusted computing module to update a blockchain configured to include data representing the online activities of parties associated with a signed agreement. In some embodiments, invoking the trusted computing module to update the blockchain includes data representing: (i) the content of the agreement signed by the parties, (ii) any modifications made to the agreement by the parties, (iii) the identities of the parties signing the agreement, and (iv) a timestamp showing when the parties signed the agreement. A diagram is shown as an example of modules of apparatus 1700 according to embodiments herein. Apparatus 1700 may be an example of an embodiment of a blockchain-based trusted platform configured to provide legal services to a user. Apparatus 1700 may correspond to the embodiments described above, and apparatus 1700 includes: a providing module 1702 that provides services to a user in multiple steps; a trusted time module 1704 that provides verified timestamps; a trusted identity module 1706 that provides verified identities; a trusted computing module 1708 that provides trusted computing results; and a recording module 1710 that records data associated with the services provided to the user and at least one of verified timestamps, verified identities, or computing results associated with steps in the blockchain. In an optional embodiment, the providing module 1702 includes a blockchain-based trusted platform, such as a blockchain-based trusted online platform. In an optional embodiment, the apparatus 1700 further includes a providing module that, in response to a request for verified records associated with the service, provides verified records of multiple steps performed by the application and at least one of verified timestamps, verified identities, or computation results associated with each of the multiple steps. In an optional embodiment, the trusted computing module 1708 processes blockchain data using one or more data processors with a TEE, the TEE being isolated from the operating system of the one or more data processors and configured to provide enhanced confidentiality and integrity for the code executed in the one or more data processors and the data loaded. In an optional embodiment, the trusted computing module 1708 executes trusted components associated with providing the service in a trusted execution environment, and records multiple steps of the service provided to the user and at least one of verified timestamps, verified identities, or computation results associated with each of the multiple steps in the blockchain. In an optional embodiment, the trusted components calculate hash values ​​of the data associated with the steps of the service provided to the user based on a hash algorithm. In an optional embodiment, the blockchain-based trusted platform includes a blockchain-based application that provides services to users, which invokes the functions of the trusted time module, trusted identity module, or trusted computing module through a corresponding application programming interface (API) associated with the trusted time module 1704, trusted identity module 1706, or trusted computing module 1708.In an optional embodiment, the trusted time module 1704 generates a timestamp based on (i) national standard time information and / or (ii) time information obtained from the Global Positioning System. In another optional embodiment, the trusted time module 1704 generates a timestamp associated with the first user using a first standard time recognized by a first court system associated with the first user, and generates a timestamp associated with the second user using a second standard time recognized by a second court system associated with the second user, wherein the first user and the second user reside in different areas with different court systems. In an optional embodiment, the trusted identity module 1706 verifies the user's identity based on one or more identifiers associated with the user, the identifiers including at least one of the following: (i) a mobile phone number, (ii) a credit card number, (iii) a user ID associated with an online payment system, (iv) a user ID associated with an online shopping account, (v) a user ID associated with a music streaming or download account, (vi) a user ID associated with a movie streaming or download account, (vii) a user ID associated with a messaging or chat account, (viii) a user ID associated with an online banking account, (ix) a user ID associated with a ride-hailing service, (x) a user ID associated with an online food ordering service, (xi) a social security number, (xii) a driver's license number, (xiii) a passport number, (xiv) a user ID associated with an online gaming service, (xv) an ID issued by a government entity, (xvi) one or more fingerprints, (xvii) one or more voiceprints, or (xviii) iris information. In an optional embodiment, the trusted identity module 1706 verifies the identity of the first user using at least one of a first set of identifiers recognized by a first court system associated with the first user, and verifies the identity of the second user using at least one of a second set of identifiers recognized by a second court system associated with the second user, wherein the first user and the second user reside in different areas with different court systems. In an optional embodiment, the trusted computing module 1708 records information associated with the user in accordance with privacy laws. In an optional embodiment, the providing module 1702 provides a shopping service that enables the user to search for information related to products offered by a seller and to place an order for those products, invokes the trusted identity module 1706 to verify the user's identity and the seller's identity, and invokes the trusted time module to verify the time the user placed the order. In an optional embodiment, the trusted computing module 1708 is invoked to update the blockchain, wherein the blockchain is configured to include data representing the user's online activity associated with placing an order for the product. In an optional embodiment, the trusted computing module 1708 is invoked to update the blockchain, thereby including data representing information displayed to the user after the user initiates checkout processing, as well as each piece of information provided by the user to the seller, the user's identity, the seller's identity, and the time the order was placed.In an optional embodiment, the information displayed to the user after the user initiates checkout includes a description of the ordered product, the price of the product, the seller's identifier, the name of the entity receiving the product, the delivery address, and a message requiring the user to confirm the order. In an optional embodiment, the providing module 1702 provides a web browser configured to enable the user to view web pages on the network and save the content of one or more web pages in a storage device, invokes the trusted identity module 1706 to verify the user's identity, and invokes the trusted time module 1704 to verify the time when the user viewed and / or saved the web pages. In an optional embodiment, the trusted computing module 1708 is invoked to update the blockchain, wherein the blockchain is configured to include data representing the content of the web pages viewed and / or saved by the user, the URL of the web page, the user's identity, and a timestamp showing when the user viewed and / or saved the web page. In an optional embodiment, the providing module 1702 provides an online agreement signing service enabling two or more parties to reach an agreement online, invokes the trusted identity module 1706 to verify the identities of the parties to the agreement, and invokes the trusted time module 1704 to verify the time when the parties signed the agreement. In an alternative embodiment, a blockchain-based application invokes a trusted computing module to update the blockchain, which is configured to include data representing the online activities of the parties associated with the signed agreement. In an alternative embodiment, a trusted computing module 1708 is invoked to update the blockchain, thereby including data representing: (i) the content of the agreement signed by the parties, (ii) any modifications made to the agreement by the parties, (iii) the identities of the parties signing the agreement, and (iv) a timestamp showing when the parties signed the agreement. A diagram is shown as an example of a module of another apparatus 1800 according to embodiments herein. Apparatus 1800 may be an example of an embodiment of a blockchain node configured to perform subpoena service in a blockchain network.Device 1800 may correspond to the foregoing embodiments. Device 1800 includes the following: a receiving module 1802, which receives a request generated based on a blockchain application, the request being used to deliver a notification related to legal proceedings from a sender to a recipient, wherein the request includes an identity associated with the sender and an identity associated with the recipient; a first determining module 1804, which determines that the sender is a registered user of the blockchain application based on a match between the sender's identity and the identity contained in the sender's registration information recorded on the blockchain; a recording module 1806, which records the time of receiving the request on the blockchain; a second determining module 1808, which determines whether the recipient is a registered user of the blockchain application based on the identity associated with the recipient; an identification module 1810, which, in response to determining that the recipient is a registered user, identifies one or more methods for delivering the notification based on the registration information of the sender and the available communication methods contained in the registration information of the recipient; and a delivery module 1812, which delivers the notification to the recipient based on at least one of the one or more methods. In an optional embodiment, device 1800 further includes: a sending submodule, which, in response to determining that the recipient is not a registered user of the blockchain-based application, sends a notification to the account associated with the recipient. In an optional embodiment, device 1800 further includes: a determining submodule, which, after delivering the notification to the recipient, determines whether the recipient is logged into an account registered on the blockchain-based application; and a sending submodule, in response to determining that the recipient is logged into an account registered on the blockchain-based application, sends a notification to the account associated with the recipient to notify that the notification has been delivered. In an optional embodiment, device 1800 further includes: a sending submodule, which, in response to determining that the recipient is not logged into an account registered on the blockchain-based application, sends a notification to the account associated with the recipient to notify that the recipient is offline. In an optional embodiment, device 1800 further includes: an adding submodule, which, before delivering the notification to the recipient, adds the time and a digital signature generated based on the time to the notification. In an optional embodiment, the device 1800 further includes: a receiving submodule for receiving confirmation from an account associated with the recipient for accepting a notification from the sender; a recording submodule for recording the time of receiving the confirmation on a blockchain; and a delivery submodule for delivering the confirmation to the sender based on available communication methods contained in the sender's registration information. In an optional embodiment, available communication methods include at least one of the following: email, telephone call, or instant messaging. Again, this can be interpreted as illustrating the internal functional modules and structure of a blockchain voucher delivery device. A blockchain voucher delivery device may be an example of a blockchain node configured to perform voucher delivery in a blockchain network.The execution entity may essentially be an electronic device, and the electronic device includes: one or more processors; and one or more computer-readable storage devices configured to store executable instructions of the one or more processors. In some embodiments, the one or more computer-readable storage devices are coupled to one or more processors and have programming instructions stored thereon, which are executable by the one or more processors to perform algorithms, methods, functions, processes, flows, and programs as described herein. Embodiments of the described subject matter may individually or in combination include one or more features. For example, in a first embodiment, a method for facilitating blockchain-based subpoena service, executed by a blockchain node, includes: receiving a request generated by a blockchain application to deliver a notice related to legal proceedings from a servicer to a recipient, wherein the request includes an identity associated with the servicer and an identity associated with the recipient; determining that the servicer is a registered user of the blockchain application based on a match between the servicer's identity and an identity contained in the servicer's registration information recorded on the blockchain; recording the time of receiving the request on the blockchain; determining whether the recipient is a registered user of the blockchain application based on the identity associated with the recipient; in response to determining that the recipient is a registered user, identifying one or more methods for delivering the notice based on the servicer's registration information and available communication methods contained in the recipient's registration information; and delivering the notice to the recipient based on at least one of the one or more methods. The foregoing and other described embodiments may optionally include one or more of the following features: A first feature, which may be combined with any of the following features, specifies that the method further includes: in response to determining that the recipient is not a registered user of the blockchain-based application, sending a notification to the account associated with the recipient. A second feature, which may be combined with any of the preceding or following features, specifies that the method further includes: after delivering the notification to the recipient, determining whether the recipient is logged into the account registered on the blockchain-based application, and in response to determining that the recipient is logged into the account registered on the blockchain-based application, sending a notification to the account associated with the recipient to notify that the notification has been delivered. A third feature, which may be combined with any of the preceding or following features, specifies that the method further includes: in response to determining that the recipient is not logged into the account registered on the blockchain-based application, sending a notification to the account associated with the recipient to notify that the recipient is offline. A fourth feature, which may be combined with any of the preceding or following features, specifies that the method further includes: before delivering the notification to the recipient, adding the time and a digital signature generated based on the time to the notification.A fifth feature, which may be combined with any of the preceding or following features, specifies that the method further includes: receiving an acknowledgment from an account associated with the recipient for accepting a notification from the sender; recording the time of receiving the acknowledgment on the blockchain; and delivering the acknowledgment to the sender based on the available communication methods contained in the sender's registration information. A sixth feature, which may be combined with any of the preceding or following features, specifies that the available communication methods include at least one of the following: email, telephone call, or instant messaging. The diagram illustrates an example of a module of another apparatus 1900 according to embodiments of this document. Apparatus 1900 may be an example of an embodiment of a blockchain node configured to perform dispute resolution processing in a blockchain network. Device 1900 may correspond to the above-described embodiments. Device 1900 includes the following: a first receiving module 1902, which receives a request for resolving a dispute between at least a first party and a second party, wherein the request includes a first identity associated with the first party and a second identity associated with the second party; a first determining module 1904, which determines, based on a match between the first identity and an identity contained in the first party's registration information recorded on the blockchain, and a match between the second identity and an identity contained in the second party's registration information recorded on the blockchain, that the first party and the second party are registered users of the blockchain-based application; a first recording module 1906, which records the time of receiving the request on the blockchain; and a second receiving module 1908, which receives one or more disputes registered on the blockchain-based application. A solution provider receives one or more potential disputed solutions; a third receiving module 1910 receives a first selection from the first party and a second selection from the second party, wherein the first selection includes a first group of one or more potential disputed solutions, and the second selection includes a second group of one or more potential disputed solutions; a second recording module 1912 records the time of receiving the first selection and the time of receiving the second selection on a blockchain; and a second determining module 1914 determines (i) that there is at least one common potential disputed solution between the first group of one or more potential disputed solutions and the second group of one or more potential disputed solutions, and / or (ii) that no potential disputed solution is acceptable to both the first party and the second party. In an optional embodiment, the request for resolving the dispute includes virtual assets, and the apparatus 1900 further includes: a sending submodule that sends the virtual assets to at least one of the one or more disputed solution providers that provides at least one common disputed solution.In an optional embodiment, the device 1900 further includes: a first receiving submodule, which receives from a first party a first request to resolve a dispute, the first request including a first virtual asset; a second receiving submodule, which receives from a second party a second request to resolve a dispute, the second request including a second virtual asset; and a determining submodule, which determines a virtual asset based on the virtual asset with higher value between the first and second virtual assets. In an optional embodiment, the device 1900 further includes: a removal submodule, which removes virtual assets from a first account associated with the first party and a second account associated with the second party, respectively; and a storage submodule, which stores the virtual assets removed from the first and second accounts on a blockchain. In an optional embodiment, the device 1900 further includes: a first determining submodule, determining that there is no common dispute solution between a first group of one or more dispute solutions and a second group of one or more dispute solutions; a receiving submodule, receiving a dispute solution from a legally authorized entity different from the dispute solution provider; a second determining submodule, determining whether the dispute solution matches a dispute solution in the first group of one or more dispute solutions and a dispute solution in the second group of one or more dispute solutions; a first sending submodule, in response to determining that the dispute solution is most closely matched with the first group of one or more dispute solutions, sending virtual assets removed from the second account to the dispute solution provider providing the dispute solution in the first group of one or more dispute solutions; or a second sending submodule, in response to determining that the dispute solution is most closely matched with the second group of one or more dispute solutions, sending virtual assets removed from the first account to the dispute solution provider providing the dispute solution in the second group of one or more dispute solutions. In an optional embodiment, a first selection is received from a first party and a second selection is received from a second party within a predetermined time window. Referring again, it can be interpreted as illustrating the internal functional modules and structure of a blockchain dispute resolution device. A blockchain dispute resolution device may be an example of a blockchain node configured to perform dispute resolution processing in a blockchain network. The execution entity may essentially be an electronic device, and the electronic device includes: one or more processors; and one or more computer-readable storage devices configured to store executable instructions of the one or more processors. In some embodiments, the one or more computer-readable storage devices are coupled to one or more processors and have programming instructions stored thereon, which are executable by the one or more processors to perform algorithms, methods, functions, processes, flows, and programs as described herein. Embodiments of the described subject matter may individually or in combination include one or more features.For example, in a first embodiment, a method for performing blockchain-based dispute resolution processing includes: at a blockchain-based application, receiving a request for resolving a dispute between at least a first party and a second party, wherein the request includes a first identity associated with the first party and a second identity associated with the second party; determining that the first party and the second party are registered users of the blockchain-based application based on a match between the first identity and an identity contained in the first party's registration information recorded on the blockchain, and a match between the second identity and an identity contained in the second party's registration information recorded on the blockchain; recording the time of receiving the request on the blockchain; receiving one or more potential dispute solutions from one or more dispute solution providers registered in the blockchain-based application; receiving a first option from the first party and a second option from the second party, wherein the first option includes a first group of one or more potential dispute solutions, and the second option includes a second group of one or more potential dispute solutions; recording the time of receiving the first option on the blockchain and recording the time of receiving the second option on the blockchain; and determining (i) that there is at least one common potential dispute solution between the first group of one or more potential dispute solutions and the second group of one or more potential dispute solutions, and / or (ii) that no potential dispute solution is acceptable to both the first party and the second party. The foregoing and other described embodiments may each optionally include one or more of the following features: a first feature, which may be combined with any of the following features, specifies that the request for resolving the dispute includes virtual assets, and the method includes sending the virtual assets to at least one of the one or more dispute resolution providers offering at least one common dispute resolution solution. A second feature, which may be combined with any of the preceding or following features, specifies that the method further includes: receiving from a first party a first request for resolving the dispute, the first request including a first virtual asset; receiving from a second party a second request for resolving the dispute, the second request including a second virtual asset; and determining the virtual asset based on the virtual asset with higher value among the first and second virtual assets. A third feature, which may be combined with any of the preceding or following features, specifies that the method further includes: removing the virtual assets from a first account associated with the first party and a second account associated with the second party, respectively; and storing the virtual assets removed from the first account and the second account on a blockchain.A fourth feature, which can be combined with any of the preceding or following features, specifies that the method further includes: determining that there is no common dispute solution between the first group of one or more dispute solutions and the second group of one or more dispute solutions; receiving a dispute solution from a legally authorized entity different from the dispute solution provider; determining whether the dispute solution matches a dispute solution in the first group of one or more dispute solutions and the second group of one or more dispute solutions; in response to determining that the dispute solution is most closely matched with a dispute solution in the first group of one or more dispute solutions, sending virtual assets removed from the second account to the dispute solution provider that provided the dispute solution in the first group of one or more dispute solutions; or in response to determining that the dispute solution is most closely matched with a dispute solution in the second group of one or more dispute solutions, sending virtual assets removed from the first account to the dispute solution provider that provided the dispute solution in the second group of one or more dispute solutions. A fifth feature, which can be combined with any of the preceding or following features, specifies receiving a first selection from a first party and a second selection from a second party respectively within a predetermined time window. This is an example diagram of a module of another apparatus 2000 according to embodiments of this document. Apparatus 2000 may be an example of an embodiment of a blockchain node configured to process information. The apparatus 2000 may correspond to the above embodiment. The apparatus 2000 includes the following: a receiving module 2002, which receives a request initiated from an account of a user associated with a blockchain-based application, the request being for providing services, wherein the request includes an identity associated with the user; a determining module 2004, which determines the user as a registered user of the blockchain-based application based on a match between the identity and an identity contained in the registration information of the user associated with the blockchain-based application recorded on the blockchain; an identification module 2006, which identifies one or more electronic forms to be filled out and submitted in multiple steps for providing services; and a generating module 2008, which, in each of the multiple steps, determines the user based on the time of execution of the step and... The process involves: generating a unique identifier (ID) for the digital content on the spreadsheet; a first recording module 2010 recording the unique ID, the time, and the digital content on a blockchain in each of the plurality of steps; an embedding module 2012 embedding the unique ID into the digital content at that time by changing one or more attributes associated with the digital content to represent the unique ID in each of the plurality of steps, wherein the embedding generates digital content that can retrieve the embedded information of the time and the digital content from the blockchain based on the unique ID; and a second recording module 2014 recording the digital content of the embedded information on the blockchain in each of the plurality of steps.In an optional embodiment, the request is a first request, and the apparatus 2000 further includes: a receiving submodule for receiving a second request initiated from an account of a service provider associated with a blockchain-based application, wherein the second request is used to process the first request, and the second request includes an identity associated with the service provider; and a determining submodule for determining that the service provider is a registered service provider for the blockchain-based application based on a match between the identity associated with the service provider and the identity contained in the service provider's registration information recorded on the blockchain. In an optional embodiment, the user and the service provider perform multiple steps. In an optional embodiment, in each of the multiple steps performed by the user, a unique ID is generated based on the time and the digital content filled in by the user on a spreadsheet at that time, wherein the unique ID is embedded in the digital content filled in by the user. In an optional embodiment, the unique ID is a first unique ID, and the apparatus 2000 further includes: a generating submodule for generating a second unique ID based on the time of performing the step and the digital content in the spreadsheet filled in by the service provider at that time; and an embedding submodule for embedding the second unique ID into the digital content filled in by the service provider in each of the multiple steps performed by the service provider. In an optional embodiment, the visual differences between the spreadsheet and the embedded digital content are not readily apparent to the naked eye. In an optional embodiment, the unique ID is generated based on a hash function and / or asymmetric encryption. In an optional embodiment, embedding the unique ID is performed based on digital watermarking processing using one or more of discrete wavelet transform, discrete cosine transform, singular value decomposition, least significant bit, or undetectable steganography. In an optional embodiment, one or more attributes associated with the digital content include one or more of the digital content's color, size, orientation, shape, and font. In alternative embodiments, the identity includes at least one of the following: (i) a mobile phone number, (ii) a credit card number, (iii) a user ID associated with an online payment system, (iv) a user ID associated with an online shopping account, (v) a user ID associated with a music streaming or download account, (vi) a user ID associated with a movie streaming or download account, (vii) a user ID associated with a messaging or chat account, (viii) a user ID associated with an online bank account, (ix) a user ID associated with a ride-hailing service, (x) a user ID associated with an online food ordering service, (xi) a social security number, (xii) a driver's license number, (xiii) a passport number, (xiv) a user ID associated with an online gaming service, or (xv) an ID issued by a government entity. Again, this can be interpreted as illustrating the internal functional modules and structure of a blockchain information processing device. The blockchain information processing device can be an example of a blockchain node configured to perform information processing within a blockchain network.The execution entity may essentially be an electronic device, and the electronic device includes: one or more processors; and one or more computer-readable storage devices configured to store executable instructions of the one or more processors. In some embodiments, the one or more computer-readable storage devices are coupled to one or more processors and have programming instructions stored thereon, which are executable by the one or more processors to perform algorithms, methods, functions, processes, flows, and programs as described herein. Embodiments of the described subject matter may individually or in combination include one or more features. For example, in a first embodiment, the blockchain-based information processing method executed by a blockchain node includes: receiving a request initiated from an account of a user associated with a blockchain-based application, the request being for providing services, wherein the request includes an identity associated with the user; determining the user as a registered user of the blockchain-based application based on a match between the identity and an identity contained in the user's registration information recorded on the blockchain; identifying one or more forms to be filled out and submitted in multiple steps for providing the service; in each of the multiple steps: generating a unique identifier (ID) based on the time of execution of the step and the digital content on the form at that time; recording the unique ID, the time, and the digital content on the blockchain; in each of the multiple steps: embedding the unique ID into the digital content at that time by changing one or more attributes associated with the digital content to represent the unique ID, wherein the embedding generates digital content that allows retrieval of the time and the digital content from the blockchain based on the unique ID; and in each of the multiple steps, recording the digital content of the embedded information on the blockchain. The foregoing and other described embodiments may each optionally include one or more of the following features: a first feature, which may be combined with any of the following features, designating the request as a first request, the method further comprising: receiving a second request initiated from an account of a service provider associated with a blockchain-based application, wherein the second request is for processing the first request, the second request including an identity associated with the service provider; and determining the service provider as a registered service provider for the blockchain-based application based on a match between the identity associated with the service provider and an identity contained in the service provider's registration information recorded on the blockchain. A second feature, which may be combined with any of the preceding or following features, designates the user and service provider to perform multiple steps. A third feature, which may be combined with any of the preceding or following features, designates that in each of the multiple steps performed by the user, a unique ID is generated based on time and digital content entered by the user on a spreadsheet at that time, wherein the unique ID is embedded in the digital content entered by the user.The fourth feature, which can be combined with any of the preceding or following features, specifies that the unique ID is the first unique ID, and the method further includes: in each of the multiple steps performed by the service provider: generating a second unique ID based on the time of the execution step and the digital content filled in by the service provider on the spreadsheet at that time; and in each of the multiple steps performed by the service provider: embedding the second unique ID into the digital content filled in by the service provider. The fifth feature, which can be combined with any of the preceding or following features, specifies that the visual difference between the content of the spreadsheet and the embedded information is not noticeably visible to the naked eye. The sixth feature, which can be combined with any of the preceding or following features, specifies that the unique ID is generated based on a hash function and / or asymmetric encryption. The seventh feature, which can be combined with any of the preceding or following features, specifies that the embedded unique ID is based on digital watermarking processing performed using one or more of discrete wavelet transform, discrete cosine transform, singular value decomposition, least significant bit, or steganography. The eighth feature, which can be combined with any of the preceding or following features, specifies one or more attributes associated with the digital content, including one or more of the color, size, orientation, shape, and font of the digital content. The ninth feature, which may be combined with any preceding or following feature, specifies that the identity includes at least one of the following: (i) a mobile phone number, (ii) a credit card number, (iii) a user ID associated with an online payment system, (iv) a user ID associated with an online shopping account, (v) a user ID associated with a music streaming or download account, (vi) a user ID associated with a movie streaming or download account, (vii) a user ID associated with a messaging or chat account, (viii) a user ID associated with an online banking account, (ix) a user ID associated with a ride-hailing service, (x) a user ID associated with an online food ordering service, (xi) a social security number, (xii) a driver's license number, (xiii) a passport number, (xiv) a user ID associated with an online gaming service, or (xv) an ID issued by a government entity. This is an example diagram of a module of another device 2100 according to embodiments of this document. Device 2100 may be an example of an embodiment of a blockchain node configured to process court judgments.Device 2100 may correspond to the above embodiment. Device 2100 includes the following: a receiving module 2102, which receives a request associated with an account based on a blockchain application, the request being used to collect a monetary ruling issued in a court order, wherein the request includes an identity associated with the account; a first determining module 2104, which determines that the command is authentic based on a match between the hash value associated with the command recorded on the blockchain; a first recording module 2106, which records a first verified timestamp indicating the time the request was received on the blockchain; a first invocation module 2108, which invocation the trusted computing module to determine the creditor, the debtor, and the amount of the monetary ruling based on parsing the command; and a second determining module. 2110, based on the trusted identity module, and based on the identity and the registration information of the account recorded on the blockchain, determine that the account is associated with the creditor; the second invocation module 2112, invokes the trusted computing module to identify the creditor's payment account and one or more payment accounts of the debtor based on the registration information, wherein the cumulative balance of the debtor's one or more payment accounts is greater than or equal to the amount of the monetary ruling; the third invocation module 2114, invokes the trusted computing module to transfer the amount of the monetary ruling from one or more payment accounts of the debtor to the creditor's payment account; and the second recording module 2116, records a second verified timestamp indicating the time when the amount of the monetary ruling was transferred. In an optional embodiment, device 2100 further includes: a receiving submodule, which, before receiving the first request, receives a second request associated with a second account based on a blockchain application, the second request being for recording a court order, wherein the second request includes an identity associated with the second account; a determining submodule, which, based on a trusted identity module, determines that the second account is associated with the court based on the identity associated with the second account and the registration information of the second account recorded on the blockchain; an invocation submodule, which invokes a trusted computing module to record the order on the blockchain as a hash value of the order; and a recording submodule, which records a third verified timestamp indicating the time when the order was recorded on the blockchain. In an optional embodiment, device 2100 further includes: an invocation submodule, which invokes a trusted computing module to obtain an accumulated monetary amount equal to the amount of the monetary ruling from one or more payment accounts. In an optional embodiment, device 2100 further includes: an invocation submodule, which invokes a trusted computing module to determine a deadline for enforcing the monetary ruling based on parsing the order, wherein the trusted computing module is invoked before the deadline to transfer the amount of the monetary ruling. In an optional embodiment, a trusted computing module is invoked to determine the amount of an alert transfer currency received from a financial institution associated with one or more payment accounts, wherein the alert indicates a withdrawal or transfer request to be initiated from at least one of the one or more payment accounts.Referring again, it can be interpreted as illustrating the internal functional modules and structure of a blockchain execution device. A blockchain execution device can be an example of a blockchain node configured to enforce judgments within a blockchain network. The execution entity can essentially be an electronic device, and this electronic device includes: one or more processors; and one or more computer-readable storage devices configured to store executable instructions of the one or more processors. In some embodiments, the one or more computer-readable storage devices are coupled to one or more processors and have programming instructions stored thereon, which can be executed by the one or more processors to perform algorithms, methods, functions, processes, flows, and programs as described herein. Embodiments of the described subject matter may individually or in combination include one or more features. For example, in a first embodiment, a method for processing a court judgment executed by a blockchain node includes: receiving a request associated with an account on a blockchain-based application, the request being for collecting a monetary ruling issued in a court order, wherein the request includes an identity associated with the account; and a trusted identity module determining the authenticity of the order based on a match between the hash value associated with the order recorded on the blockchain; a trusted time module recording a first verified timestamp on the blockchain indicating the time the request was received; and invoking the trusted computing module to determine the creditor, debtor, and amount of the monetary ruling based on parsing the order. Based on the trusted identity module, and based on the identity and the registration information of the account recorded on the blockchain, the account is determined to be associated with the creditor; the trusted computing module is invoked to identify the creditor's payment account and one or more payment accounts of the debtor based on the registration information, wherein the cumulative balance of the debtor's one or more payment accounts is greater than or equal to the amount of the monetary ruling; the trusted computing module is invoked to transfer the amount of the monetary ruling from the debtor's one or more payment accounts to the creditor's payment account; and the trusted time module records a second verified timestamp indicating the time when the amount of the monetary ruling was transferred. The foregoing and other described embodiments may each optionally include one or more of the following features: a first feature, which may be combined with any of the following features, designating the request as a first request, the account as a first account, and the method further comprising: before receiving the first request, receiving a second request associated with a second account based on a blockchain application, the second request being for recording a court order, wherein the second request includes an identity associated with the second account; determining, based on a trusted identity module, that the second account is associated with a court based on the identity associated with the second account and registration information of the second account recorded on the blockchain; invoking a trusted computing module to record the order on the blockchain as a hash value of the order; and a trusted time module recording a third verified timestamp representing the time the order was recorded on the blockchain.The second feature, which can be combined with any of the preceding or following features, specifies that the method further includes: invoking a trusted computing module to obtain an accumulated monetary amount equal to the amount of the monetary ruling from one or more payment accounts. The third feature, which can be combined with any of the preceding or following features, specifies that the method further includes: invoking a trusted computing module to determine a deadline for enforcing the monetary ruling based on parsing the command, wherein the trusted computing module is invoked to transfer the monetary ruling amount before the deadline. The fourth feature, which can be combined with any of the preceding or following features, specifies that the trusted computing module is invoked to transfer the monetary ruling amount based on receiving an alert from a financial institution associated with the one or more payment accounts, wherein the alert indicates that a withdrawal request or transfer request is initiated from at least one of the one or more payment accounts. The systems, apparatuses, modules, or units shown in the foregoing embodiments can be implemented using computer chips or entities, or can be implemented using products with specific functions. A typical embodiment device is a computer, which can be a personal computer, laptop computer, cellular phone, camera phone, smartphone, personal digital assistant, media player, navigation device, email sending device, game console, tablet computer, wearable device, or any combination of these devices. For embodiments of the function and role of each module in the apparatus, reference can be made to embodiments of the corresponding steps in the preceding method. For simplicity, details are omitted here. Since the apparatus implementation substantially corresponds to the method implementation, reference can be made to the relevant descriptions in the method implementation for related components. The previously described apparatus implementations are merely examples. Modules described as separate parts may or may not be physically separate, and parts 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 modules can be selected based on actual needs to achieve the objectives of the present invention. Those skilled in the art can understand and implement the embodiments of this application without inventive effort. The implementation of the subject matter, actions, and operations described herein can be implemented in digital electronic circuits, tangibly embodied computer software or firmware, computer hardware, including the structures disclosed herein and their structural equivalents, or combinations of one or more of them. The implementation of the subject matter described herein can be implemented as one or more computer programs, for example, one or more computer program instruction modules encoded on a computer program carrier for execution by a data processing device or control of the operation of a data processing device. For example, a computer program carrier may include one or more computer-readable storage media on which instructions are encoded or stored. The carrier can be a tangible, non-transitory computer-readable medium, such as a disk, magneto-optical disk or optical disk, a solid-state drive, random access memory (RAM), read-only memory (ROM), or other types of media.Optionally or additionally, the carrier may be an artificially generated propagation signal, such as a machine-generated electrical signal, optical signal, or electromagnetic signal, which is generated to encode information for transmission to a suitable receiver device for execution by a data processing device. Computer storage media may be, or can be in part, 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 these. Computer storage media are not propagation signals. A computer program, also referred to or described as a program, software, software application, app, module, software module, engine, script, or code, may be written in any form of programming language, including compiled or interpreted languages, or declarative or procedural languages; it may be configured in any form, including as a standalone 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 at one or more locations interconnected by a data communication network. A computer program may, but is not required to, correspond to a file in a file system. Computer programs can be stored as: a portion of a file containing other programs or data, such as one or more scripts stored in a markup language document; a single file dedicated to the program in question; or multiple coordination files, such as multiple files storing one or more modules, subroutines, or code sections. Processors for executing computer programs include, for example, both general-purpose and special-purpose microprocessors, and any one or more processors of any kind of digital computer. Typically, the processor receives instructions for executing the computer program, as well as data from a non-transitory computer-readable medium coupled to the processor. The term "data processing apparatus" includes all kinds of means, devices, and machines for processing data, such as programmable processors, computers, or multiple processors or computers. Data processing apparatuses may include special-purpose logic circuitry such as FPGAs (Field-Programmable Gate Arrays), ASICs (Application-Specific Integrated Circuits), or GPUs (Graphics Processing Units). In addition to hardware, the apparatus may also include code that creates an execution environment for the computer program, such as code constituting processor firmware, a protocol stack, a database management system, an operating system, or a combination of one or more of these. The processing and logic flows described herein can be executed by one or more computers or processors executing one or more computer programs to perform operations by manipulating input data and generating output. Processing and logic flows can also be executed by dedicated logic circuits, such as FPGAs, ASICs, or GPUs, or a combination of dedicated logic circuits and one or more programmed computers. Computers suitable for executing computer programs can be based on general-purpose and / or dedicated microprocessors, or any other type of central processing unit. Typically, the central processing unit receives instructions and data from read-only memory and / or random access memory. The components of a computer may include a central processing unit for executing instructions and one or more storage devices for storing instructions and data.The central processing unit and memory may be supplemented by dedicated logic circuitry or integrated within dedicated logic circuitry. Typically, a computer will also include or be operatively coupled to one or more storage devices to receive data from or transfer data to one or more storage devices. Mass storage devices can be, for example, magnetic disks, magneto-optical disks or optical disks, solid-state drives, or any other type of non-transitory computer-readable media. However, a computer is not required to have such devices. Therefore, a computer can be coupled to one or more local and / or remote mass storage devices, such as one or more memories. For example, a computer may include one or more local memories as components of the computer, or the computer may be coupled to one or more remote memories in a cloud network. Furthermore, a computer may be embedded in another device, such as a mobile phone, a personal digital assistant (PDA), a mobile audio or video player, a game console, a global positioning system (GPS) receiver, or a portable storage device such as a universal serial bus (USB) flash drive, to name just a few. Components can be "coupled" to each other by communicating directly or via one or more intermediaries, such as electrical or optical connections. Components can also be "coupled" to each other if one component is integrated into another. For example, a large-capacity storage component (e.g., an L2 cache component) integrated into the processor is "coupled" to the processor. To provide interaction with a user, embodiments of the subject matter described herein can be implemented or configured to communicate with a computer having: a display device, such as an LCD (liquid crystal display) monitor, for displaying information to a user; and an input device through which the user can provide input to the computer, such as a keyboard and a pointing device such as a mouse, trackball, or touchpad. Other types of devices can also be used to provide interaction with the 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 can receive input from the user in any form, including sound, voice input, or tactile input. Furthermore, the computer can interact with the user by sending documents to and receiving documents from the device used by the user; for example, by sending web pages to a web browser on the user's device in response to a request received from the web browser, or by interacting with an application (app) running on the user's device, such as a smartphone or tablet computer. Furthermore, a computer can interact with a user by sending text messages or other forms of messages in turn to a personal device (e.g., a smartphone running a messaging application) and receiving response messages from the user. This document uses the term "configured as" in relation to systems, devices, and computer program components.For a system of one or more computers configured to perform a specific operation or action, this means that the system has software, firmware, hardware, or a combination thereof installed thereon that causes the system to perform the operation or action during operation. For one or more computer programs configured to perform a specific operation or action, this means that the one or more programs include instructions that, when executed by a data processing device, cause that device to perform the operation or action. For a dedicated logic circuit configured to perform a specific operation or action, this means that the circuit has electronic logic for performing the operation or action. While this document contains numerous specific implementation details, these details should not be construed as limiting the scope of the claims as defined by the claims themselves, but rather as descriptions of specific features of particular embodiments. Multiple features described in the context of a single embodiment herein may also be implemented in combination in a single embodiment. Conversely, various features described in the context of a single implementation may also be implemented individually or in any suitable sub-combination in multiple embodiments. Furthermore, although the features above may be described as operating in certain combinations and even initially claimed in this way, in some cases one or more features of that combination may be removed from the claimed combination, and claims may be made pointing to sub-combinations or variations thereof. Similarly, although the operations are depicted in a specific order in the drawings and recited in the claims, this should not be construed as requiring the operations to be performed in the specific order or sequentially shown, or requiring all of the shown operations to be performed, in order to achieve the desired result. In some cases, multitasking and parallel processing may be advantageous. Furthermore, the division of various system modules and components in the above embodiments should not be construed as requiring such division in all embodiments, but rather 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 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 the desired result. As an example, the processes depicted in the drawings do not require the specific order or sequence shown to achieve the desired result. In some cases, multitasking and parallel processing may be advantageous. < / form>

Claims

1. A blockchain-based verification system, comprising: An application layer comprising at least one blockchain-based application configured to perform multiple steps to provide a service; as well as The trusted service layer includes a trusted time module, a trusted identity module, and a trusted computing module; Wherein, for each of at least some of the plurality of steps, The application is configured to, based on the processing of blockchain data using the trusted computing module, perform at least one of the following: obtain a verified timestamp from the trusted time module, obtain a verified identity from the trusted identity module, or obtain a calculation result from the trusted computing module, and The trusted computing module is configured to record in the blockchain information related to the corresponding steps performed by the application, as well as at least one of the verified timestamp, the verified identity, or the computing result; The blockchain-based application provides a shopping service that allows users to search for information related to products offered by sellers and to place orders for those products. The application is configured to invoke the trusted identity module to verify the user's identity and the seller's identity, and to invoke the trusted time module to verify the time when the user placed the order; The blockchain-based application is configured to invoke the trusted computing module to update the blockchain, thereby including data representing: information displayed to the user after the user initiates checkout processing, and each piece of information provided by the user to the seller, the user's identity, the seller's identity, and the time the order was placed.

2. The system according to claim 1, wherein, The trusted computing module is configured to, in response to a request for verification records associated with the service, provide verification records of the plurality of steps performed by the application, and at least one of the verified timestamp, the verified identity, or the computation result associated with each of the plurality of steps.

3. The system according to claim 1, wherein, The trusted computing module includes one or more data processors with a Trusted Execution Environment (TEE). The TEE is isolated from the operating system of the one or more data processors and is configured to provide enhanced confidentiality and integrity for the code executed and the data loaded in the one or more data processors.

4. The system according to claim 3, wherein, The blockchain-based applications include: A trusted component is configured to execute and record the plurality of steps performed by the application in the trusted execution environment, and at least one of the verified timestamp, the verified identity, or the calculation result associated with each of the plurality of steps.

5. The system according to claim 4, wherein, The trusted component includes: A hash calculation component is configured to generate hash values ​​representing data performed by the application based on a hash algorithm.

6. The system according to claim 1, wherein, The blockchain-based application is configured to invoke the functions of the trusted time module, the trusted identity module, or the trusted computing module through the corresponding application programming interface (API) associated with the trusted time module, the trusted identity module, or the trusted computing module.

7. The system according to claim 1, wherein, The trusted time module is configured to generate timestamps based on (i) national standard time information and / or (ii) time information obtained from the Global Positioning System.

8. The system according to claim 1, wherein, The trusted time module is configured as follows: A timestamp associated with the first user is generated using the first standard time recognized by the first court system associated with the first user, and The timestamp associated with the second user is generated using a second standard time recognized by the second court system associated with the second user. The first user and the second user reside in different areas with different court systems.

9. The system according to claim 1, wherein, The trusted identity module is configured to verify the user's identity based on one or more identifiers associated with the user, the identifiers including at least one of the following: (i) mobile phone number, (ii) Credit card number, (iii) User ID associated with the online payment system, (iv) User ID associated with the online shopping account, (v) User ID associated with a music streaming or downloading account, (vi) User ID associated with the movie streaming or download account, (vii) User ID associated with the messaging or chat account, (viii) User ID associated with an online banking account, (ix) User ID associated with the ride-hailing service, (x) User ID associated with the online food ordering service, (xi) Social Insurance Number (xii) Driver's license number, (xiii) Passport number, (xiv) User IDs associated with online game services (xv) IDs issued by government entities, (xvi) One or more fingerprints, (xvii) One or more voiceprints, or (xviii) Iris information.

10. The system according to claim 1, wherein, The trusted identity module is configured as follows: The identity of the first user is verified using at least one of the first set of identifiers recognized by the first court system associated with the first user, and The identity of the second user is verified using at least one of the second set of identifiers recognized by the second court system associated with the second user. The first user and the second user reside in different areas with different court systems.

11. The system according to claim 1, wherein, The trusted computing module is configured to record information associated with the user in accordance with privacy laws.

12. The system according to claim 1, wherein, The blockchain-based application is configured to invoke the trusted computing module to update the blockchain, and The blockchain is configured to include data representing the user's online activities associated with the order for the product.

13. The system according to claim 12, wherein, The information displayed to the user after the user initiates the checkout process includes: a description of the ordered product, the price of the product, the seller's identifier, the name of the entity receiving the product, the delivery address, and a message requesting the user to confirm the order.

14. A blockchain-based verification method, comprising: Services are delivered to users in multiple steps on a trusted blockchain-based platform. For each of the plurality of steps, perform at least one of the following: A verified timestamp is obtained from the trusted time module of the trusted platform; a verified identity is obtained from the trusted identity module of the trusted platform; or a calculation result is obtained from the trusted computing module of the trusted platform. as well as Record in the blockchain the data associated with the service provided to the user, and at least one of the verified timestamp, the verified identity, or the calculation result associated with the step; The blockchain-based application provides a shopping service that allows users to search for information related to products offered by sellers and to place orders for those products. The application is configured to invoke the trusted identity module to verify the user's identity and the seller's identity, and to invoke the trusted time module to verify the time when the user placed the order; The blockchain-based application is configured to invoke the trusted computing module to update the blockchain, thereby including data representing: information displayed to the user after the user initiates checkout processing, and each piece of information provided by the user to the seller, the user's identity, the seller's identity, and the time the order was placed.

15. The method of claim 14, comprising: In response to a request for verification records associated with the service, verification records of the plurality of steps performed by the application are provided, along with at least one of the verified timestamp, the verified identity, or the calculation result associated with each of the plurality of steps.

16. The method of claim 14, comprising: The trusted computing module utilizes one or more data processors with a Trusted Execution Environment (TEE) to process the blockchain data. The TEE is isolated from the operating system of the one or more data processors and is configured to provide enhanced confidentiality and integrity for the code executed and the data loaded in the one or more data processors.

17. The method of claim 16, comprising: The trusted components associated with providing the service are executed in the trusted execution environment, and the multiple steps of the service provided to the user are recorded in the blockchain, along with at least one of the verified timestamp, the verified identity, or the calculation result associated with each of the multiple steps.

18. The method according to claim 17, wherein, Executing the trusted component includes: calculating a hash value of the data associated with the step of providing the service to the user based on a hash algorithm.

19. The method of claim 14, comprising: The blockchain-based application of the trusted platform is configured to invoke the functions of the trusted time module, the trusted identity module, or the trusted computing module through the corresponding application programming interface (API) associated with the trusted time module, the trusted identity module, or the trusted computing module.

20. The method of claim 14, comprising: At the trusted time module, a timestamp is generated based on (i) national standard time information and / or (ii) time information obtained from the Global Positioning System.

21. The method of claim 14, comprising: At the trusted time module, a timestamp associated with the first user is generated using a first standard time recognized by a first court system associated with the first user, and a timestamp associated with the second user is generated using a second standard time recognized by a second court system associated with the second user, wherein the first user and the second user reside in different areas with different court systems.

22. The method of claim 14, comprising: At the trusted identity module, the user's identity is verified based on one or more identifiers associated with the user, the identifiers including at least one of the following: (i) mobile phone number, (ii) Credit card number, (iii) User ID associated with the online payment system, (iv) User ID associated with the online shopping account, (v) User ID associated with a music streaming or downloading account, (vi) User ID associated with the movie streaming or download account, (vii) User ID associated with the messaging or chat account, (viii) User ID associated with an online banking account, (ix) User ID associated with the ride-hailing service, (x) User ID associated with the online food ordering service, (xi) Social Insurance Number (xii) Driver's license number, (xiii) Passport number, (xiv) User IDs associated with online game services (xv) IDs issued by government entities, (xvi) One or more fingerprints, (xvii) One or more voiceprints, or (xviii) Iris information.

23. The method of claim 14, comprising: At the trusted identity module, the identity of the first user is verified using at least one of a first set of identifiers recognized by a first court system associated with the first user, and the identity of the second user is verified using at least one of a second set of identifiers recognized by a second court system associated with the second user, wherein the first user and the second user reside in different areas with different court systems.

24. The method of claim 14, comprising: At the trusted computing module, information associated with the user is recorded in accordance with privacy laws.

25. The method of claim 14, comprising: The trusted computing module is invoked to update the blockchain, which is configured to include data representing the user's online activities associated with the order for the product.

26. The method according to claim 14, wherein, The information displayed to the user after the user initiates the checkout process includes: a description of the ordered product, the price of the product, the seller's identifier, the name of the entity receiving the product, the delivery address, and a message requesting the user to confirm the order.

27. An apparatus for providing a service, the apparatus comprising a plurality of modules for performing the method of any one of claims 14 to 26.

Images