A blockchain-based ticket management method and related device

Abstract

The application discloses a kind of based on blockchain's bill management method and related equipment, the method includes: obtaining electronic ticket issuing request;Electronic ticket issuing request contains the service provider identity information of bill service provider;According to electronic ticket issuing request, call the authorized service provider set in electronic ticket contract to service provider identity information is authenticated, and obtain authentication result;If the result of authentication result is ticket issuing authority result, then generate electronic ticket through electronic ticket contract;Through electronic ticket contract, obtain the first user information with the holding right of electronic ticket, generate first bill flow track according to first user information, first user information, first bill flow track and the bill basic information in electronic ticket are stored in the bill token in the electronic ticket container.The unique ownership state of electronic ticket can be recorded by the application, and the use safety of electronic ticket is improved.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a blockchain-based ticket management method and related equipment. Background Technology

[0002] Electronic invoices are electronic payment vouchers issued by the tax system in the purchase and sale of goods, the provision or receipt of services, and other business activities. These vouchers use a nationally unified code and employ standardized anti-counterfeiting technology. Compared to traditional paper invoices, online invoice management systems allow for online invoicing, saving on invoice production costs, tax control machine costs, and related labor costs.

[0003] Traditional e-invoice solutions typically employ a centralized database combined with digital signatures to ensure the security and lifecycle of e-invoices. However, it is difficult for multiple parties to verify and identify the actual ownership status of e-invoices. In the absence of certainty about the actual ownership status of e-invoices, it is often difficult to guarantee the security of their use. Summary of the Invention

[0004] This application provides a blockchain-based bill management method and related equipment, which can record the unique ownership status of electronic bills and improve the security of electronic bill usage.

[0005] This application provides a blockchain-based invoice management method, including:

[0006] Obtain an electronic invoice issuance request; the electronic invoice issuance request includes the service provider's identity information;

[0007] Based on the electronic invoice issuance request, the authorized service provider set in the electronic invoice contract is invoked to authenticate the service provider's identity information and obtain the authentication result;

[0008] If the authentication result indicates that the holder has the authority to issue bills, then an electronic bill is generated through the electronic bill contract.

[0009] The system obtains the first user information with the right to hold electronic bills through the electronic bill contract, generates the first bill circulation trajectory based on the first user information, and stores the first user information, the first bill circulation trajectory, and the basic bill information in the electronic bill into the bill token in the electronic bill container; the bill token refers to the bill storage address in the electronic bill container that corresponds to the electronic bill identifier of the electronic bill; the electronic bill container is located in the electronic bill contract.

[0010] One embodiment of this application provides a blockchain-based invoice management device, comprising:

[0011] The first request acquisition module is used to acquire electronic invoice issuance requests; the electronic invoice issuance request includes the service provider's identity information.

[0012] The authentication processing module is used to call the set of authorized service providers in the electronic invoice contract to authenticate the service provider's identity information based on the electronic invoice issuance request, and obtain the authentication result.

[0013] The bill generation module is used to generate electronic bills through electronic bill contracts if the authentication result indicates that the user has the authority to issue bills.

[0014] The information acquisition module is used to acquire the first user information who has the right to hold electronic bills through the electronic bill contract;

[0015] The trajectory generation module is used to generate the first ticket circulation trajectory based on the first user information.

[0016] The storage module is used to store the first user information, the first bill circulation trajectory, and the basic bill information in the electronic bill into the bill token in the electronic bill container; the bill token refers to the bill storage address in the electronic bill container that corresponds to the electronic bill identifier of the electronic bill; the electronic bill container is located in the electronic bill contract.

[0017] The authentication processing module includes:

[0018] The invocation unit is used to invoke the set of authorized service providers in the electronic invoice contract according to the electronic invoice issuance request; the set of authorized service providers includes the legal identity information of at least two authorized service providers;

[0019] Traverse the authentication unit, which is used to traverse the set of authorized service providers based on the service provider's identity information;

[0020] The traversal of authentication units is also used to determine the authentication result as having the authority to issue invoices if a legitimate identity information identical to the service provider's identity information is found in the set of authorized service providers.

[0021] The information acquisition module includes:

[0022] The request processing unit is used to obtain a ticket holding request for an electronic ticket sent by the terminal device corresponding to the first user information;

[0023] The request processing unit is also used to invoke the electronic bill contract based on the bill holding request;

[0024] The permission allocation unit is used to allocate holding permissions for the electronic bill to the first user information carried in the electronic bill holding request through the electronic bill contract, thereby obtaining the first user information with holding permissions for the electronic bill.

[0025] The bill holding request also carries the first user information and the first signature data for the electronic bill;

[0026] The permission allocation unit includes:

[0027] The consensus subunit is used to initiate consensus processing on the electronic bill and the first signature data to the consensus network through the electronic bill contract, and obtain the first consensus result; the consensus network is used to write the association between the electronic bill and the first user information into the blockchain ledger when the first consensus result is a consensus pass result;

[0028] The permission determination subunit is used to determine, when the association between the electronic ticket and the first user information is written into the blockchain ledger, whether the first user information carried in the ticket holding request has the right to hold the electronic ticket.

[0029] The basic information of the bill includes the electronic bill identifier and the electronic bill face information; the bill token includes the token identifier field, the bill owner field, the face information field, and the bill circulation field.

[0030] Storage module, including:

[0031] The extraction unit is used to extract the electronic bill identifier and electronic bill information from the electronic bill through the bill container function in the electronic bill contract;

[0032] The storage unit is used to store the electronic ticket identifier in the token identifier field, the first user information in the ticket owner field, the electronic ticket face information in the ticket face information field, and the first ticket circulation trajectory in the ticket circulation field.

[0033] The aforementioned document management device also includes:

[0034] The second request acquisition module is used to acquire the electronic ticket transfer request sent by the terminal device corresponding to the transfer request user information; the electronic ticket transfer request includes the second user information, the transfer request user information, and the electronic ticket;

[0035] The first token invocation module is used to invoke the bill token corresponding to the electronic bill in the electronic bill contract according to the electronic bill transfer request.

[0036] The first information reading module is used to read the first user information stored in the ticket owner field of the ticket token;

[0037] The first permission transfer module is used to transfer the electronic bill holding rights of the first user information to the second user information through an electronic bill contract if the user information requesting the transfer is the same as the first user information.

[0038] The first token update module is used to update the ticket token based on the first user information, the second user information, and the electronic ticket.

[0039] The first token update module includes:

[0040] The first trajectory generation unit is used to generate a second ticket circulation trajectory based on the first user information and the second user information.

[0041] The first update unit is used to replace the first user information stored in the ticket owner field of the ticket token with the second user information;

[0042] The first update unit is also used to add the second bill transfer track to the bill transfer field of the bill token.

[0043] The aforementioned document management device also includes:

[0044] The third request acquisition module is used to acquire the electronic invoice reimbursement request sent by the terminal device corresponding to the reimbursement request user information; the electronic invoice reimbursement request includes reimbursement company information, reimbursement request user information, and electronic invoice;

[0045] The second token invocation module is used to invoke the token corresponding to the electronic invoice in the electronic invoice contract according to the electronic invoice reimbursement request.

[0046] The second information reading module is used to read the first user information stored in the ticket owner field of the ticket token;

[0047] The second permission transfer module is used to transfer the electronic bill holding rights of the first user information to the reimbursement company information through an electronic bill contract if the user information requesting reimbursement is the same as the first user information and there is no bill reimbursement identifier in the bill transfer field of the bill token.

[0048] The second token update module is used to generate a reimbursement identifier and update the invoice token based on the reimbursement identifier, the first user information, the reimbursement company information, and the electronic invoice.

[0049] The second token update module includes:

[0050] The second trajectory generation unit is used to generate a third invoice circulation trajectory based on the first user information and the reimbursement company information.

[0051] The reimbursement identifier generation unit is used to generate a reimbursement identifier for the first user information.

[0052] The second update unit is used to replace the first user information stored in the ticket owner field of the ticket token with the reimbursement company information.

[0053] The second update unit is also used to add the third invoice circulation trajectory and invoice reimbursement identifier to the invoice circulation field of the invoice token.

[0054] The aforementioned document management device also includes:

[0055] The log writing module is used to call the log function in the electronic bill contract to query the bill generation behavior information and bill storage behavior information in response to the electronic bill issuance request;

[0056] The log writing module is also used to write information about bill generation and storage behavior into the operation log of the electronic bill contract.

[0057] The aforementioned document management device also includes:

[0058] The service provider addition module is used to receive service provider addition requests; the service provider addition request includes the identity information of the bill service provider and the identity information of the bill administration bureau;

[0059] The service provider addition module is also used to call the legitimate authority in the electronic bill contract to verify the identity of the bill authority based on the service provider addition request, and obtain the verification result;

[0060] The service provider addition module is also used to add the identity information of the bill service provider to the set of authorized service providers in the electronic bill contract if the verification result is a successful verification result.

[0061] One embodiment of this application provides a computer device, including: a processor and a memory;

[0062] The processor is connected to a memory, which stores a computer program. When the computer program is executed by the processor, it causes the computer device to perform the method provided in the embodiments of this application.

[0063] One aspect of this application provides a computer-readable storage medium storing a computer program adapted to be loaded and executed by a processor, so that a computer device having the processor performs the method provided in this application.

[0064] One embodiment of this application provides a computer program product or computer program, which includes computer instructions stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the computer device to perform the method provided in this application embodiment.

[0065] In this embodiment, after obtaining an electronic bill issuance request containing the service provider's identity information, the authorized service provider set in the electronic bill contract can be invoked to authenticate the service provider's identity information, obtaining an authentication result. If the authentication result indicates that the service provider has the authority to issue the bill, an electronic bill is generated through the electronic bill contract. Then, the first user information with the right to hold the electronic bill is obtained through the electronic bill contract. A first bill transfer trajectory is generated based on the service provider's identity information and the first user information. The first user information, the first bill transfer trajectory, and the basic bill information in the electronic bill are stored in a bill token in the electronic bill container. Here, the bill token refers to the bill storage address in the electronic bill container corresponding to the electronic bill identifier of the electronic bill. The electronic bill container is located in the electronic bill contract. Using the method provided in this embodiment, the bill transfer status corresponding to the electronic bill and the first user information with the right to hold the electronic bill can be viewed at any time by invoking the bill token in the electronic bill container corresponding to the electronic bill identifier of the electronic bill. This allows for recording the unique ownership status of the electronic bill and improves the security of using the electronic bill. Attached Figure Description

[0066] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0067] Figure 1 This is a schematic diagram of a network architecture provided in an embodiment of this application;

[0068] Figures 2a-2b This is a schematic diagram illustrating a scenario for invoice management provided in an embodiment of this application;

[0069] Figure 3 This is a flowchart illustrating a blockchain-based invoice management method provided in an embodiment of this application.

[0070] Figure 4 This is a schematic diagram illustrating a scenario of allocating bill holding rights according to an embodiment of this application;

[0071] Figure 5 This is a schematic diagram of an electronic bill contract provided in an embodiment of this application;

[0072] Figure 6 This is a flowchart illustrating an electronic invoice circulation method provided in an embodiment of this application;

[0073] Figure 7This is a flowchart illustrating an electronic invoice reimbursement method provided in an embodiment of this application;

[0074] Figure 8 This is a schematic diagram of the structure of a blockchain-based ticket management device provided in an embodiment of this application;

[0075] Figure 9 This is a schematic diagram of the structure of a computer device provided in an embodiment of this application. Detailed Implementation

[0076] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of this application.

[0077] Please see Figure 1 , Figure 1 This is a schematic diagram of a network architecture provided in an embodiment of this application. Blockchain is a novel application model of computer technologies such as distributed data storage, peer-to-peer transmission, consensus mechanisms, and encryption algorithms. It is mainly used to organize data in chronological order and encrypt it into a ledger, making it tamper-proof and forgery-proof. It also allows for data verification, storage, and updating. Essentially, a blockchain is a decentralized database where each node stores the same blockchain. The blockchain network can distinguish nodes into consensus nodes and business nodes, with the consensus node responsible for achieving consensus across the entire blockchain network. The process of writing transaction data into the ledger in a blockchain network can be as follows: the client sends transaction data to a business node, which then relays the transaction data among the business nodes in the blockchain network until the consensus node receives it. The consensus node then packages the transaction data into a block and reaches a consensus with other consensus nodes. After the consensus is passed, the block carrying the transaction data is written into the ledger.

[0078] In this context, it can be understood that a block is a data packet that carries transaction data (i.e., transaction business) on a blockchain network. It is a data structure that is marked with a timestamp and the hash value of the previous block. The transactions in the block are verified and confirmed by the network's consensus mechanism.

[0079] It is understood that a blockchain system can include smart contracts. A smart contract can be understood and executed by all nodes in the blockchain (including consensus nodes), capable of executing arbitrary logic and producing results. Users can initiate a transaction request through a client, invoking a smart contract already deployed on the blockchain. Subsequently, the transaction nodes on the blockchain can send the request to the consensus nodes, which can then run the smart contract. It should be understood that a blockchain can include one or more smart contracts, distinguished by an identity document (ID) or name. The client's transaction request can also carry the smart contract's identity document or name, specifying the smart contract the blockchain needs to run. If the smart contract specified by the client requires data retrieval, each consensus node will access its local ledger to read the data. Finally, the consensus nodes will verify the consistency of the execution results (i.e., reach consensus). If they are consistent, the execution result can be stored in their respective local ledgers and returned to the client.

[0080] like Figure 1 As shown, the network architecture may include a consensus node cluster 1000, a service node cluster 100, and a terminal device (client) cluster 10. The consensus node cluster 1000 may include at least two consensus nodes, and the service node cluster 100 may include at least two service nodes. Figure 1 As shown, the consensus node cluster 1000 may include consensus node 1000a, consensus node 1000b, ..., consensus node 1000n; the service node cluster 100 may specifically include service node 100a, service node 100b, ..., service node 100n; and the terminal device cluster 10 may specifically include terminal device 10a, terminal device 10b, ..., terminal device 10n.

[0081] like Figure 1As shown, terminal devices 10a, 10b, ..., 10n can respectively connect to service nodes 100a, 100b, ..., 100n via the network, so that the terminal devices can interact with the service nodes through the network connection; service nodes 100a, 100b, ..., 100n can respectively connect to consensus nodes 1000a, 1000b, ..., 1000n via the network, so that the service nodes can interact with the consensus nodes through the network connection; service nodes 100a, 100b, ..., 100n are interconnected to enable data interaction between the service nodes; consensus nodes 1000a, 1000b, ..., 1000n are interconnected to enable data interaction between the consensus nodes.

[0082] It is understandable that the various nodes in the aforementioned blockchain (which can be business nodes or consensus nodes) can transmit data or blocks through the data connections described above. The blockchain network can achieve data connections between nodes based on node identifiers. Each node in the blockchain network has a corresponding node identifier, and each node can store the node identifiers of other nodes connected to it, so that subsequently, based on the node identifiers of other nodes, the acquired data or generated blocks can be broadcast to other nodes. The node identifier can be an Internet Protocol (IP) address or any other information that can be used to identify nodes in the blockchain network.

[0083] It is understood that the above data connection is not limited to the connection method. It can be connected directly or indirectly through wired communication, or directly or indirectly through wireless communication, or through other connection methods. This application does not impose any restrictions on this.

[0084] It is understood that the data processing method provided in this application embodiment can be executed by a computer device, which includes, but is not limited to, the aforementioned business node and consensus node (which can be a terminal or a server). The aforementioned server can be an independent physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server providing basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, CDN, and big data and artificial intelligence platforms. The aforementioned terminal device can be a smartphone, tablet computer, laptop computer, desktop computer, smart speaker, smartwatch, etc., but is not limited to these.

[0085] like Figure 1As shown, any business node in the business node cluster 100 can receive an electronic invoice issuance request from the terminal device corresponding to the invoice service provider in the terminal device cluster 10. This electronic invoice issuance request includes the service provider's identity information. Then, the business node receiving the electronic invoice issuance request can invoke the authorized service provider in the electronic invoice contract (which belongs to the aforementioned smart contract) to authenticate the service provider's identity information and obtain the authentication result. If the authentication result indicates that the service provider has the authority to issue invoices, an electronic invoice is generated through the electronic invoice contract. Only invoice service providers with the authority to issue invoices can issue electronic invoices; in other words, electronic invoice issuance requests initiated by invoice service providers without the authority to issue invoices are invalid. The process of generating an electronic invoice through an electronic invoice contract can be as follows: A business node can run the electronic invoice contract based on an electronic invoice issuance request to generate an electronic invoice. Then, it sends a consensus request carrying the electronic invoice to a proposal node (which can be any consensus node in the consensus node cluster) within the consensus node cluster of 1000. The proposal node generates a new block based on the electronic invoice. Subsequently, the proposal node can send the newly generated block to other consensus nodes in its blockchain network based on the node identifiers of other consensus nodes in the blockchain network. These other consensus nodes verify the newly generated block (i.e., reach consensus) and, after verification, add the newly generated block to their stored blockchain (that is, the electronic invoice is stored in the blockchain after consensus is reached). It is understood that the generation process of the electronic invoice is only complete when it passes consensus among the consensus nodes in the blockchain network, at which point the electronic invoice is valid. If the electronic invoice fails to pass consensus, it will be deemed invalid by any node in the blockchain network (i.e., whether it is a business node or a consensus handover document).

[0086] It is understood that the methods provided in the embodiments of the present invention can be executed by computer devices, including but not limited to terminals or servers. The service nodes or consensus nodes in the embodiments of the present invention can be computer devices.

[0087] For easier understanding, please refer to Figures 2a-2b , Figures 2a-2b This is a schematic diagram illustrating a scenario for invoice management provided in an embodiment of this application. Wherein, as... Figure 2a The user terminal device 20 corresponding to user A shown can be the one described above. Figure 1 Any terminal device in the terminal device cluster 10 in the corresponding embodiment, such as user terminal device 20, can be terminal device 10a; for example, Figure 2a The merchant terminal device 21 corresponding to the catering merchant B shown can be the one described above. Figure 1Any terminal device in the terminal device cluster 10 in the corresponding embodiment, such as merchant terminal device 21, can be terminal device 10b; for example, Figure 2a The billing service provider C shown above corresponds to the billing terminal device 22, which can be the aforementioned Figure 1 Any terminal device in the terminal device cluster 10 in the corresponding embodiment, such as the invoicing terminal device 22, can be terminal device 10n; for example, Figure 2a The business node 200 shown can be the above Figure 1 Any service node in the service node cluster 100 in the corresponding embodiment, for example, the service node can be service node 100b; for example Figure 2a The consensus node cluster 2000 shown can be the consensus node cluster 1000 mentioned above.

[0088] like Figure 2aAs shown, User A, an employee of Company D, pays 500 yuan online to Restaurant B in the name of Company D through User Terminal Device 20. User A can then apply for an invoice, that is, initiate an electronic invoice issuance transaction through User Terminal Device 20 to Merchant Terminal Device 21 corresponding to Restaurant B (i.e., request Restaurant B to issue an electronic invoice g for 500 yuan to Company D). Merchant Terminal Device 21 will send the identity information of Restaurant B, the identity information of Company D, and the invoice amount information to the invoice service provider C's corresponding invoice issuing terminal device 22 to apply for invoice issuance. Invoice service provider C is an authorized service provider by the tax bureau that can apply for electronic invoices for merchants. Invoice issuing terminal device 22 will generate an electronic invoice issuance request based on the information sent by Merchant Terminal Device 21. This request includes not only the identity information of Restaurant B, the identity information of Company D, and the invoice amount information required for generating the electronic invoice, but also the service provider identity information of invoice service provider C. Then, the invoicing terminal device 22 sends the electronic invoice issuance request to the business node 200. The business node 200 first calls the authorized service provider set in the electronic invoice contract 201 to authenticate the service provider identity information of the invoice service provider C, and obtains the authentication result. The authorized service providers included in the authorized service provider set are all authorized by the tax bureau and can apply for the issuance of electronic invoices for merchants; that is, they are service providers with invoice issuance authority. The business node 200 authenticates the invoice service provider C to determine that it belongs to the authorized service provider set. When the authentication result indicates that bill service provider C has the authority to issue bills, business node 200 will generate electronic bill g based on the identity information of catering merchant B, enterprise D, and invoice amount information contained in the electronic bill issuance request. Then, the consensus request 202 carrying the electronic bill g will be sent to the proposal node in the consensus node cluster 2000, for example, the proposal node is consensus node 2000a. Consensus node 2000a will generate a new block based on the electronic bill g, and then consensus node 2000a will broadcast the new block to consensus nodes 2000b, ..., consensus node 2000n. Consensus nodes 2000b, ..., consensus node 2000n will reach a consensus on the new block. If the consensus is successful, the consensus nodes in the consensus node cluster will add the new block to the stored blockchain. Once a new block is agreed upon by the consensus node cluster 2000, the generation process of electronic bill g is considered complete, meaning that electronic bill g is considered a valid electronic bill. Subsequently, business node 200 can return electronic bill g to the billing terminal device 22 corresponding to billing service provider C.Finally, the invoicing terminal device 22 will issue an electronic bill claim instruction to the user terminal device 20. The user terminal device 20 can generate a bill holding request for the electronic bill g based on the electronic bill claim instruction, so that the business node 200 can allocate the holding rights of the electronic bill g to user A through the bill holding request.

[0089] After business node 200 assigns the holding rights of electronic invoice g to user A, it will also record the basic information of electronic invoice g, its circulation trajectory, and the identity information of the user to which it belongs, to facilitate subsequent management of electronic invoice g. The basic information refers to the information on the electronic invoice g itself, i.e., the information displayed when electronic invoice g is shown, such as the identity information of restaurant B, enterprise D, and invoice amount, etc.; the circulation trajectory refers to the changes in the holding rights of electronic invoice g; and the user to which it belongs refers to the user who currently holds the holding rights of electronic invoice g. Please refer to [link / reference]. Figure 2b ,like Figure 2b As shown, business node 200 first obtains the identity information of the user to whom electronic bill g belongs, i.e., user A's identity information, through electronic bill contract 201. Then, business node 200 generates the bill transfer trajectory of electronic bill g based on user A's identity information. This trajectory records changes in the holding rights of electronic bill g. By default, the initial owner of electronic bill g can be bill service provider C, so the generated transfer trajectory could be "Bill Service Provider C → User A". Then, the business node stores user A's identity information, the transfer trajectory, and the basic bill information in electronic bill g. For example... Figure 2b As shown, business node 200 includes electronic bill contract 201, which in turn includes authorized service provider set 2011 (i.e., the aforementioned...). Figure 2a In addition to the set of authorized service providers mentioned above, it may also include an electronic invoice container 2012. The electronic invoice container 2012 contains multiple invoice tokens. Each invoice token can be used to store the basic information of an electronic invoice, its circulation trajectory, and the identity information of the user to which it belongs. A business node can store user A's identity information, the invoice circulation trajectory, and the basic information of the electronic invoice g into invoice token 20121.

[0090] Further, please see Figure 3 , Figure 3 This is a flowchart illustrating a blockchain-based invoice management method provided in an embodiment of this application. The method can be implemented by business nodes (e.g., the aforementioned...). Figure 1 The execution can be performed by the business node in the corresponding embodiment, or by the business node and the consensus node (e.g., the one mentioned above). Figure 1 The consensus node in the corresponding embodiment), and the terminal device (e.g., the one mentioned above). Figure 1 The method is jointly executed by the terminal devices in the corresponding embodiments. The following description will take the execution of this method by a business node as an example. This blockchain-based ticket management method may include at least the following steps S101-S104:

[0091] Step S101: Obtain an electronic invoice issuance request; the electronic invoice issuance request includes the service provider identity information of the invoice service provider.

[0092] Specifically, electronic invoices, also known as electronic receipts, are electronic payment vouchers issued by the tax system in the purchase and sale of goods, provision or receipt of services, and other business activities. These vouchers use a nationally unified coding system and employ unified anti-counterfeiting technology. Compared to traditional paper invoices, the online invoice management system allows for online invoicing, saving on invoice production costs, tax control machine costs, and related labor costs. Invoice service providers, also known as invoice issuance service providers, are authorized by the tax bureau and are third-party service platforms that can assist merchants in applying for electronic invoices. A single invoice service provider can cooperate with multiple merchants, meaning it can receive invoice requests from multiple merchants and then generate electronic invoice issuance requests accordingly. For the security of the entire tax system, electronic invoices cannot be generated from terminal devices of invoice service providers not authorized by the tax bureau. Therefore, in addition to the basic information required for generating electronic invoices (such as the merchant's identity information, the identity information of the consuming enterprise or individual, and the invoice amount), electronic invoice issuance requests must also include the invoice service provider's identity information.

[0093] Step S102: Based on the electronic invoice issuance request, the authorized service provider set in the electronic invoice contract is invoked to authenticate the service provider's identity information and obtain the authentication result.

[0094] Specifically, after receiving an electronic invoice issuance request, the business node extracts the service provider's identity information from the request. Then, the business node invokes the set of authorized service providers in the electronic invoice contract based on the request. This set includes the legal identity information of at least two authorized service providers, each of which is a legitimate invoice service provider authorized by the tax authorities. The business node then iterates through the set of authorized service providers based on their identity information. If a legitimate identity matching the service provider's identity information is found, the authentication result confirms that the business node has the authority to issue invoices. For ease of understanding, assume that the service provider's identity information is the service provider identification code, and the authorized service provider set stores the legal identification codes corresponding to the authorized service providers. The authorized service provider set 1 includes {xbz165, wqp132, qpz901}, where xbz165, wqb132, and qpz901 each correspond to a legal identification code of an authorized service provider. The service provider identification code of the bill service provider 2 extracted by the business node from the electronic bill issuance request is xyz468. Subsequently, the business node will traverse the authorized service provider set 1 to search for identification codes that are the same as xyz468. After the traversal is completed, there is no identification code in the authorized service provider set 1 that is the same as xyz468. The business node will determine that the bill service provider 2 does not have the authority to issue bills, that is, the authentication result is that the bill service provider does not have the authority to issue bills. It is understandable that if the same identification code as xyz468 is found in the authorized service provider set 1, the business node will determine that the invoice service provider 2 has the authority to issue invoices, that is, the authentication result is that the invoice service provider has the authority to issue invoices.

[0095] Optionally, the business node can receive a service provider addition request, which includes the identity information of the bill service provider and the identity information of the bill administration bureau. Then, the business node can invoke the legitimate administration bureau in the electronic bill contract to verify the identity of the bill administration bureau based on the service provider addition request, and obtain the verification result. If the verification result is successful, the business node adds the identity information of the bill service provider to the set of authorized service providers in the electronic bill contract.

[0096] Step S103: If the authentication result indicates that the holder has the authority to issue bills, then an electronic bill is generated through the electronic bill contract.

[0097] Specifically, in a feasible embodiment, the process of a business node generating an electronic bill through an electronic bill contract can be as follows: the business node can run the electronic bill contract according to the electronic bill issuance request, generate an electronic bill through the bill generation function in the electronic bill contract, and then the business node can send a consensus request carrying the electronic bill to the proposal node (which can be the aforementioned) in the consensus node cluster. Figure 1Any consensus node in the consensus node cluster 1000 generates a bill verification block containing the electronic bill based on the electronic bill. Subsequently, the proposal node, based on the node identifiers of other consensus nodes in the blockchain network, sends the newly generated bill verification block to other consensus nodes in its blockchain network. These other consensus nodes then reach a consensus on the newly generated bill verification block and, upon successful consensus, add it to their stored blockchain (that is, store the electronic bill in the blockchain after successful consensus). Consensus on a bill verification block by a consensus node means that the node verifies the block; if the block is deemed valid, it casts a vote of approval; otherwise, it casts a vote of disapproval. When the number of consensus nodes casting votes of approval for the bill verification block exceeds the consensus threshold, the consensus on the bill verification block is considered successful. Understandably, the generation process of an electronic ticket is only complete when it passes consensus among the consensus nodes in the blockchain network, at which point the electronic ticket becomes valid. If the electronic ticket fails to pass consensus, it will be deemed invalid by any node in the blockchain network (i.e., whether it is a business node or a consensus handover form).

[0098] Specifically, in a feasible embodiment, the process of a business node generating an electronic invoice through an electronic invoice contract can be as follows: The business node can initiate an invoice generation business request to invoke an electronic invoice contract already deployed on the blockchain. This request can carry basic information required to generate the electronic invoice, such as the merchant's identity information, the identity information of the consuming enterprise or individual, and the invoice amount. The request can also carry the identifier or name of the electronic invoice contract to be invoked (specifying the invoice generation function of the electronic invoice contract that the blockchain needs to run). The business node sends this invoice generation business request to the proposal node in the consensus node cluster. The proposal node packages the request into an invoice generation block and broadcasts it to other consensus nodes. The remaining consensus nodes reach a consensus on this block, i.e., they each invoke the invoice generation function of the electronic invoice contract based on the identifier or name of the invoice contract contained in the block to generate the electronic invoice. Each node then verifies the generated electronic invoice; if verification is successful, a vote of approval is cast; if verification fails, a vote of disapproval is cast. When the number of consensus nodes voting in favor of a block verifying a ticket exceeds the consensus threshold, the consensus for that ticket generation block is considered passed. Consensus nodes then add the newly generated ticket generation block to their stored blockchain and write the generated electronic ticket into the ledger. Business nodes can synchronize the ledger data to obtain valid electronic tickets.

[0099] Step S104: Obtain first user information with holding rights to the electronic bill through the electronic bill contract; generate a first bill transfer trajectory based on the first user information; and store the first user information, the first bill transfer trajectory, and the basic bill information in the electronic bill into the bill token in the electronic bill container.

[0100] Specifically, the process by which a business node obtains the first user information with holding rights to an electronic ticket through an electronic ticket contract can be as follows: It receives a ticket holding request for the electronic ticket sent by the terminal device corresponding to the first user information; it invokes the electronic ticket contract based on the ticket holding request; and through the electronic ticket contract, it assigns holding rights to the electronic ticket to the first user information carried in the ticket holding request, thus obtaining the first user information with holding rights to the electronic ticket. Optionally, the ticket holding request also carries the first signature data of the first user information for the electronic ticket, i.e., the signature data obtained after digitally signing the basic information of the electronic ticket using the private key corresponding to the first user information. The basic information can be the electronic ticket identifier of the electronic ticket. In this case, the process of assigning holding rights to the electronic ticket to the first user information carried in the ticket holding request through the electronic ticket contract, thus obtaining the first user information with holding rights to the electronic ticket, can be as follows: It initiates consensus processing on the electronic ticket and the first signature data to the consensus network through the electronic ticket contract, thus obtaining the first consensus result. When the first consensus result is a consensus pass, the consensus network can write the association between the electronic ticket and the first user information into the blockchain ledger. When the association between the electronic ticket and the first user information is written into the blockchain ledger, the business node can determine that the first user information carried in the ticket holding request has the right to hold the electronic ticket.

[0101] To facilitate understanding of the process of allocating holding rights for electronic tickets, the above... Figure 2a The following example illustrates how business node 200 assigns the holding rights of electronic ticket g to user A. Please refer to [link / reference needed]. Figure 4 , Figure 4 This is a schematic diagram illustrating a scenario of allocating bill holding rights according to an embodiment of this application. For example... Figure 4 As shown, user terminal device 20 corresponding to user A receives an electronic invoice claim instruction sent by the invoicing terminal device (the issuance of the electronic invoice claim instruction can be found above). Figure 2aFollowing the description of the corresponding embodiment, user A completes the claim operation according to the electronic ticket claim interface corresponding to the electronic ticket claim instruction. Subsequently, user terminal device 20 responds to the claim operation and generates a ticket holding request 23. The electronic ticket claim instruction carries the electronic ticket identifier of electronic ticket g, and the ticket holding request 23 carries user A's identity information and signature data obtained by signing the electronic ticket identifier with user A's private key. After receiving the ticket holding request 23, business node 200 initiates consensus processing on the consensus network through electronic ticket contract 201 for the signature data of electronic ticket g and user A, obtaining a consensus result. The consensus processing process is as follows: Figure 4 As shown, business node 200 can generate a consensus request 203 carrying electronic ticket g and user A's signature data to the proposal node in the consensus node cluster 2000. Assuming the current proposal node is consensus node 2000b, consensus node 2000b will generate a ticket holding block containing electronic ticket g and user A's signature data according to the consensus request 203, and then send the ticket holding block to other consensus nodes for consensus voting. When the consensus nodes in the consensus node cluster 2000 reach a consensus on the ticket holding block, the association between electronic ticket g and user A will be written into the blockchain ledger. After business node 200 synchronizes the data in the blockchain ledger, it will determine that user A has the right to hold the electronic ticket, and at the same time, business node 200 will distribute electronic ticket g to user terminal device 20. Optionally, communication between business node 200 and user terminal device 20 can be achieved through data forwarding of invoice terminal device 22. That is, the aforementioned ticket holding request 23 can be sent by user terminal device 20 to invoice terminal device 22, and then forwarded by invoice terminal device 22 to business node 200. This is not restricted.

[0102] Specifically, the electronic invoice container is the storage address within the electronic invoice contract. An electronic invoice container can contain multiple invoice tokens. Each invoice token can store the initial invoice circulation trajectory, initial user information, and basic invoice information for an electronic invoice. The basic invoice information includes the electronic invoice identifier and the invoice's face information. The electronic invoice identifier can include the electronic invoice number and electronic invoice code, i.e., the electronic invoice number and electronic invoice code. A typical electronic invoice code can consist of 12 digits, including the national and local tax codes, administrative region codes, year codes, industry codes, and invoice type codes. These are numbered from left to right as follows: the first digit is the national and local tax code; the second to fifth digits are the administrative region codes; the sixth and seventh digits are the year codes; the eighth digit is the industry code; and the ninth to twelfth digits are the invoice type codes. The electronic invoice number is uniformly assigned by the State Administration for Industry and Commerce, is generally 8 digits, is unique, and is assigned annually and in batches. The information on an electronic invoice can include the identity information of the consumer (such as the company name and tax number of company D mentioned above), the identity information of the issuer (such as the name, product name, or business scope of restaurant B mentioned above), and the face value of the invoice. The first invoice circulation trajectory refers to the change in the holder's rights to the electronic invoice. Assuming an electronic invoice is generated, the default holder is the invoice service provider. When the first user receives the electronic invoice through their corresponding user terminal device, the holder's rights change to the first user. In this case, the first invoice circulation trajectory could be "Invoice Service Provider → First User".

[0103] Specifically, the bill token may include a token identifier field, a bill owner field, a bill face information field, and a bill circulation field. The process of storing the first user information, the first bill circulation trajectory, and the basic bill information in the electronic bill into the bill token in the electronic bill container can be as follows: extract the electronic bill identifier and electronic bill face information from the electronic bill through the bill container function in the electronic bill contract; store the electronic bill identifier in the token identifier field, store the first user information in the bill owner field, store the electronic bill face information in the bill face information field, and store the first bill circulation trajectory in the bill circulation field.

[0104] Using the method provided in this application, after obtaining an electronic bill issuance request containing the service provider's identity information, the authorized service provider set in the electronic bill contract can be invoked to authenticate the service provider's identity information according to the electronic bill issuance request, and an authentication result can be obtained. If the authentication result indicates that the user has the authority to issue the bill, an electronic bill is generated through the electronic bill contract. Then, the first user information with the authority to hold the electronic bill is obtained through the electronic bill contract. A first bill circulation trajectory is generated based on the service provider's identity information and the first user information. The first user information, the first bill circulation trajectory, and the basic bill information in the electronic bill are stored in the bill token in the electronic bill container. The first user information, the first bill circulation trajectory, and the basic bill information in the electronic bill stored in the bill token can be viewed at any time, and the business node can determine the unique ownership status of the electronic bill at any time, thereby preventing users without the authority to hold the electronic bill from operating on it, thus improving the security of electronic bill usage.

[0105] Further, please see Figure 5 , Figure 5 This is a schematic diagram of an electronic bill contract provided in an embodiment of this application. The electronic bill contract can be stored on a business node (e.g., the one described above). Figure 1 The corresponding business node in the embodiment) or consensus node (e.g., the above-mentioned Figure 1 Within the consensus node in the corresponding embodiment, such as Figure 5 The electronic invoice contract 5 shown consists of four main parts: role permissions 51, contract description 52, electronic invoice container 53, and operation log 54.

[0106] like Figure 5 As shown, role permission 51 indicates the creator, administrator, and bill service provider of the electronic bill contract. In a typical electronic bill system, the contract creator and administrator should both be the tax bureau, and the bill service provider refers to a service provider with bill issuance authority. The bill service provider with bill issuance authority is the bill issuance service provider role, usually designated by the service provider (i.e., the tax bureau) acting as the administrator. It is understandable that the legal identity information corresponding to the bill service provider can be stored in the above... Figure 3 The set of bill service providers mentioned in the corresponding embodiments.

[0107] like Figure 5 As shown, Contract Description 52 is used to record the name, type, and total assets of the electronic invoice contract. For example, the contract name is Electronic Invoice, the contract category is Ticketing, and the Ticketing contract does not have a corresponding total asset amount, so the total asset amount is none.

[0108] like Figure 5As shown, the electronic bill container 53 is used to store the actual electronic bill information, including bill tokens 531, 532, 533, ... Taking bill token 533 as an example, the electronic bill information storage is explained. Bill token 533 includes a token identifier (token-id) field 5331, a bill owner (owner) field 5332, a bill information (meta) field 5333, and a bill circulation (data) field 5334. The token identifier field 5331 records the electronic bill identifier, i.e., the bill number and bill code of the electronic bill. It can be understood that each electronic bill can only be issued through a bill service provider and assigned a unique bill number and bill code, because different electronic bills and their corresponding bill tokens can be distinguished by the electronic bill identifier. The bill owner field 5332 records the current electronic bill owner information; in other words, it records the user information currently holding the electronic bill. The bill information field 5333 records the bill information of the electronic bill. Among them, the bill circulation field 5334 is used to record the circulation information of electronic bills. By parsing the bill circulation field 5334, the original creator of the electronic bill and the user identity of each circulation can be quickly found.

[0109] like Figure 5 As shown, operation log 54 is used to record key operations in the electronic bill contract, including the designation of contract role permissions, the creation and circulation of electronic bills, and other change operations, and associates these operations with blockchain transaction identifiers. Optionally, after storing the electronic bill in the bill token, the business node can also call the log function in the electronic bill contract to query the bill generation behavior information and bill storage behavior information for the electronic bill issuance request that generated the electronic bill; then, the bill generation behavior information and bill storage behavior information are written into the operation log in the electronic bill contract.

[0110] The method provided in this application standardizes and regulates electronic bill contracts, thereby making the issuance and operation of electronic bills more standardized. It assigns each electronic bill a unique identifier and value, making it part of digital assets. The electronic bill contract establishes a role-based access control system and a data maintenance method for electronic bills. While meeting the business needs of electronic bill creation and circulation, it enables full lifecycle supervision of electronic bills, ensuring the tracking and maintenance of asset ownership and guaranteeing the uniqueness and security of electronic bill assets.

[0111] Further, please see Figure 6 , Figure 6 This is a flowchart illustrating an electronic invoice circulation method provided in an embodiment of this application. Figure 6As shown, this electronic invoice circulation method can be implemented by business nodes (which can be the aforementioned...) Figure 1 This is executed by any business node in the corresponding embodiment. The following explanation will use the execution of this electronic invoice transfer method by business node 600 as an example. Figure 6 As shown, before the execution of this electronic bill circulation method, the bill token 6001 in business node 600 stores relevant information about the electronic bill identified as electronic bill identifier x. Specifically, the token identifier field stores electronic bill identifier x, the bill owner field stores first user information, the bill information field stores electronic bill information y, and the bill circulation field stores the first bill circulation trajectory, which is "bill circulation merchant → first user". How this relevant information of the electronic bill is stored in the bill token 6001 can be found above. Figure 3 The descriptions in the corresponding embodiments will not be repeated here. Figure 6 As shown, this electronic invoice circulation method may include at least the following steps S61-S65:

[0112] Step S61: Obtain the electronic ticket transfer request sent by the terminal device corresponding to the transfer request user information; the electronic ticket transfer request includes the second user information, the transfer request user information, and the electronic ticket.

[0113] Specifically, the transfer request user information refers to the identity information of the user requesting the transfer, whereby the user requesting the transfer is the user who wants to perform the electronic ticket holding rights transfer operation. For example... Figure 6 As shown, assuming that the user requesting the transfer of the electronic ticket corresponding to the terminal device 60 wants to transfer an electronic ticket identified as electronic ticket identifier x to the second user, the terminal device 60 will obtain the transfer request identity information of the user requesting the transfer, the second identity information of the second user, and the electronic ticket, generate an electronic ticket transfer request, and send it to the business node 600.

[0114] Step S62: Invoke the bill token corresponding to the electronic bill in the electronic bill contract according to the electronic bill transfer request.

[0115] Specifically, after receiving an electronic bill transfer request, business node 600 extracts the electronic bill identifier (i.e., electronic bill identifier x) from the request. Then, business node 600 searches the electronic bill container of the electronic bill contract for a bill token whose identifier is also electronic bill identifier x, and uses this token as the corresponding bill token for that electronic bill. For example... Figure 6 As shown, the ticket token corresponding to this electronic ticket can be ticket token 6001.

[0116] Step S63: Read the first user information stored in the ticket owner field of the ticket token.

[0117] Step S64: If the user information requesting the transfer is the same as the first user information, then the holding rights of the electronic bill held by the first user information are transferred to the second user information through the electronic bill contract.

[0118] Specifically, business node 600 needs to first verify the transfer request user information to determine if the user has the right to hold the electronic ticket carried in the electronic ticket transfer request. Therefore, business node 600 can read the first user information from the ticket owner field of the ticket token 6001 corresponding to the electronic ticket, and then compare the first user information with the transfer request user information. If the first user information and the transfer request user information are the same, the verification of the transfer request user information is successful, and business node 200 can transfer the right to hold the electronic ticket held by the first user information to the second user information through the electronic ticket contract. It is understood that transferring the right to hold the electronic ticket held by the first user information to the second user information requires going through the consensus network (i.e., the aforementioned...). Figure 1 In the consensus processing of the network where the consensus node cluster is located in the corresponding embodiment, once the consensus is passed, the holding rights of the electronic ticket held by the first user information are transferred to the second user information before they are recognized by the various consensus nodes or business nodes in the entire blockchain.

[0119] Step S65: Update the ticket token based on the first user information, the second user information, and the electronic ticket.

[0120] Specifically, the process of updating the bill token based on the first user information, the second user information, and the electronic bill can be as follows: A second bill transfer trajectory is generated based on the first and second user information; the first user information stored in the bill owner field of the bill token is replaced with the second user information; the second bill transfer trajectory is added to the bill transfer field of the bill token. For example... Figure 6 As shown, after the business node updates the bill token 6001, the electronic bill identifier x in the token identifier field and the electronic bill information y in the bill information field of the bill token 6001 remain unchanged. However, the first user information stored in the bill owner field changes to the second user information. The second bill transfer trajectory generated by the business node 600 is "first user → second user". The business node 600 will add this second bill transfer trajectory to the bill transfer field, meaning that the first bill transfer trajectory will still be stored in the bill transfer field and will not be replaced.

[0121] Optionally, business node 600 can call the electronic bill contract to complete the transfer of the electronic bill holding rights held by the first user information to the second user information, as well as the update of the bill token corresponding to the electronic bill. This can also be written into the operation log for later review.

[0122] Using the method provided in this application, the circulation status of electronic tickets can be viewed at any time in the ticket token corresponding to the electronic ticket, avoiding the situation where multiple people own one ticket and improving the security of electronic tickets.

[0123] Further, please see Figure 7 , Figure 7 This is a flowchart illustrating an electronic invoice reimbursement method provided in an embodiment of this application. Figure 6 As shown, this electronic invoice circulation method can be executed by a business node. The following will use this electronic invoice circulation method executed by business node 700 (which can be described above). Figure 6 The following explanation uses the execution of business node 600 in the corresponding embodiment as an example. Figure 6 As shown, before the electronic invoice reimbursement method is executed, the invoice token 7001 in business node 700 stores relevant information about the electronic invoice with electronic invoice identifier x. Specifically, the token identifier field stores electronic invoice identifier x, the invoice owner field stores the first user information, the invoice information field stores the electronic invoice information y, and the invoice circulation field stores the first invoice circulation trajectory, where the first invoice circulation trajectory is "invoice circulation merchant → first user". Figure 7 As shown, this electronic invoice circulation method may include at least the following steps S71-S75:

[0124] S71, Obtain the electronic invoice reimbursement request sent by the terminal device corresponding to the reimbursement request user information; the electronic invoice reimbursement request includes reimbursement company information, the reimbursement request user information, and electronic invoice.

[0125] Specifically, the reimbursement request user information refers to the identity information of the user requesting reimbursement, where the user requesting reimbursement is the user who wants to claim reimbursement for the electronic invoice. For example... Figure 6 As shown, assuming that the user requesting reimbursement at terminal device 70 wants to reimburse an electronic invoice with the identifier "electronic invoice identifier x" at the company, terminal device 60 will obtain the user's reimbursement request identity information, the company's reimbursement information, and the electronic invoice, generate an electronic invoice reimbursement request, and send it to business node 700.

[0126] S72, invoke the invoice token corresponding to the electronic invoice in the electronic invoice contract according to the electronic invoice reimbursement request.

[0127] Specifically, after receiving an electronic invoice reimbursement request, business node 700 extracts the electronic invoice identifier (i.e., electronic invoice identifier x) from the request. Then, business node 700 searches the electronic invoice container of the electronic invoice contract for a token whose identifier is also electronic invoice identifier x, and uses this token as the corresponding token for the electronic invoice. For example... Figure 7 As shown, the ticket token corresponding to this electronic ticket can be ticket token 7001.

[0128] S73, Read the first user information stored in the ticket owner field of the ticket token.

[0129] S74, if the reimbursement request user information is the same as the first user information, and there is no reimbursement identifier in the bill transfer field of the bill token, then the holding rights of the electronic bill held by the first user information are transferred to the reimbursement company information through the electronic bill contract.

[0130] Specifically, business node 700 first needs to determine whether the user requesting reimbursement has the right to hold the electronic invoice, and whether the electronic invoice has already been reimbursed. Only if the user requesting reimbursement has the right to hold the electronic invoice, and the electronic invoice has not been reimbursed, will business node 700 respond to the electronic invoice reimbursement request and execute the corresponding reimbursement method, such as transferring the right to hold the electronic invoice held by the first user to the reimbursing company through the electronic invoice contract. It is understandable that transferring the right to hold the electronic invoice held by the first user to the reimbursing company requires going through the consensus network (i.e., the aforementioned...). Figure 1 In the consensus processing of the network where the consensus node cluster is located in the corresponding embodiment, once the consensus is passed, the holding rights of the electronic invoice held by the first user information are transferred to the reimbursement company information and then recognized by the various consensus nodes or business nodes in the entire blockchain, and the reimbursement of the electronic invoice is considered successful.

[0131] Specifically, electronic invoices that have already been reimbursed can be marked using an invoice reimbursement identifier. When an electronic invoice reimbursement is completed, the business node will generate a corresponding invoice reimbursement identifier and then add the invoice reimbursement identifier to the invoice circulation field of the invoice token corresponding to the electronic invoice for easy viewing later.

[0132] S75, generate the invoice reimbursement identifier, and update the invoice token based on the invoice reimbursement identifier, the first user information, the reimbursement company information, and the electronic invoice.

[0133] Specifically, business node 700 can generate a third invoice circulation trajectory based on the first user information and the reimbursement company information; then, it can generate an invoice reimbursement identifier for the first user information; then, it can replace the first user information stored in the invoice owner field of the invoice token with the reimbursement company information; finally, it can add the third invoice circulation trajectory and the invoice reimbursement identifier to the invoice circulation field of the invoice token. For example... Figure 7 As shown, after the business node updates the invoice token 7001, the electronic invoice identifier x in the token identifier field and the electronic invoice information y in the invoice information field of the invoice token 7001 remain unchanged. However, the first user information stored in the invoice owner field changes to the reimbursement company information. The third invoice circulation trajectory generated by the business node 700 is "first user → reimbursement company". The business node 700 will also generate an invoice reimbursement identifier for the first user information, and then the business node 700 will add this third invoice circulation trajectory and the invoice reimbursement identifier to the invoice circulation field.

[0134] Optionally, the business node 700 can call the electronic invoice contract to complete the reimbursement of the electronic invoice held by the first user information, as well as the update behavior of updating the invoice token corresponding to the electronic invoice. This can also be written into the operation log for later review.

[0135] Using the method provided in this application embodiment, the identity information of the reimbursement user is verified before electronic invoice reimbursement, and reimbursement is only allowed after the verification is successful. After electronic invoice reimbursement, an invoice reimbursement identifier for the reimbursement user's identity information is generated and written into the invoice circulation field of the invoice token corresponding to the electronic invoice. Subsequent electronic invoice reimbursement requests for the electronic invoice will be rejected by the business node, which can avoid problems such as fake invoices being issued in a real manner or multiple invoices being issued.

[0136] Further, please see Figure 8 , Figure 8 This is a schematic diagram of the structure of a blockchain-based bill management device provided in an embodiment of this application. The aforementioned blockchain-based bill management device can be a computer program (including program code) running on a computer device; for example, the blockchain-based bill processing device is an application software. This device can be used to execute the corresponding steps in the method provided in the embodiment of this application. The blockchain-based bill management device 1 may include: a first request acquisition module 101, an authentication processing module 102, a bill generation module 103, an information acquisition module 104, a trajectory generation module 105, and a storage module 106.

[0137] The first request acquisition module 101 is used to acquire the electronic invoice issuance request; the electronic invoice issuance request includes the service provider identity information of the invoice service provider;

[0138] The authentication processing module 102 is used to call the set of authorized service providers in the electronic invoice contract to authenticate the service provider identity information according to the electronic invoice issuance request, and obtain the authentication result.

[0139] The bill generation module 103 is used to generate an electronic bill through the electronic bill contract if the authentication result indicates that the user has the authority to issue bills.

[0140] The information acquisition module 104 is used to acquire the first user information with the right to hold electronic bills through the electronic bill contract;

[0141] The trajectory generation module 105 is used to generate a first ticket circulation trajectory based on the first user information.

[0142] Storage module 106 is used to store the first user information, the first bill circulation trajectory, and the basic bill information in the electronic bill into the bill token in the electronic bill container; the bill token refers to the bill storage address in the electronic bill container that corresponds to the electronic bill identifier of the electronic bill; the electronic bill container is located in the electronic bill contract.

[0143] The specific implementation methods of the first request acquisition module 101, authentication processing module 102, ticket generation module 103, information acquisition module 104, trajectory generation module 105, and storage module 106 can be found in the above description. Figure 3 The descriptions of steps S101-S104 in the corresponding embodiments will not be repeated here.

[0144] Please see Figure 8 The authentication processing module 102 may include: a calling unit 1021 and a traversal authentication unit 1022.

[0145] The calling unit 1021 is used to call the set of authorized service providers in the electronic invoice contract according to the electronic invoice issuance request; the set of authorized service providers includes the legal identity information of at least two authorized service providers;

[0146] The authentication unit 1022 is used to traverse the set of authorized service providers based on the service provider identity information.

[0147] Traversing the authentication unit 1022 is also used to determine the authentication result as having the authority to issue invoices if a legitimate identity information identical to the service provider's identity information is found in the set of authorized service providers.

[0148] The specific implementation methods of the calling unit 1021 and the traversal authentication unit 1022 can be found in the above. Figure 3 The description of step S102 in the corresponding embodiment will not be repeated here.

[0149] Please see Figure 8 The information acquisition module 104 may include a request processing unit 1041 and a permission allocation unit 1042.

[0150] The request processing unit 1041 is used to obtain a ticket holding request for an electronic ticket sent by the terminal device corresponding to the first user information;

[0151] The request processing unit 1041 is also used to invoke the electronic bill contract according to the bill holding request;

[0152] The permission allocation unit 1042 is used to allocate holding permissions for the electronic bill to the first user information carried in the bill holding request through the electronic bill contract, thereby obtaining the first user information with holding permissions for the electronic bill.

[0153] The specific implementation methods of the request processing unit 1041 and the permission allocation unit 1042 can be found in the above description. Figure 3 The description of step S104 in the corresponding embodiment will not be repeated here.

[0154] The bill holding request also carries the first user information and the first signature data for the electronic bill;

[0155] Please see Figure 8 The permission allocation unit 1042 may include: consensus subunit 10421 and permission determination subunit 10422.

[0156] Consensus subunit 10421 is used to initiate consensus processing on the electronic bill and the first signature data to the consensus network through the electronic bill contract to obtain the first consensus result; the consensus network is used to write the association between the electronic bill and the first user information into the blockchain ledger when the first consensus result is a consensus pass result;

[0157] The permission determination subunit 10422 is used to determine, when the association between the electronic ticket and the first user information is written into the blockchain ledger, whether the first user information carried in the ticket holding request has the permission to hold the electronic ticket.

[0158] The specific implementation methods of consensus subunit 10421 and permission determination subunit 10422 can be found in the above. Figure 3 The description of step S104 in the corresponding embodiment will not be repeated here.

[0159] The basic information of the bill includes the electronic bill identifier and the electronic bill face information; the bill token includes the token identifier field, the bill owner field, the face information field, and the bill circulation field.

[0160] Please see Figure 8The storage module 106 may include an extraction unit 1061 and a storage unit 1062.

[0161] Extraction unit 1061 is used to extract the electronic bill identifier and electronic bill information from the electronic bill through the bill container function in the electronic bill contract;

[0162] Storage unit 1062 is used to store the electronic ticket identifier in the token identifier field, the first user information in the ticket owner field, the electronic ticket face information in the ticket face information field, and the first ticket circulation trajectory in the ticket circulation field.

[0163] The specific implementation methods of the extraction unit 1061 and the storage unit 1062 can be found in the above description. Figure 3 The description of step S104 in the corresponding embodiment will not be repeated here.

[0164] Please see Figure 8 The aforementioned ticket management device 1 may further include: a second request acquisition module 107, a first token invocation module 108, a first information reading module 109, a first permission transfer module 110, and a first token update module 111.

[0165] The second request acquisition module 107 is used to acquire the electronic ticket transfer request sent by the terminal device corresponding to the transfer request user information; the electronic ticket transfer request includes the second user information, the transfer request user information, and the electronic ticket;

[0166] The first token invocation module 108 is used to invoke the bill token corresponding to the electronic bill in the electronic bill contract according to the electronic bill transfer request.

[0167] The first information reading module 109 is used to read the first user information stored in the ticket owner field of the ticket token;

[0168] The first permission transfer module 110 is used to transfer the electronic bill holding rights of the first user information to the second user information through an electronic bill contract if the user information requesting the transfer is the same as the first user information.

[0169] The first token update module 111 is used to update the ticket token based on the first user information, the second user information, and the electronic ticket.

[0170] The specific implementation methods of the second request acquisition module 107, the first token invocation module 108, the first information reading module 109, the first permission transfer module 110, and the first token update module 111 can be found in the above description. Figure 6 The descriptions of steps S61-S65 in the corresponding embodiments will not be repeated here.

[0171] Please see Figure 8 The first token update module 111 may include: a first trajectory generation unit 1111 and a first update unit 1112.

[0172] The first trajectory generation unit 1111 is used to generate a second ticket circulation trajectory based on the first user information and the second user information.

[0173] The first update unit 1112 is used to replace the first user information stored in the ticket owner field of the ticket token with the second user information;

[0174] The first update unit 1112 is also used to add the second bill transfer trajectory to the bill transfer field of the bill token.

[0175] The specific implementation methods of the first trajectory generation unit 1111 and the first update unit 1112 can be found in the above description. Figure 6 The description of step S65 in the corresponding embodiment will not be repeated here.

[0176] Please see Figure 8 It may include: a third request acquisition module 112, a second token invocation module 113, a second information reading module 114, a second permission transfer module 115, and a second token update module 116.

[0177] The third request acquisition module 112 is used to acquire the electronic invoice reimbursement request sent by the terminal device corresponding to the reimbursement request user information; the electronic invoice reimbursement request includes reimbursement company information, reimbursement request user information, and electronic invoice;

[0178] The second token invocation module 113 is used to invoke the token corresponding to the electronic invoice in the electronic invoice contract according to the electronic invoice reimbursement request.

[0179] The second information reading module 114 is used to read the first user information stored in the ticket owner field of the ticket token;

[0180] The second permission transfer module 115 is used to transfer the electronic bill holding rights of the first user information to the reimbursement company information through an electronic bill contract if the reimbursement request user information is the same as the first user information and there is no bill reimbursement identifier in the bill transfer field of the bill token.

[0181] The second token update module 116 is used to generate a reimbursement identifier for invoices and update the invoice token based on the invoice reimbursement identifier, the first user information, the reimbursement company information, and the electronic invoice.

[0182] The specific implementation methods of the third request acquisition module 112, the second token invocation module 113, the second information reading module 114, the second permission transfer module 115, and the second token update module 116 can be found in the above description. Figure 7 The descriptions of steps S71-S75 in the corresponding embodiments will not be repeated here.

[0183] Please see Figure 8 The second token update module 116 may include: a second trajectory generation unit 1161, a reimbursement identifier generation unit 1162, and a second update unit 1163.

[0184] The second trajectory generation unit 1161 is used to generate a third invoice circulation trajectory based on the first user information and the reimbursement company information.

[0185] The reimbursement identifier generation unit 1162 is used to generate a reimbursement identifier for the first user information.

[0186] The second update unit 1163 is used to replace the first user information stored in the ticket owner field of the ticket token with the reimbursement company information.

[0187] The second update unit 1163 is also used to add the third invoice circulation trajectory and invoice reimbursement identifier to the invoice circulation field of the invoice token.

[0188] The specific implementation methods of the second trajectory generation unit 1161, the reimbursement identifier generation unit 1162, and the second update unit 1163 can be found in the above description. Figure 7 The description of step S75 in the corresponding embodiment will not be repeated here.

[0189] Please see Figure 8 The aforementioned ticket management device 1 may further include: a log writing module 117.

[0190] The log writing module 117 is used to call the log function in the electronic bill contract to query the bill generation behavior information and bill storage behavior information for the electronic bill issuance request;

[0191] The log writing module 117 is also used to write the bill generation behavior information and bill storage behavior information into the operation log of the electronic bill contract.

[0192] For details on the implementation of the log writing module 117, please refer to the above. Figure 5 The description of the corresponding operation log 54 in the corresponding embodiment will not be repeated here.

[0193] Please see Figure 8 The aforementioned invoice management device 1 may further include: a service provider addition module 118.

[0194] The service provider addition module 118 is used to receive service provider addition requests; the service provider addition request includes the identity information of the bill service provider and the identity information of the bill administration bureau.

[0195] The service provider addition module 118 is also used to call the legitimate management authority in the electronic bill contract to verify the identity of the bill management authority based on the service provider addition request, and obtain the verification result;

[0196] The service provider addition module 118 is also used to add the identity information of the bill service provider to the set of authorized service providers in the electronic bill contract if the verification result is a successful verification result.

[0197] For details on the implementation of the service provider addition module 118, please refer to the above. Figure 3 The description of step S102 in the corresponding embodiment will not be repeated here.

[0198] Further, please see Figure 9 , Figure 9 This is a schematic diagram of the structure of a computer device provided in an embodiment of this application. Figure 9 As shown above, Figure 8 The ticket management device 1 in the corresponding embodiment can be applied to the aforementioned computer device 9000. The computer device 9000 may include a processor 9001, a network interface 9004, and a memory 9005. Furthermore, the computer device 9000 also includes a user interface 9003 and at least one communication bus 9002. The communication bus 9002 is used to enable communication between these components. The user interface 9003 may include a display screen and a keyboard; optionally, the user interface 9003 may also include a standard wired interface or a wireless interface. The network interface 9004 may optionally include a standard wired interface or a wireless interface (such as a Wi-Fi interface). The memory 9005 may be high-speed RAM or non-volatile memory, such as at least one disk storage device. Optionally, the memory 9005 may also be at least one storage device located remotely from the aforementioned processor 9001. Figure 9 As shown, the memory 9005, which is a computer-readable storage medium, may include an operating system, a network communication module, a user interface module, and a device control application program.

[0199] exist Figure 9In the computer device 9000 shown, the network interface 9004 provides network communication functionality; the user interface 9003 is mainly used to provide an input interface for the user; and the processor 9001 can be used to call the device control application program stored in the memory 9005 to achieve:

[0200] Obtain an electronic invoice issuance request; the electronic invoice issuance request includes the service provider's identity information;

[0201] Based on the electronic invoice issuance request, the authorized service provider set in the electronic invoice contract is invoked to authenticate the service provider's identity information and obtain the authentication result;

[0202] If the authentication result indicates that the holder has the authority to issue bills, then an electronic bill is generated through the electronic bill contract.

[0203] The system obtains the first user information with the right to hold electronic bills through the electronic bill contract, generates the first bill circulation trajectory based on the first user information, and stores the first user information, the first bill circulation trajectory, and the basic bill information in the electronic bill into the bill token in the electronic bill container; the bill token refers to the bill storage address in the electronic bill container that corresponds to the electronic bill identifier of the electronic bill; the electronic bill container is located in the electronic bill contract.

[0204] It should be understood that the computer device 9000 described in the embodiments of this application can execute the foregoing text. Figure 3 The description of the blockchain-based ticket management method in the corresponding embodiments can also be performed as described above. Figure 8 The description of the blockchain-based ticket management device 1 in the corresponding embodiments will not be repeated here. Furthermore, the beneficial effects of using the same method will also not be repeated here.

[0205] Furthermore, it should be noted that this application embodiment also provides a computer-readable storage medium, which stores a computer program executed by the aforementioned data processing computer device 9000. The computer program includes program instructions, and when the processor executes the program instructions, it can execute the aforementioned... Figure 3 The description of the above-described invoice management method in the corresponding embodiments will not be repeated here. Furthermore, the beneficial effects of using the same method will also not be repeated. For technical details not disclosed in the computer-readable storage medium embodiments related to this application, please refer to the description of the method embodiments of this application.

[0206] The aforementioned computer-readable storage medium can be an internal storage unit of the ticket management device or the computer equipment provided in any of the foregoing embodiments, such as a hard disk or memory of the computer equipment. The computer-readable storage medium can also be an external storage device of the computer equipment, such as a plug-in hard disk, smart media card (SMC), secure digital (SD) card, flash card, etc., provided on the computer equipment. Furthermore, the computer-readable storage medium may include both internal storage units and external storage devices of the computer equipment. The computer-readable storage medium is used to store the computer program and other programs and data required by the computer equipment. The computer-readable storage medium can also be used to temporarily store data that has been output or will be output.

[0207] One aspect of this application provides a computer program product or computer program including computer instructions stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the computer device to perform the method provided in one aspect of the embodiments of this application.

[0208] The terms "first," "second," etc., in the specification, claims, and drawings of this application are used to distinguish different objects, not to describe a specific order. Furthermore, the term "comprising," and any variations thereof, are intended to cover non-exclusive inclusion. For example, a process, method, apparatus, product, or device that includes a series of steps or units is not limited to the listed steps or modules, but may optionally include steps or modules not listed, or may optionally include other step units inherent to these processes, methods, apparatuses, products, or devices.

[0209] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementations should not be considered beyond the scope of this application.

[0210] The methods and related apparatuses provided in this application are described with reference to the method flowcharts and / or structural diagrams provided in this application. Specifically, each block of the method flowchart and / or structural diagram, as well as combinations of blocks in the flowchart and / or block diagram, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing device to create a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing device, generate instructions for implementing the process. Figure 1 A schematic diagram of one or more processes and / or structures. Figure 1 The computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to operate in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 A schematic diagram of one or more processes and / or structures. Figure 1 The functions specified in one or more boxes. These computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable apparatus for implementing the process. Figure 1 A process or multiple processes and / or structures illustrate the steps of the functions specified in one or more boxes.

[0211] The above-disclosed embodiments are merely preferred embodiments of this application and should not be construed as limiting the scope of this application. Therefore, any equivalent variations made in accordance with the claims of this application shall still fall within the scope of this application.

Claims

1. A blockchain-based invoice management method, characterized in that, include: Obtain an electronic invoice issuance request; the electronic invoice issuance request includes the service provider's identity information; Based on the electronic invoice issuance request, the authorized service provider set in the electronic invoice contract is invoked to authenticate the service provider's identity information, and the authentication result is obtained. If the authentication result indicates that the holder has the authority to issue bills, then an electronic bill is generated through the electronic bill contract; The electronic bill contract is used to obtain the first user information that has the right to hold the electronic bill, and the first bill circulation trajectory is generated based on the first user information. The electronic bill identifier and electronic bill information are extracted from the electronic bill through the bill container function in the electronic bill contract; the electronic bill contract includes an electronic bill container, which includes multiple bill tokens for storing different electronic bills, and each bill token includes a token identifier field, a bill owner field, a bill information field, and a bill circulation field; The electronic ticket identifier is stored in the token identifier field, the first user information is stored in the ticket owner field, the electronic ticket face information is stored in the face information field, and the first ticket circulation trajectory is stored in the ticket circulation field; the ticket token refers to the ticket storage address in the electronic ticket container corresponding to the electronic ticket identifier of the electronic ticket; the ticket circulation field is also used to add a second ticket circulation trajectory to characterize the transfer process of holding rights between the first user information and the second user information when the holding rights of the electronic ticket are transferred to the second user information.

2. The method according to claim 1, characterized in that, The step of authenticating the service provider's identity information by calling the authorized service provider set in the electronic invoice contract according to the electronic invoice issuance request, and obtaining the authentication result, includes: The electronic invoice issuance request invokes the set of authorized service providers in the electronic invoice contract; the set of authorized service providers includes the legal identity information of at least two authorized service providers; The authorized service provider set is traversed based on the service provider identity information; If a legitimate identity information identical to the identity information of the authorized service provider is found in the set of authorized service providers, the authentication result is determined to be that the service provider has the authority to issue invoices.

3. The method according to claim 1, characterized in that, The step of obtaining the first user information with the right to hold the electronic bill through the electronic bill contract includes: Obtain the electronic bill holding request sent by the terminal device corresponding to the first user information, invoke the electronic bill contract according to the electronic bill holding request, and allocate holding rights for the electronic bill to the first user information carried in the electronic bill holding request through the electronic bill contract, thereby obtaining the first user information with holding rights for the electronic bill.

4. The method according to claim 3, characterized in that, The bill holding request also carries the first signature data of the first user information for the electronic bill; The step of allocating holding rights for the electronic bill to the first user information carried in the bill holding request through the electronic bill contract, thereby obtaining first user information with holding rights for the electronic bill, includes: The electronic bill contract initiates consensus processing on the consensus network for the electronic bill and the first signature data to obtain a first consensus result; the consensus network is used to write the association between the electronic bill and the first user information into the blockchain ledger when the first consensus result is a consensus pass result; When the association between the electronic ticket and the first user information is written into the blockchain ledger, it is determined that the first user information carried in the ticket holding request has the right to hold the electronic ticket.

5. The method according to claim 1, characterized in that, Also includes: Obtain the electronic ticket transfer request sent by the terminal device corresponding to the user information of the transfer request; The electronic invoice transfer request includes the second user information, the transfer request user information, and the electronic invoice; The electronic bill transfer request is used to invoke the bill token corresponding to the electronic bill in the electronic bill contract; Read the first user information stored in the ticket owner field of the ticket token; If the user information requesting the transfer is the same as the first user information, then the holding rights of the electronic bill held by the first user information are transferred to the second user information through the electronic bill contract; The ticket token is updated based on the first user information, the second user information, and the electronic ticket.

6. The method according to claim 5, characterized in that, The step of updating the ticket token based on the first user information, the second user information, and the electronic ticket includes: A second invoice circulation trajectory is generated based on the first user information and the second user information; Replace the first user information stored in the ticket owner field of the ticket token with the second user information; Add the second bill transfer trajectory to the bill transfer field of the bill token.

7. The method according to claim 1, characterized in that, Also includes: The system obtains an electronic invoice reimbursement request sent by a terminal device corresponding to the user information of the reimbursement request; the electronic invoice reimbursement request includes reimbursement company information, the reimbursement request user information, and the electronic invoice; The electronic invoice reimbursement request is used to retrieve the invoice token corresponding to the electronic invoice in the electronic invoice contract; Read the first user information stored in the ticket owner field of the ticket token; If the reimbursement request user information is the same as the first user information, and there is no reimbursement identifier in the invoice transfer field of the invoice token, then the holding rights of the electronic invoice held by the first user information are transferred to the reimbursement company information through the electronic invoice contract. Generate the invoice reimbursement identifier, and update the invoice token based on the invoice reimbursement identifier, the first user information, the reimbursement company information, and the electronic invoice.

8. The method according to claim 7, characterized in that, The process of generating the invoice reimbursement identifier and updating the invoice token based on the invoice reimbursement identifier, the first user information, the reimbursement company information, and the electronic invoice includes: A third invoice circulation trajectory is generated based on the first user information and the reimbursement company information; The invoice reimbursement identifier is generated based on the first user information; Replace the first user information stored in the ticket owner field of the ticket token with the reimbursement company information; The third invoice transfer trajectory and the invoice reimbursement identifier are added to the invoice transfer field of the invoice token.

9. The method according to claim 1, characterized in that, Also includes: Call the log function in the electronic bill contract to query the bill generation behavior information and bill storage behavior information for the electronic bill issuance request; The information on bill generation and storage is written into the operation log of the electronic bill contract.

10. The method according to claim 1, characterized in that, Also includes: Receive a service provider addition request; the service provider addition request includes the identity information of the bill service provider and the identity information of the bill administration bureau; Based on the service provider's added request, the legitimate authority in the electronic bill contract is invoked to verify the identity of the bill authority, and the verification result is obtained; If the verification result is a successful verification, then the identity information of the bill service provider will be added to the set of authorized service providers in the electronic bill contract.

11. A blockchain-based ticket management device, characterized in that, include: The first request acquisition module is used to acquire electronic invoice issuance requests; the electronic invoice issuance request includes the service provider identity information of the invoice service provider; The authentication processing module is used to call the set of authorized service providers in the electronic invoice contract to authenticate the identity information of the service providers according to the electronic invoice issuance request, and obtain the authentication result. The bill generation module is used to generate an electronic bill through the electronic bill contract if the authentication result indicates that the user has the authority to issue bills. The information acquisition module is used to acquire the first user information who has the right to hold the electronic bill through the electronic bill contract; The first trajectory generation module is used to generate a first ticket circulation trajectory based on the first user information; The storage module is used to extract the electronic bill identifier and electronic bill information from the electronic bill through the bill container function in the electronic bill contract; the electronic bill contract includes an electronic bill container, which includes multiple bill tokens for storing different electronic bills, and each bill token includes a token identifier field, a bill owner field, a bill information field, and a bill circulation field; The storage module is further configured to store the electronic ticket identifier in the token identifier field, store the first user information in the ticket owner field, store the electronic ticket face information in the face information field, and store the first ticket circulation trajectory in the ticket circulation field; the ticket token refers to the ticket storage address in the electronic ticket container corresponding to the electronic ticket identifier of the electronic ticket; the ticket circulation field is further configured to add a second ticket circulation trajectory to characterize the transfer process of holding rights between the first user information and the second user information when the holding rights of the electronic ticket are transferred to the second user information.

12. A computer device, characterized in that, include: Processor, memory, and network interface; The processor is connected to the memory and the network interface, wherein the network interface is used to provide network communication functions, the memory is used to store program code, and the processor is used to call the program code to execute the method according to any one of claims 1-10.

13. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program adapted to be loaded by a processor and to execute the method described in any one of claims 1-10.

Images