WO2018161903A1 - 电子票据管理方法、装置及存储介质 - Google Patents

电子票据管理方法、装置及存储介质 Download PDF

Info

Publication number
WO2018161903A1
WO2018161903A1 PCT/CN2018/078171 CN2018078171W WO2018161903A1 WO 2018161903 A1 WO2018161903 A1 WO 2018161903A1 CN 2018078171 W CN2018078171 W CN 2018078171W WO 2018161903 A1 WO2018161903 A1 WO 2018161903A1
Authority
WO
WIPO (PCT)
Prior art keywords
ticket
user
account
transaction
block
Prior art date
Application number
PCT/CN2018/078171
Other languages
English (en)
French (fr)
Inventor
郭锐
李茂材
张建俊
屠海涛
赵琦
王宗友
梁军
朱大卫
刘斌华
Original Assignee
腾讯科技（深圳）有限公司
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 腾讯科技（深圳）有限公司 filed Critical 腾讯科技（深圳）有限公司
Priority to EP18763957.0A priority Critical patent/EP3594884A4/en
Priority to KR1020197022822A priority patent/KR102277998B1/ko
Priority to JP2019526479A priority patent/JP7108611B2/ja
Publication of WO2018161903A1 publication Critical patent/WO2018161903A1/zh
Priority to US16/384,349 priority patent/US10977632B2/en

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/08—Payment architectures
    • G06Q20/10—Payment architectures specially adapted for electronic funds transfer [EFT] systems; specially adapted for home banking systems
    • G06Q20/102—Bill distribution or payments
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction
    • G06Q20/3825—Use of electronic signatures
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/08—Payment architectures
    • G06Q20/14—Payment architectures specially adapted for billing systems
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/389—Keeping log of transactions for guaranteeing non-repudiation of a transaction
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • G06Q20/401—Transaction verification
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • G06Q20/401—Transaction verification
    • G06Q20/4016—Transaction verification involving fraud or risk level assessment in transaction processing
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q30/00—Commerce
    • G06Q30/04—Billing or invoicing
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/50—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using hash chains, e.g. blockchains or hash trees
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q2220/00—Business processing using cryptography

Definitions

  • the embodiments of the present invention relate to the field of network technologies, and in particular, to an electronic ticket management method, apparatus, and storage medium.
  • An electronic ticket is a ticket stored in the form of a data message.
  • Electronic bills are mainly used in the process of commercial trade, and can be transferred, discounted or pledged in the course of commercial trade.
  • enterprise user A purchases a batch of goods from enterprise user B.
  • enterprise user B can still obtain an electronic ticket through online banking, and the electronic ticket records Transaction information between enterprise user A and enterprise user B, including arrears information, ticket holder information, billing date, and expiration date.
  • enterprise user B can transfer, discount or pledge the electronic receipt through online banking.
  • the transaction information of the electronic ticket is likely to be maliciously falsified, resulting in poor security and reliability of the electronic ticket.
  • embodiments of the present invention provide an electronic receipt management method, apparatus, and storage medium.
  • the technical solution is as follows:
  • an electronic ticket management method is provided, the method being applied to an electronic receipt management system, the method comprising:
  • an electronic ticket management apparatus comprising:
  • a receiving module configured to receive a ticket issuance request of the first user, where the ticket issuance request carries original bill information
  • An account generating module configured to generate, according to the original bill information, a first bill account corresponding to the first user, and store account information of the first bill account into an account table in the electronic bill management system;
  • a block generating module configured to generate a second block based on the ticket issuance request, the first ticket account, and a tile header feature value of a first block in a blockchain in the electronic ticket management system,
  • the first block is a previous block of the second block on the blockchain, and the second block is configured to record a ticket issue event of the first user;
  • a sending module configured to send a release success message to the first user, where the release success message carries the first ticket account.
  • an apparatus for electronic ticket management comprising: one or more processors, a memory for storing at least one instruction, at least one program, a code set, or a set of instructions, the at least one The instruction, the at least one piece of program, the set of codes, or the set of instructions are loaded by the processor and perform the following operations:
  • a storage medium having stored therein at least one instruction, at least one program, a code set, or a set of instructions, the at least one instruction, the at least one program, the code set, or an instruction set Loaded and executed by the processor to implement the electronic ticket management method as described above.
  • the embodiment of the present invention generates a first ticket account corresponding to the first user not only in the account table but also based on the first user's ticket issuance request, the first ticket account, and the blockchain, based on the original bill information of the first user.
  • the block header feature value of the first block generates a second block, which can not only manage the account information through the account table, but also can tamper with any information in the block based on the association relationship between the front and rear blocks in the blockchain. Time can be detected through the next block to prevent malicious users from tampering or refusing the issued electronic notes, thus ensuring the security and reliability of the transaction information.
  • FIG. 1 is a schematic diagram of an implementation environment of electronic ticket management according to an embodiment of the present invention.
  • FIG. 2 is a schematic diagram of a method for managing electronic receipts according to an embodiment of the present invention
  • 3 is an original data information filling interface provided by an embodiment of the present invention.
  • FIG. 5 is a flowchart of user registration according to an embodiment of the present invention.
  • FIG. 6 is a flow chart of issuing a ticket according to an embodiment of the present invention.
  • FIG. 7 is a flow chart of a ticket transfer according to an embodiment of the present invention.
  • FIG. 8 is a flow chart of discounting a ticket according to an embodiment of the present invention.
  • FIG. 9 is a flowchart of a bill splitting according to an embodiment of the present invention.
  • FIG. 10A is a flow chart of bill payment according to an embodiment of the present invention.
  • FIG. 10B is a flow chart of a ticket transaction according to an embodiment of the present invention.
  • FIG. 10C is a flow chart of a ticket transaction according to an embodiment of the present invention.
  • FIG. 11 is a block diagram of an electronic receipt management apparatus according to an embodiment of the present invention.
  • FIG. 12 is a block diagram of an electronic receipt management apparatus according to an embodiment of the present invention.
  • FIG. 13 is a block diagram of an electronic receipt management apparatus according to an embodiment of the present invention.
  • FIG. 14 is a block diagram of an electronic receipt management apparatus according to an embodiment of the present invention.
  • FIG. 15 is a block diagram of an electronic receipt management apparatus according to an embodiment of the present invention.
  • FIG. 16 is a block diagram of an electronic receipt management apparatus 1600 according to an embodiment of the present invention.
  • FIG. 1 is a schematic diagram of an implementation environment of an electronic ticket management method according to an embodiment of the present invention.
  • the implementation environment is an electronic receipt management system
  • the electronic ticket management system and the user 101 in the electronic receipt management system can respectively store the same one blockchain, and the blockchain is composed of multiple zones. Blocks, each block stores different information, and each piece of information is stored in chronological order on each block. In the embodiment of the present invention, each block may store information related to one transaction.
  • the electronic ticket management system is used to manage electronic tickets of the user 101, such as issuing or trading electronic tickets, and storing the transaction information to blocks on the blockchain during the issuance and transaction process.
  • User 101 is used to interact with an electronic ticket management system to issue electronic tickets or to conduct transactions with other users, which may be specifically supplier users, individual users, business users or bank users, and the like.
  • the electronic device used by the user 101 can be a laptop, a desktop computer, a smart phone, or the like.
  • the electronic ticket management system may include at least two nodes, at least two nodes may include at least two servers 102, and may also include a gateway 103, etc., and the electronic ticket management system may be DAM (Digit Asset Management). system).
  • the at least two servers 102 are configured to manage electronic tickets of each user based on a blockchain technology
  • the gateway 103 is configured to provide an access service between the user 101 and the DAM, and may also be used as a billing node in the implementation environment.
  • the transaction information in the transaction process is stored and updated periodically, so that other nodes in the implementation environment can share the transaction information, so that each node can provide a consistency certificate for the transaction information, thereby improving the security of the transaction information, for example, when When a ticket transfer process is completed, the billing node can share transaction information to the blockchain of each node according to the node identifier of each node (such as a network address).
  • the server 102 can interact with the user 101 through the gateway 103 to manage the electronic tickets of the user 101.
  • the interaction with the banking system 104 is also involved.
  • the banking system 104 is used to provide real commercial paper information, thereby verifying the authenticity of the original receipt information submitted by the user.
  • the electronic receipt management system may store, in addition to a blockchain, an account table in which at least one ticket account for identifying an electronic receipt and corresponding account information describing the electronic receipt, such as an account status, are stored.
  • the account balance, etc., the account table can be updated according to the transaction, thus realizing the method of dynamically updating the electronic ticket during the transaction process.
  • the account information in the account table can also be stored in the blockchain with each transaction process, that is, the account table is stored in the blockchain. Since the information in the blockchain cannot be changed, it is not necessary to modify the original account information each time the account information needs to be updated during the transaction, but the updated account information is stored in a new block.
  • the above electronic ticket system may be based on an API (Application Programming Interface) interface of the HTTP (HyperText Transfer Protocol) protocol, which adopts two-way certificate verification and supports JSON (JavaScript).
  • JavaScript JavaScript Object Markup Language
  • POST calls to data and return JSON data uniformly.
  • UTF-8 8-bit Unicode Transformation Format
  • JavaScript is a literal translation scripting language.
  • the POST call is an important part of the HTTP protocol and is used to send update requests to the destination server.
  • the electronic ticket management system can also use a signature algorithm such as ECDSA (Elliptic Curve Digital Signature Algorithm) to sign a message initiated by the user during the transaction.
  • the signature algorithm can be divided into two parts: the first part is a service parameter, the service parameter needs to be initiated by the user to sign with his own private key, and the DAM platform uses the user's public key for verification.
  • the second part is the protocol parameters.
  • the protocol parameters need to be initiated by the https requester (gateway/participant with R&D capability) to sign with their own private key.
  • the DAM platform uses the public key of the requester for verification.
  • FIG. 2 is a schematic diagram of a method for managing electronic receipts according to an embodiment of the present invention. Referring to FIG. 2, the method is applied to an electronic ticket management system, and specifically includes:
  • the first user refers to any user registered in the electronic ticket management system, and is not limited to an individual user, a corporate user, or a bank user.
  • the original bill information refers to the bill information of the commercial bill held by the user, and includes at least the bill identifier of the original bill information, and may also include the asset information of the commercial bill, the billing date, the expiration date, the bank account of the user, and the bank of the account. And issuing asset information and the like, referring to FIG. 3, an embodiment of the present invention provides an original data information filling interface, and the original data information filling interface provides an input box for filling in the plurality of bill information, etc., so as to be The information input by the user is obtained in each input box, and then sent to the electronic ticket management system.
  • the transaction real name system may be adopted, and any user may provide the identity information of the user when registering the electronic ticket management system.
  • the individual user may provide the identity card number of the user.
  • Enterprise users can provide their own enterprise code. The user can fill in the registration information on the registration interface provided by the electronic receipt management system and submit a registration request to the electronic receipt management system.
  • a registration interface which displays an enterprise full name input box, an organization code input box, a bank account input box, an account bank input box, an enterprise contact input box, and an enterprise phone input.
  • the box and the contact address input box can be obtained based on the information input by the user in each input box, “the enterprise is fully referred to as supplier B, the organization cabinet code is 0526634-7, the enterprise contact is king five, and the contact number is 18888833377, contact address It is the user identity information such as “B Road in Tianjin Area A” and bank account information such as “Bank account number is 62111111888823333, Bank of deposit is Construction Bank”. Referring to FIG. 5, an embodiment of the present invention provides a user registration flowchart.
  • the electronic receipt management system When the electronic receipt management system receives the registration request of the user, it can go to the public security organ to verify whether the identity information carried in the registration request is true, and if it is not true, the user is refused to register, and if it is true, the user is allowed to register, and The user generates a pair of keys and returns the private key of the pair of keys to the user, and the public key is stored by the electronic ticket management system to verify the identity of the user.
  • the first user's ticket issuance request may be triggered by the user on the client or webpage provided by the electronic receipt management system, and sent to the gateway of the electronic receipt management system, so that the gateway can receive the first User's ticket issuance request. Since the gateway can have the function of checksum isolation, it can improve the security of information.
  • the first bill account is used to identify an electronic ticket issued for the first user, which may be a feature value for uniquely identifying the electronic ticket, such as a hash value, etc., and the account information of the first ticket account is used for
  • the electronic note is described, not limited to the information of the note holder, asset information, billing date, expiration date, account status, transaction result, and the like.
  • the bill holder information, asset information, billing date, and expiration date can be directly obtained from the original bill information; the transaction result can be added in the subsequent transaction process, for example, a sign rejection message; the account status can be set to normal holding Stateful.
  • the electronic receipt management system may modify the account status in the account information of the first ticket account in the account table according to the transaction process of the ticket transaction, and the account status includes the transferred status, the discounted status, and the redeemed status. And normal holding status, etc.
  • the electronic receipt management system may query the commercial paper information corresponding to the ticket identifier according to the ticket identifier in the original bill information; if the commercial paper information matches the original bill information, Perform step 202.
  • the ticket identifier is usually a ticket number.
  • the electronic receipt management system may query the banking system for the commercial paper information corresponding to the ticket identifier, such as an ECDS (Electronic Commercial Draft System), if the commercial paper information is successfully queried, and the If the commercial paper information matches the original ticket information filled in by the first user, step 202 may be performed; otherwise, the ticket issuance request of the first user may be rejected.
  • ECDS Electronic Commercial Draft System
  • the embodiment of the present invention is based on the commercial bill of the first user, and the electronic bill corresponding to the commercial bill is issued.
  • the electronic bill can be issued in various manners, for example, the electronic bill consistent with the commercial bill can be directly issued.
  • the commercial paper may also be transferred or pledged by the user to the electronic receipt management system, and the electronic receipt management system, as the biller, issues an electronic receipt that is equivalent to the commercial paper.
  • the ticket account generation process can be completed by the server in the ticket management system in the account table, thereby managing the user's electronic ticket through the ticket account.
  • the first block is the second block on the blockchain, based on the ticket header request value, the first ticket account, and the block header feature value of the first block in the blockchain in the electronic ticket management system.
  • the previous block, the second block is used to record the ticket issue event of the first user.
  • the electronic receipt management system may acquire the first block from the blockchain, and then acquire all the information in the block header of the first block, and obtain all the information in the block header of the first block.
  • the block header feature value of the first block, and acquiring event information of the ticket issuance request to be stored in the block body of the second block, and then performing event value calculation on the event information of the ticket issuance request and the first ticket account Obtaining a block body feature value of the second block, and further storing the block header feature value of the first block and the block body feature value of the second block (which may further include a version number, a difficulty value, and a timestamp) To the block header of the second block.
  • the embodiment of the present invention further stores the event information of the ticket issuance request and the first ticket account to the block body of the second block, thereby generating the second block.
  • the second block is related to the first block by the block header feature value of the first block, thereby achieving the purpose of concatenating the blocks in the block chain, and making the block in the block Any tampering of information can be detected by tracing the feature value of the block header of the previous block stored in the block header of the block, thereby ensuring the security of the transaction information.
  • the event information may include an event type (eg, a ticket issuance request event and a transaction request event) and asset information involved in the event, and the event information in the subsequent transaction process is the same.
  • an event type eg, a ticket issuance request event and a transaction request event
  • the message exchanged during the ticket transaction process may also carry signature information, which is obtained by the message sending user to sign the message.
  • the private key used by the user when signing is issued by the electronic ticket management system, and each user corresponds to a unique pair of keys, and the public key in the pair of keys is stored by the electronic ticket management system, thereby being available for electronic ticket management.
  • the system authenticates the user.
  • the process of pledge or transfer the commercial paper to the electronic receipt management system may also be used as a transaction process. Therefore, the ticket issuance request may also carry the signature information of the first user.
  • the electronic receipt management system may also perform eigenvalue calculation on the event information, the original ticket information, the first ticket account, and the signature information of the ticket issuance request to obtain the feature value of the block body, and then the zone Information such as the block body feature value, the block header feature value of the first block, and the like are stored to the block header of the second block; the electronic ticket system may also process event information of the ticket issuance request, original ticket information, the first ticket account, and the signature The information is stored to the block body of the second block.
  • the messages exchanged in the following ticket transaction process are similarly the same, and may also carry the signature information of the sending user to the message.
  • the block generation process can be completed by the server in the ticket management system on the blockchain, thereby recording the current ticket issuance event.
  • the step may be sent by the server in the electronic receipt management system to the gateway, and then the gateway sends the release success message to the first user, so that when the first user receives the release success message, View account information corresponding to the ticket account carried by the success message.
  • an embodiment of the present invention provides a flow chart of ticket issuance.
  • the original bill information input by the user in the electronic bill management system can be obtained, and the original bill information is reviewed through the process of querying the commercial bill information in step 202, and if the audit is passed, the bill can be The secondary issue event is written to the block to complete the release process. If the audit fails, the release is determined to be unsuccessful, and the user can be notified to restart the release process.
  • the above content is the issuance process of electronic bills.
  • the bill transaction process it also involves the process of bill transfer, bill discounting, etc.
  • the ticket transaction request of the first user When receiving the ticket transaction request of the first user, if the ticket transaction request is a full-note transaction request, perform a ticket transaction based on a message interaction with the first user and the second user.
  • the ticket transaction request refers to a request for a user to conduct a transaction with another user based on the electronic ticket held.
  • the ticket transaction request is a ticket transfer request or a ticket discount request.
  • the ticket transaction request may further carry transaction asset information of the request transaction and signature information of the first user for the ticket transaction request, where the transaction asset information is used to indicate the amount of assets to be traded by the first user in the current transaction, and the signature information may be
  • the electronic ticket management system stores the blockchain in the success of the transaction for verifying the identity of the first user when the transaction information is subsequently forensic.
  • the second user refers to a user other than the first user in the electronic ticket management system, and the two users can be determined according to the first user, for example, according to the second user who is filled in when the first user initiates the ticket transaction request.
  • the logo is determined.
  • the type of the ticket transaction request may be determined by the first ticket account carried by the ticket transaction request and the transaction asset information carried by the ticket transaction request.
  • the type of the ticket transaction request may be determined by the following method: the electronic ticket management system may query the asset information corresponding to the first ticket account according to the first ticket account carried by the ticket transaction request, and the amount of the asset corresponding to the asset information Comparing the amount of the transaction asset corresponding to the transaction asset information carried by the ticket transaction request, if the two are equal, determining a full-sized ticket transaction request of the type of the ticket transaction request, and then based on the relationship with the first user and the second user Message interaction, ticket transactions.
  • the electronic ticket management system can perform the ticket transaction process.
  • the ticket transaction process may be specifically: the electronic receipt management system sends a first receipt request message to the second user, where the first receipt request message is used to indicate the receipt of the first receipt account; when the first receipt confirmation message of the second user is received At the same time, it can be determined that the ticket transaction is successful; when the second sign rejection message of the second user is received, it can be determined that the ticket transaction fails.
  • the first receipt request message may further carry the first ticket account.
  • the second user Based on the first ticket account carried in the first receipt request, the second user can view the account information of the first ticket account and the like through the first ticket account, so that the first ticket account to be signed can be checked.
  • the first receipt confirmation message may carry the signature information of the first receipt confirmation message by the second user, and the signature information may be stored by the electronic receipt management system into the blockchain when the transaction is successful, for subsequent forensic transaction information. Verify the identity of the second user.
  • the second user may select whether to sign or not. If the signing is determined, the first signing confirmation message may be sent to the electronic ticket management system.
  • the ticket transaction process may be applied to the ticket transfer process.
  • the second user may also transfer the offline account to the first user at any time before or after the receipt to complete the discounting process.
  • the corresponding second ticket account may be generated for the second user in the account table, the second The bill account is used to identify the electronic bill that is signed by the second user.
  • the bill holder information in the account information of the second bill account may be the user identifier of the second user, and other information in the account information may not be temporarily Make settings or set to default values.
  • the electronic receipt management system when it receives the ticket transaction request, it can verify whether the ticket transaction request matches the ticket account according to the ticket account carried by the ticket transaction request, and if it matches, continue this time. The transaction, if it does not match, ends the transaction.
  • the electronic receipt management system may perform verification according to at least one item of the account information of the ticket account. For example, according to the asset information in the account information of the ticket account, whether the transaction asset information carried by the ticket transaction request matches the asset information is verified. For example, if the asset amount of the transaction asset information is not greater than the asset amount of the asset information, it indicates that the ticket transaction request is reasonable, and the ticket transaction request is determined to match the ticket account, otherwise it is determined that the two do not match. For another example, whether the request time of the ticket transaction request matches the expiration date can be verified according to the expiration date in the account information of the ticket account.
  • the electronic receipt management system can also perform verification according to the account status in the account information of the ticket account.
  • the account status is the normal holding status
  • the account status is outside, it can be determined that the two do not match.
  • the electronic bill management system may also initiate the bill bidding for the first user before the step of conducting the transaction.
  • the bill bidding process is: when the bill transaction request is determined to be a bill discount request, the electronic bill management system sends a bill bid message corresponding to the first bill account to each user in the electronic bill management system, and according to the bid feedback information, the first bid is The user with the highest bidding account account is the second user.
  • the electronic bill management system may generate a bill bidding message based on the first bill account carried in the bill discounting request, and the bill bidding message carries the first bill account, and may include the user identifier of the first user and the first bill. Asset information and expiration date in the account information of the account. Further, the electronic receipt management system may send the ticket bidding message to each user by means of pushing or the like. The electronic receipt management system may obtain feedback information of each user on the ticket bidding message in the bill bidding process, and the feedback information includes at least the amount information that the user promises to discount, so that the electronic bill management system can put the highest amount of promised cash. The user acts as the second user.
  • the ticket bidding process should be set with a bidding time, which can be set by the first user or the electronic ticket management system, but not later than the due date.
  • the user may send the ticket transaction request to the gateway in the electronic ticket management system through the client, and the gateway sends the ticket transaction request to the server in the ticket management system, so that the server is the user based on the ticket transaction request.
  • the ticket bidding may also be initiated by the gateway, and the second user is determined, and then the user identifier of the second user and the ticket transaction request of the first user are sent to the server.
  • the ticket account in the account table is updated, and a block for recording the ticket transaction of the first user and a block for recording the second user ticket transaction are generated on the blockchain.
  • the electronic receipt management system may update the ticket accounts of both parties in the account table when the ticket transaction is successful.
  • the electronic receipt management system can also generate blocks for recording ticket transactions.
  • the embodiment of the present invention does not limit the specific process of updating the ticket account and generating the block. For example, when the ticket transaction is successful, the electronic ticket management system may update the first ticket account in the account table and the second ticket account of the second user, and generate the third block and the fourth block on the blockchain. .
  • the third block is used to record the current ticket transaction event of the first user
  • the fourth block is used to record the current ticket cancellation event of the second user.
  • the electronic ticket management system may modify the ticket status of the account information of the first ticket account to the transferred status, thereby indicating that the first ticket account is identified.
  • the electronic ticket has been transferred, and the asset information in the account information of the generated second ticket account is set as the asset information corresponding to the original first ticket account (if the second ticket account has not been generated, it can also be generated at this time),
  • the account status in the account information of the second ticket account is the normal holding status.
  • the process of generating a block is the same as the process of generating a second block, and the block body of the third block can store event information of the ticket transaction request, the first ticket account, and the signature of the first user to the ticket transaction request.
  • the block header of the third block may store the block header feature value of the previous block and the block body feature value of the third block, etc.; the first sign may be stored in the block body of the fourth block Confirming the event information of the message, the second ticket account, and the signature information of the second user to the first receipt confirmation message, the block header of the fourth block may store the feature value of the block header of the previous block and the fourth block Block body feature value.
  • the ticket account update process and the block generation process involved in this step 206 can all be completed by a server in the electronic ticket management system.
  • the electronic receipt management system may send a corresponding transaction success message to the second user, and the transaction success message may carry the second ticket account corresponding to the second user after the transaction, or the second user.
  • the corresponding fourth ticket account enables the second user to view the signed ticket account.
  • the electronic receipt management system may further send a corresponding transaction success message to the first user, and the transaction success message may carry the first ticket account after the transaction, or the first ticket account and the third ticket account, so that the first ticket account is viewed.
  • the transaction success message may be sent to the gateway by a server in the electronic ticket management system, and then the gateway sends the transaction success message to the client where the user is located.
  • an embodiment of the present invention provides a ticket transfer flow chart.
  • the ticket management system checks the ticket transfer request of the first user, and if the check passes, generates a second ticket account of the second user, and Sending the ticket receipt request to the second user. If the second user agrees to sign, the ticket management system separately updates the ticket accounts of the first user and the second user, and generates a block for recording the transaction information, if the second user rejects Upon receipt, the ticket management system updates the receipt rejection message to the first ticket account.
  • an embodiment of the present invention provides a ticket discount flow chart.
  • the ticket management system initiates a ticket bidding when receiving the ticket discounting request of the first user, and after the second user is determined, the second user is verified, and if the verification passes, the second user is Generating a second ticket account, and sending the ticket receipt request to the second user. If the second user agrees to sign, the ticket management system separately updates the ticket accounts of the first user and the second user, and generates information for recording the transaction. In the block, if the second user refuses to sign, the ticket management system updates the sign rejection message to the first ticket account.
  • the electronic bill management system not only supports users to trade all the assets corresponding to their electronic bills, but also supports the users to trade some of the assets of the electronic bills (for example, the electronic bills held by a user)
  • the amount of assets is large, and some assets can be traded with other users, so that more users can trade with the user within the scope of asset capabilities).
  • the above steps 205-207 are related steps in the full-note transaction in the embodiment of the present invention.
  • the electronic receipt management system receives the first user
  • the ticket transaction request is a partial ticket transaction request
  • the third ticket account corresponding to the first user may be generated in the account table based on the transaction asset information carried in the partial ticket transaction request, and further to the second transaction request
  • the user sends a second signing request message, where the second signing request message is used to indicate that the part of the first bill account is signed.
  • the first ticket account carried by the ticket transaction request and the transaction asset information carried by the ticket transaction request may also be determined. For example, the following method may be used to determine: if the asset amount corresponding to the asset information is greater than the transaction asset amount corresponding to the transaction asset information, the ticket transaction request may be determined to be a partial ticket transaction request, in order to facilitate the signing process of the transaction parties when the transaction is successful,
  • the electronic receipt management system may generate a third ticket account corresponding to the first user in the account table.
  • the ticket holder information in the account information of the third ticket account may be the user identifier of the first user, and other information may be Temporarily not set.
  • the electronic receipt management system may send a second receipt request message to the second user, the second receipt request message carrying the first ticket account and the transaction asset information, so that the second user checks the part of the first ticket account to be signed.
  • the electronic receipt management system may update the ticket account and generate a block in the following manner: when the electronic receipt management system receives the second receipt confirmation message of the second user, in the account table Updating the first ticket account, the third ticket account, and the fourth ticket account of the second user, and generating a sixth block and a seventh block on the blockchain, wherein the sixth block is used to record the first user's book The secondary ticket transaction event, the seventh block is used to record the second ticket collection event of the second user.
  • the second receipt confirmation message may carry the signature information of the second receipt confirmation message by the second user, and the signature information may be stored in the blockchain by the ticket transaction system for the subsequent forensic transaction information when the transaction is successful. The identity of the second user is verified.
  • the transaction asset information carried by the partial ticket transaction request of the first user is 80, and the asset information of the first ticket account is 100.
  • the electronic receipt management system receives the second receipt confirmation message of the second user, the first The second user confirms the asset of the receipt 80. Therefore, the electronic receipt management system can modify the asset information of the first ticket account to 0, the account status to the transferred status, and the asset information of the third ticket account to 20, and the account status update.
  • the asset information of the fourth ticket account (which can be generated and set for the second user when receiving the partial ticket transaction request) is updated to 80, and the account status is updated to the normal holding state.
  • the block body of the sixth block may store event information of the partial ticket transaction request, the first ticket account and the third ticket account, and the signature information of the first user for the partial ticket transaction request, and the sixth
  • the block header feature value of the previous block and the block body feature value of the sixth block may be stored in the block header of the block;
  • the event information of the second sign receipt confirmation message may be stored in the block body of the seventh block,
  • the fourth bill account and the second user's signature information for the second sign confirmation message may be stored in the block header of the seventh block and the block header feature value of the last block and the block body feature value of the seventh block.
  • the second user may refuse to sign a part of the first ticket account.
  • the processing manner of the electronic ticket management system is not specifically limited in the embodiment of the present invention.
  • the electronic receipt management system receives the second receipt rejection message of the second user, the third ticket account is deleted from the account table.
  • the electronic receipt management system can maintain the original first ticket account.
  • the electronic ticket management system can also delete the fourth ticket account from the account list.
  • an embodiment of the present invention provides a bill splitting flowchart.
  • the ticket account of the initiator is A
  • the remaining ticket account of the initiator is B
  • the ticket account of the receiver is C, for example, when the electronic ticket management system determines that the ticket transaction request is a full bill.
  • the above-mentioned ticket transaction process involves the interaction between users, and the actual ticket transaction process may also involve the completion of the redemption process for the first user by the electronic ticket management system.
  • the bill redemption process is: when the electronic bill management system detects that the first bill account reaches the redemption period, sending a bill redemption request to the first user, and if the first user confirms the redemption, returning the redemption confirmation message, when receiving the first
  • the user may redeem the asset corresponding to the first ticket account, and when the redemption process is completed, update the first ticket account in the account table, and based on the redemption confirmation message and the previous block
  • the block header feature value generates a fifth block, and then sends a redemption success message to the first user.
  • the redemption confirmation message may carry the signature information of the redemption confirmation message by the first user, and the signature information may be stored in the blockchain by the ticket transaction system when the redemption is successful, and used for verification of the subsequent forensic transaction information.
  • the identity of a user may carry the signature information of the redemption confirmation message by the first user, and the signature information may be stored in the blockchain by the ticket transaction system when the redemption is successful, and used for verification of the subsequent forensic transaction information. The identity of a user.
  • an embodiment of the present invention provides a bill redemption flow chart.
  • the electronic ticket management system can periodically detect the expiration date of each bill account, and determine whether the current date matches the redemption period according to the expiration date (not Limited to the expiration date or the first ten days of the expiration date, if it is matched, it is determined that the first bill account reaches the redemption period, and the electronic receipt management system may send a bill redemption request to the first user, the bill redemption request carrying the first bill Account.
  • the account information of the first ticket account may be checked and a redemption confirmation message is sent to the electronic ticket management system.
  • the electronic receipt management system When the electronic receipt management system receives the redemption confirmation message, the first user may directly pay the amount of the asset corresponding to the current first ticket account. After the redemption is successful, the commercial ticket transferred by the first user to the electronic receipt management system shall be managed by the electronic receipt. The system is all.
  • the electronic receipt management system may first query the original receipt information from the blockchain according to the first ticket account, and identify the ticket according to the original ticket information. The actual arrears of the commercial paper are inquired, the assets are requested from the actual debtor, and the requested assets are redeemed to the first user.
  • the electronic receipt management system may modify the status of the ticket in the account information of the first ticket account to the redeemed state in the account table, and generate a fifth block, where the block body of the fifth block may
  • the event information of the redemption confirmation message, the first ticket account, and the signature information of the first user to the redemption confirmation message may be stored, and the block header feature value of the previous block and the fifth block may be stored in the block header of the fifth block.
  • the block body feature value may be stored.
  • the electronic receipt management system may also perform a verification process, for example, when the electronic receipt management system detects that the first ticket account reaches the redemption period, the first ticket is verified. Whether the account meets the redemption condition, if yes, continue the transaction, if not, the transaction is ended.
  • the redemption condition may include, but is not limited to, the account status in the account information of the first ticket account is a normal holding status, the asset information is not 0, or the due date is not earlier than the current date.
  • the electronic receipt management system may also record the account to be signed or the account to be redeemed, that is, when the electronic receipt management system receives any user to receive the receipt of the receipt account
  • the sign rejection message is received, the user's sign rejection message is updated to the account to be signed account in the account table; or, when the electronic ticket management system receives the redemption rejection message of any user to treat the bill account, the user's redemption is rejected.
  • the message is updated to the bill to be redeemed in the account table.
  • the receipt rejection message may be stored in the transaction result in the account information of the ticket account.
  • the gateway in the electronic receipt management system may perform the verification of the redemption period, trigger the redemption process, and send the redemption initiation message to the server.
  • the verification process may be performed.
  • the ticket redemption request is sent to the gateway, and the gateway sends the ticket redemption request to the client where the first user is located, and the client may send the first user's redemption confirmation message or redemption rejection message to the gateway, and the gateway will The message sent by the first user is sent to the server, so that the server completes the redemption process based on the message.
  • the first bill account corresponding to the first user may be generated in the account table, based on the first user's bill issuance request, the first bill account, and the first in the blockchain.
  • the block header feature value of the block can generate a second block.
  • the ticket transaction flow is illustrated by taking FIG. 10B as an example.
  • the core enterprise H purchases a batch of goods of the first-tier supplier N, and if the payment has not been made, the commercial paper can be opened through the bank note system, and the commercial paper receipt request is sent from the bank note system to the first-tier supplier N.
  • the first-tier supplier N can sign through the bank online banking to obtain a commercial paper.
  • the first-level supplier N sends a ticket issuance request to the electronic receipt management system, and when the gateway in the electronic receipt management system receives the ticket issuance request, it can apply to the bank receipt system for the holding of the commercial instrument of the first-level supplier N.
  • someone changed to a gateway which is equivalent to the first-level supplier N to transfer the commercial paper to the gateway.
  • the electronic ticket management system issues electronic tickets for it, and writes the issue event to the blockchain to determine the success of the issue.
  • the Tier 1 supplier N can transfer, discount or split the electronic bill through the electronic bill management system.
  • the gateway of the electronic receipt management system can automatically detect the redemption period of the electronic receipt. Once the redemption period is reached, the gateway can initiate a redemption process to redeem the assets corresponding to the electronic receipt for the primary supplier N.
  • the above transaction process is performed based on the billing node of each user on the bank side and the billing node of the billing node on the blockchain platform side, as shown in FIG. 10C, the commercial bill is signed, the commercial bill is pledge, and the transfer is made.
  • the process of electronic bills and the like corresponds to the interaction between the bill accounts of the users of both parties.
  • the subsequent circulation links can be independent of the original electronic commercial bill of exchange system. Users do not have to own online banking, and can also transfer or discount electronic bills on the electronic billing system.
  • the amount of the asset at the time may be the amount of any asset held by the user, and the user who conducts the transaction is not limited to the enterprise user, the individual user, and the bank user, etc., which makes the electronic ticket transaction process less restrictive, and therefore has a strong Liquidity.
  • the bills are traded in the form of social communication.
  • the electronic bills can be expanded by the core enterprise H and the first-tier supplier N, and the business partner of the N is the secondary supplier M. A slice of the amount and payment of any amount.
  • any node with electronic bill resources can become a catalyst for asset circulation (such as banks, core companies, suppliers, etc. and bill exchanges that can accept C-ticket transactions), the entire transaction process is highly open and driven. The efficiency of asset circulation.
  • asset circulation such as banks, core companies, suppliers, etc. and bill exchanges that can accept C-ticket transactions
  • the entire transaction process is highly open and driven. The efficiency of asset circulation.
  • using the characteristics of the blockchain decentralized storage can be achieved, and the transaction information can also be stored in multiple nodes, thereby effectively avoiding the falsification or rejection of transaction information and traceability throughout the process.
  • the embodiment of the present invention provides a platform for the user to freely trade the electronic ticket.
  • the user can freely trade based on the message interaction between the first user and the second user.
  • the transaction is successful, not only the ticket account in the account table can be updated, but also the block for recording the transaction is generated on the blockchain, further ensuring the security and reliability of the transaction information.
  • the embodiment of the present invention provides a specific process of updating a ticket account and generating a block.
  • the ticket accounts corresponding to the first user and the second user respectively the ticket accounts of both parties of the transaction can be reasonably managed.
  • the third block for recording the first user's current ticket transaction event be generated, but also the fourth block for recording the second user's current ticket receipt event, so that both parties can be reasonably recorded.
  • the respective roles in this transaction and fully embodies the transaction process of the electronic ticket from the first user to the second user.
  • the embodiment of the present invention provides a specific method for splitting the electronic ticket.
  • the specific splitting process is: when receiving the ticket transaction request, determining the type of the ticket transaction request, if Is a full bill transaction request, based on the message interaction with the first user and the second user, performing a ticket transaction; if it is a partial ticket transaction request, generating a first based on the transaction asset information carried in the partial ticket transaction request.
  • the third bill account corresponding to the user when the transaction is successful, the transaction assets in the original first bill account can be transferred to the fourth bill account of the second user, and the remaining assets can be transferred to the third bill account, and then the
  • the transaction information is stored in the blockchain, which not only completely records the process of the original electronic bill being traded, but also splits into two new electronic bills, and ensures the security of the transaction information.
  • the embodiment of the present invention provides a simple processing method of the electronic ticket management system when the user refuses to sign the transaction assets in the first ticket account, and the method can save the original first by deleting the third ticket account. Account information for the ticket account.
  • the user can send a ticket bid message to each user of the electronic ticket management system. And the user with the highest bid is the second user who deals with the first user.
  • the embodiment of the present invention can also intelligently detect whether the first bill account reaches the redemption period, and when the first bill account reaches the redemption period, actively redeem the asset for the first user, thereby intelligently and humanizedly managing the first user.
  • Electronic bills can also intelligently detect whether the first bill account reaches the redemption period, and when the first bill account reaches the redemption period, actively redeem the asset for the first user, thereby intelligently and humanizedly managing the first user.
  • the message exchanged in the ticket transaction process also carries the signature information obtained by the message sending user to sign the message, so that the signature of the user can be obtained according to the signature of the user.
  • Information is fair and valid to verify user identity.
  • the embodiment of the present invention may further query the corresponding commercial bill information according to the bill identifier in the original bill information, and when the two information match, the first user is issued. Electronic bills.
  • the embodiment of the present invention may further verify whether the account information of the ticket account matches the ticket transaction request when receiving the ticket transaction request, or Verification is performed when it is detected that the ticket account has reached the redemption period.
  • the embodiment of the present invention can store the sign rejection message or the redemption rejection message to the corresponding ticket account, thereby explicitly recording the failed transaction and preventing the malicious user from refusing.
  • FIG. 11 is a block diagram of an electronic receipt management apparatus according to an embodiment of the present invention.
  • the device specifically includes:
  • the receiving module 1101 is configured to receive a ticket issuance request of the first user, where the ticket issuance request carries original bill information;
  • the account generating module 1102 is configured to generate a first bill account corresponding to the first user based on the original bill information, and store the account information of the first bill account into an account table in the electronic bill management system;
  • the block generating module 1103 is configured to generate a second block, where the first block is a block, based on the ticket issue request, the first ticket account, and the block header feature value of the first block in the blockchain in the electronic receipt management system. a previous block of the second block on the chain, the second block is used to record a ticket issue event of the first user;
  • the sending module 1104 is configured to send a release success message to the first user, where the release success message carries the first ticket account.
  • the embodiment of the present invention generates a first ticket account corresponding to the first user not only in the account table but also based on the first user's ticket issuance request, the first ticket account, and the blockchain, based on the original bill information of the first user.
  • the block header feature value of the first block generates a second block, which can not only manage the account information through the account table, but also can tamper with any information in the block based on the association relationship between the front and rear blocks in the blockchain. Time can be detected through the next block to prevent malicious users from tampering or refusing the issued electronic notes, thus ensuring the security and reliability of the transaction information.
  • the device further includes: a transaction module 1105 and an account update module 1106,
  • the transaction module 1105 is configured to: when receiving the ticket transaction request of the first user, perform a ticket transaction based on a message interaction with the first user and the second user, and the ticket transaction request carries the first ticket account;
  • the account update module 1106 is configured to update the ticket account in the account table when the ticket transaction is successful, and generate a block for recording the ticket transaction of the first user on the blockchain and used to record the second user ticket. Block of trading;
  • the sending module 1104 is configured to send a transaction success message to the second user.
  • the sending module 1104 is configured to send a first sign-off request message to the second user, where the first sign-off request message is used to instruct the second user to sign the first bill account;
  • the transaction module 1105 is configured to: when receiving the first receipt confirmation message of the second user, determine that the ticket transaction is successful; and when receiving the first receipt rejection message of the second user, determine that the ticket transaction fails.
  • the account update module 1106 is configured to update the first ticket account in the account table and the second ticket account of the second user when the ticket transaction is successful;
  • the block generating module 1103 is configured to generate a third block and a fourth block on the blockchain, the third block is used to record the current ticket transaction event of the first user, and the fourth block is used to record the second block. The user's bill receipt event.
  • the transaction module 1105 is configured to: based on the message between the first user and the second user, if the ticket transaction request is a full-ticket transaction request when receiving the ticket transaction request of the first user Interact and conduct ticket transactions.
  • the account generating module 1102 is configured to: when receiving the ticket transaction request of the first user, if the ticket transaction request is a partial ticket transaction request, based on the transaction asset information carried in the partial ticket transaction request, In the account table, a third ticket account corresponding to the first user is generated; the sending module 1104 is configured to send a second signing request message to the second user, where the second signing request message is used to instruct the second user to sign part of the first bill account.
  • the account update module 1106 is configured to: when receiving the second receipt confirmation message of the second user, update the first ticket account, the third ticket account, and the fourth ticket account of the second user in the account table; a generating module 1103, configured to generate a sixth block and a seventh block on the blockchain, where the sixth block is used to record the current ticket transaction event of the first user, and the seventh block is used to record the second user This bill is signed for the event.
  • the account update module 1106 is further configured to: when receiving the second sign rejection message of the second user, delete the third ticket account from the account table.
  • the ticket transaction request is a ticket transfer request or a ticket discount request.
  • the sending module 1104 is further configured to: when the ticket transaction request is a ticket discounting request, send a ticket bidding message corresponding to the first ticket account to each user in the electronic ticket management system; the transaction module 1105 is further used to The user who has the highest bid for the first bill account is used as the second user.
  • the device further includes: a redemption module 1107, configured to: when detecting that the first ticket account reaches the redemption period, to the first The user sends a ticket redemption request; when receiving the redemption confirmation message of the first user, the first user is redeemed for the asset corresponding to the first ticket account; when the redemption process is successful, the first ticket account is updated in the account table, based on the redemption confirmation The message and the block header feature value of the previous block generate a fifth block; a redemption success message is sent to the first user.
  • a redemption module 1107 configured to: when detecting that the first ticket account reaches the redemption period, to the first The user sends a ticket redemption request; when receiving the redemption confirmation message of the first user, the first user is redeemed for the asset corresponding to the first ticket account; when the redemption process is successful, the first ticket account is updated in the account table, based on the redemption confirmation The message and the block header feature value of the previous block generate a fifth block; a redemption success message is sent to the first user.
  • the account update module 1106 is configured to modify the account status in the account information of the first ticket account in the account table according to the transaction process of the ticket transaction; wherein the account status includes the transferred status, Discounted status, redeemed status, and normal holding status.
  • the message exchanged in the ticket transaction process also carries the signature information obtained by the message sending user to sign the message.
  • the device further includes:
  • the query module 1108 is configured to query the commercial paper information corresponding to the ticket identifier according to the ticket identifier in the original ticket information;
  • the account generating module 1102 is further configured to: if the commercial paper information matches the original ticket information, perform the step of generating a first ticket account corresponding to the first user based on the original ticket information.
  • the device further includes:
  • the verification module 1109 is configured to, when receiving the ticket transaction request, verify whether the ticket transaction request matches the ticket account according to the ticket account carried in the ticket transaction request, and if yes, continue the transaction, if not, terminate the transaction Transaction; or,
  • the verification module 1109 is further configured to: when it is detected that the first bill account reaches the redemption period, verify whether the first bill account satisfies the redemption condition, and if yes, continue the transaction, and if not, terminate the transaction.
  • the account update module 1106 is further configured to update the user's sign rejection message to the to-be-signed bill account in the account table when receiving the sign rejection message of any user to sign the receipt account; or ,
  • the account update module 1106 is further configured to update the user's redemption rejection message to the to-be-paid bill account in the account table when receiving the redemption rejection message of any user to treat the bill account.
  • the electronic receipt management device provided by the above embodiment is only exemplified by the division of each functional module. In actual application, the function distribution can be completed by different functional modules as needed. The internal structure of the device is divided into different functional modules to perform all or part of the functions described above.
  • the electronic ticket management apparatus and the electronic ticket management method embodiment provided by the foregoing embodiments are in the same concept, and the specific implementation process is described in detail in the method embodiment, and details are not described herein again.
  • FIG. 16 is a block diagram of an electronic receipt management apparatus 1600 according to an embodiment of the present invention.
  • device 1600 can be provided as a server.
  • apparatus 1600 includes a processing component 1622 that further includes one or more processors, and memory resources represented by memory 1632 for storing instructions executable by processing component 1622, such as an application.
  • An application stored in memory 1632 can include one or more modules each corresponding to a set of instructions.
  • processing component 1622 is configured to execute instructions to perform the methods performed by the electronic ticket management system of the above-described embodiments.
  • Apparatus 1600 can also include a power supply component 1626 configured to perform power management of apparatus 1600, a wired or wireless network interface 1650 configured to connect apparatus 1600 to the network, and an input/output (I/O) interface 1658.
  • Apparatus 1600 may operate based on an operating system stored in the memory 1632, for example, Windows Server TM, Mac OS X TM , Unix TM, Linux TM, FreeBSD TM or the like.
  • non-transitory computer readable storage medium comprising instructions, such as a memory including instructions executable by a processor in a server to perform the electronic ticket management method of the above embodiments .
  • the non-transitory computer readable storage medium may be a ROM, a random access memory (RAM), a CD-ROM, a magnetic tape, a floppy disk, and an optical data storage device.
  • the embodiment of the present invention further provides a storage medium, where the storage medium stores at least one instruction, at least one program, a code set or a set of instructions, the at least one instruction, the at least one program, the code set or The instruction set is loaded and executed by the processor to implement the electronic ticket management method in the above embodiment.
  • the storage medium may be a read only memory, a magnetic disk or an optical disk or the like.

Landscapes

  • Business, Economics & Management (AREA)
  • Accounting & Taxation (AREA)
  • Engineering & Computer Science (AREA)
  • Finance (AREA)
  • General Physics & Mathematics (AREA)
  • Strategic Management (AREA)
  • Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Development Economics (AREA)
  • Economics (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Marketing (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Abstract

本发明实施例公开了一种电子票据管理方法、装置及存储介质，属于网络技术领域。该方法包括：接收第一用户的票据发行请求，票据发行请求携带原始票据信息；基于原始票据信息，生成与第一用户对应的第一票据账户，并将第一票据账户的账户信息存储至电子票据管理系统中的账户表；基于票据发行请求、第一票据账户以及电子票据管理系统中区块链中第一区块的区块头特征值，生成第二区块，第一区块为区块链上第二区块的上一个区块，第二区块用于记录第一用户的票据发行事件；向第一用户发送发行成功消息，发行成功消息携带第一票据账户。本发明实施例保证了交易信息的安全性和可靠性。

Description

电子票据管理方法、装置及存储介质
本申请要求于2017年03月10日提交中国国家知识产权局、申请号为201710142464.X、发明名称为“电子票据管理方法及装置”的中国专利申请的优先权，其全部内容通过引用结合在本申请中。
技术领域
本发明实施例涉及网络技术领域，特别涉及一种电子票据管理方法、装置及存储介质。
背景技术
随着网络技术的发展，衍生了如电子票据、电子凭证等网络产物。电子票据是指以数据电文的形式存储的票据。电子票据主要应用于商业贸易过程中，可在商业贸易过程中进行转让、贴现或质押等。例如，企业用户A从企业用户B处购买了一批商品，虽然企业用户A尚未向企业用户B支付相应的款项，但企业用户B依然可以通过网上银行获取一张电子票据，该电子票据记录了企业用户A与企业用户B之间的交易信息，包括欠款信息、票据持有人信息、开票日期和到期日等。企业用户B作为该电子票据的持票人，可以通过网上银行对该电子票据进行转让、贴现或质押。
在实现本发明实施例的过程中，发明人发现相关技术至少存在以下问题：
由于网络本身存在被恶意用户侵入的安全隐患，电子票据的交易信息很可能被恶意篡改，导致电子票据的安全性和可靠性差。
发明内容
为了解决相关技术中存在的电子票据的安全性和可靠性差的问题，本发明实施例提供了一种电子票据管理方法、装置及存储介质。所述技术方案如下：
一方面，提供了一种电子票据管理方法，所述方法应用于电子票据管理系统，所述方法包括：
接收第一用户的票据发行请求，所述票据发行请求携带原始票据信息；
基于所述原始票据信息，生成与所述第一用户对应的第一票据账户，并将所述第一票据账户的账户信息存储至所述电子票据管理系统中的账户表；
基于所述票据发行请求、所述第一票据账户以及所述电子票据管理系统中区块链中第一区块的区块头特征值，生成第二区块，所述第一区块为所述区块链上所述第二区块的上一个区块，所述第二区块用于记录所述第一用户的票据发行事件；
向所述第一用户发送发行成功消息，所述发行成功消息携带所述第一票据账户。
一方面，提供了一种电子票据管理装置，所述装置包括：
接收模块，用于接收第一用户的票据发行请求，所述票据发行请求携带原始票据信息；
账户生成模块，用于基于所述原始票据信息，生成与所述第一用户对应的 第一票据账户，并将所述第一票据账户的账户信息存储至电子票据管理系统中的账户表；
区块生成模块，用于基于所述票据发行请求、所述第一票据账户以及所述电子票据管理系统中区块链中第一区块的区块头特征值，生成第二区块，所述第一区块为所述区块链上所述第二区块的上一个区块，所述第二区块用于记录所述第一用户的票据发行事件；
发送模块，用于向所述第一用户发送发行成功消息，所述发行成功消息携带所述第一票据账户。
一方面，提供了一种用于电子票据管理的装置，包括:一个或多个处理器、存储器，所述存储器用于存储至少一条指令、至少一段程序、代码集或指令集，所述至少一条指令、所述至少一段程序、所述代码集或指令集由所述处理器加载并执行以下操作：
接收第一用户的票据发行请求，所述票据发行请求携带原始票据信息；
基于所述原始票据信息，生成与所述第一用户对应的第一票据账户，并将所述第一票据账户的账户信息存储至电子票据管理系统中的账户表；
基于所述票据发行请求、所述第一票据账户以及所述电子票据管理系统中区块链中第一区块的区块头特征值，生成第二区块，所述第一区块为所述区块链上所述第二区块的上一个区块，所述第二区块用于记录所述第一用户的票据发行事件；
向所述第一用户发送发行成功消息，所述发行成功消息携带所述第一票据账户。
一方面，提供了一种存储介质，所述存储介质中存储有至少一条指令、至少一段程序、代码集或指令集，所述至少一条指令、所述至少一段程序、所述代码集或指令集由所述处理器加载并执行以实现如上所述的电子票据管理方法。
本发明实施例通过基于第一用户的原始票据信息，不仅在账户表中生成与第一用户对应的第一票据账户，而且基于第一用户的票据发行请求、第一票据账户和区块链中第一区块的区块头特征值，生成第二区块，不仅能够通过账户表管理账户信息，而且能够基于区块链中前后区块之间的关联关系，使得区块中任一信息被篡改时都能通过下一区块而检测到，避免恶意用户篡改或抵赖所发行的电子票据，从而保证了交易信息的安全性和可靠性。
附图说明
为了更清楚地说明本发明实施例中的技术方案，下面将对实施例描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。
图1是本发明实施例提供的一种电子票据管理的实施环境示意图；
图2是本发明实施例提供的一种电子票据管理的方法的示意图；
图3是本发明实施例提供的一种原始数据信息填写界面；
图4是本发明实施例提供的一种注册界面；
图5是本发明实施例提供的一种用户注册流程图；
图6是本发明实施例提供的一种票据发行流程图；
图7是本发明实施例提供的一种票据转让流程图；
图8是本发明实施例提供的一种票据贴现流程图；
图9是本发明实施例提供的一种票据拆分流程图；
图10A是本发明实施例提供的一种票据兑付流程图；
图10B是本发明实施例提供的一种票据交易流程图；
图10C是本发明实施例提供的一种票据交易流程图；
图11是本发明实施例提供的一种电子票据管理装置的框图；
图12是本发明实施例提供的一种电子票据管理装置的框图；
图13是本发明实施例提供的一种电子票据管理装置的框图；
图14是本发明实施例提供的一种电子票据管理装置的框图；
图15是本发明实施例提供的一种电子票据管理装置的框图；
图16是本发明实施例提供的一种电子票据管理装置1600的框图。
具体实施方式
为使本发明实施例的目的、技术方案和优点更加清楚，下面将结合附图对本发明实施方式作进一步地详细描述。
图1是本发明实施例提供的一种电子票据管理方法的实施环境示意图。如图1所示，该实施环境为电子票据管理系统，且该电子票据管理系统和该电子票据管理系统中的用户101上可分别存储相同的一条区块链，该区块链由多个区块组成，每个区块均存储有不同的信息，且每条信息在每个区块上按照时间顺序进行存储。在本发明实施例中，每个区块可以存储一次交易涉及的信息。该电子票据管理系统用于管理用户101的电子票据，如，发行或交易电子票据，并在发行和交易过程中将交易信息存储至区块链上的区块。用户101用于与电子票据管理系统进行交互，从而发行电子票据或与其他用户进行交易，该用户101可以具体为供应商用户、个人用户、企业用户或银行用户等等。在交易过程中，用户101所使用的电子设备可以为笔记本电脑、台式电脑、智能手机等等。
事实上，该电子票据管理系统可以包括至少两个节点，至少两个节点可以包括至少两个服务器102，还可以包括网关103等，该电子票据管理系统可以为DAM(Digit Asset Management，电子票据管理系统)。其中，该至少两个服务器102用于基于区块链技术管理各个用户的电子票据，网关103用于提供用户101与DAM之间的访问服务，也可以作为本实施环境中的记账节点，用于存储交易过程中的交易信息，并定时进行更新，使得实施环境中的其他节点可以共享交易信息，从而使得各个节点可以为交易信息提供一致性证明，提高了交易信息的安全性，如，当一次票据转让过程完成时，该记账节点可以根据各个节点的节点标识(如网络地址)将交易信息共享至各个节点的区块链上。服务器102可以通过网关103与用户101进行交互，从而管理用户101的电子票据。在电子票据管理系统实际运行过程中，还涉及到与银行系统104的交互，银行系统104用于提供真实的商业票据信息，从而验证用户所提交的原始票据信息的真实性。
该电子票据管理系统除了存储一条区块链外，还可以存储账户表，该账户表中存储了至少一个用于标识某电子票据的票据账户和对应的描述该电子票据的账户信息，例如账户状态、账户余额等，该账户表可根据交易对应更新，因而实现了在交易过程中动态更新电子票据的方法。
事实上，为保证账户信息的安全性，账户表中的账户信息也可以随着每 次交易过程存储至区块链上，也即是所述账户表存储于区块链中。由于区块链中的信息不可更改，因此，交易过程中每次需要更新账户信息时无需修改原账户信息，而是将更新的账户信息存储至新的区块。
需要说明的是，上述电子票据系统可以基于HTTP(HyperText Transfer Protocol，超文本传输协议)协议的API(Application Programming Interface，应用程序编程接口)接口，该API接口采用双向证书验证，并支持JSON(JavaScript Object Notation，JavaScript对象标记语言)数据的POST调用，并统一返回JSON数据。为了避免多字符集编码造成的异常，该电子票据系统的字符编码可以统一使用UTF-8(8-bit Unicode Transformation Format，8字节统一码传输格式)编码。其中，JavaScript为一种直译式脚本语言。POST调用为HTTP协议中的重要的组成部分，用来向目的服务器发送更新请求。该电子票据管理系统中还可以运用ECDSA(Elliptic Curve Digital Signature Algorithm，椭圆曲线数字签名算法)等签名算法，对交易时用户发起的消息进行签名。该签名算法可分为两部分参数：第一部分为业务参数，该业务参数需要发起用户用自己的私钥进行签名，DAM平台采用用户的公钥进行验证。第二部分为协议参数，该协议参数需要发起https请求方(网关/有研发能力的参与方)使用自己的私钥进行签名，DAM平台采用请求方的公钥进行验证。
图2是本发明实施例提供的一种电子票据管理的方法的示意图。参见图2，该方法应用于电子票据管理系统，具体包括：
201、接收第一用户的票据发行请求，票据发行请求携带原始票据信息。
其中，该第一用户是指在该电子票据管理系统注册的任一用户，不限于个人用户、企业用户或银行用户等。原始票据信息是指用户所持有的商业票据的票据信息，至少包括该原始票据信息的票据标识，还可以包括该商业票据的资产信息、开票日期、到期日、用户的银行账号、开户银行和发行资产信息等，参见图3，本发明实施例提供了一种原始数据信息填写界面，该原始数据信息填写界面提供了填写上述多项票据信息的输入框等，以便在用户确认提交后从各个输入框中获取用户所输入的信息，进而发送至电子票据管理系统。
本发明实施例中，为了确保电子票据交易的安全性，可以采用交易实名制，任一用户在注册该电子票据管理系统时可以提供该用户的身份信息，如，个人用户可以提供自身的身份证号，企业用户可以提供自身的企业代码。用户可以在电子票据管理系统提供的注册界面上填写注册信息，并向电子票据管理系统提交注册请求。参见图4，本发明实施例提供了一种注册界面，该注册界面显示有企业全称输入框、组织机构代码输入框、银行账号输入框、开户银行输入框、企业联系人输入框、企业电话输入框及联系地址输入框，基于用户在各个输入框中输入的信息，可获取到“企业全称为供应商B、组织机柜代码为0526634-7、企业联系人为王五、联系电话为18888833377、联系地址为天津市A区B路”等用户身份信息、以及“银行账号为621111111888823333、开户银行为建设银行”等银行账户信息等。参见图5，本发明实施例提供了一种用户注册流程图。当电子票据管理系统接收到用户的注册请求时，可以到公安机关等验证注册请求中携带的身份信息是否真实，如果不真实，则拒绝该用户注册，如果真实，则允许该用户注册，并为该用户生成一对密钥，并将该对密钥的私钥返回给用户，将公钥由电子票据管理系统存储，以验证用户身份。
在实际场景中，该第一用户的票据发行请求可以由用户在电子票据管理系统所提供的客户端或网页上触发生成，并向电子票据管理系统的网关发送，使得该网关能够接收到第一用户的票据发行请求。由于网关可以具有校验和隔离的作用，因而能够提高信息的安全性。
202、基于原始票据信息，生成与第一用户对应的第一票据账户，并将第一票据账户的账户信息存储至电子票据管理系统中的账户表。
该步骤中，第一票据账户用于标识为第一用户发行的电子票据，其可以为用于唯一标识该电子票据的特征值，例如哈希值等，该第一票据账户的账户信息用于描述该电子票据，不限于票据持有人信息、资产信息、开票日期、到期日、账户状态、交易结果等信息。其中，票据持有人信息、资产信息、开票日期、到期日可以直接根据原始票据信息得到；交易结果可以在后续的交易过程中进行添加，如，签收拒绝消息；账户状态可以设置为正常持有状态。需要说明的是，电子票据管理系统可以根据票据交易的交易流程，对账户表中第一票据账户的账户信息中的账户状态进行修改，该账户状态包括已转让状态、已贴现状态、已兑付状态和正常持有状态等。
事实上，为了确保该商业票据的真实性，在步骤201之后，电子票据管理系统可以根据原始票据信息中的票据标识，查询票据标识对应的商业票据信息；如果商业票据信息与原始票据信息匹配，执行本步骤202。其中，该票据标识通常为票据编号。在查询时，电子票据管理系统可以到银行系统查询与该票据标识对应的商业票据信息，该银行系统如ECDS(Electronic Commercial Draft System，电子汇票管理系统)，如果成功查询到商业票据信息、且该商业票据信息与第一用户所填写的原始票据信息匹配，则可以执行步骤202，否则，可以拒绝第一用户的票据发行请求。
需要说明的是，本发明实施例是基于第一用户的商业票据，发行该商业票据对应的电子票据，在发行时可以采用多种方式，例如，既可以直接发行与该商业票据一致的电子票据，也可以由用户将商业票据转让或质押给电子票据管理系统，由电子票据管理系统作为开票人，发行与该商业票据对等的电子票据。
在实际场景中，票据账户的生成过程可以由票据管理系统中的服务器在账户表中完成，从而通过票据账户管理用户的电子票据。
203、基于票据发行请求、第一票据账户以及电子票据管理系统中区块链中第一区块的区块头特征值，生成第二区块，第一区块为区块链上第二区块的上一个区块，第二区块用于记录第一用户的票据发行事件。
该步骤中，电子票据管理系统可以从区块链中获取第一区块，然后获取第一区块的区块头中的所有信息，并基于该第一区块的区块头中的所有信息，得到第一区块的区块头特征值，并获取将要存入第二区块的区块主体中的票据发行请求的事件信息，然后对该票据发行请求的事件信息及第一票据账户进行特征值计算，得到第二区块的区块主体特征值，进而，将第一区块的区块头特征值、第二区块的区块主体特征值(还可以包括版本号、难度值和时间戳)存储至第二区块的区块头。本发明实施例还将票据发行请求的事件信息和第一票据账户存储至第二区块的区块主体，从而生成第二区块。采用该种处理方式，使得第二区块与第一区块通过第一区块的区块头特征值相关，因而实现了将区块链中的区块串联起来的目的，且使得对区块中任何信息的篡改，均能够通过对区块的区块头中所存储的上一个区块的区块头特征值的追溯而检测到，从而保证了交易信息的安全性。
其中，事件信息可以包括事件类型(如，票据发行请求事件和交易请求事件)和本次事件涉及的资产信息，后续交易过程中的事件信息与之同理。
需要说明的是，为了方便后续取证交易信息、防止恶意用户抵赖或篡改交易信息，票据交易过程中所交互的消息还可以携带签名信息，该签名信息由消息发送用户对消息进行签名得到。用户在签名时所使用的私钥是由电子票据管理系统发放，每个用户都对应唯一的一对密钥，该对密钥中的公钥由电子票据管理系统存储，从而可供电子票据管理系统验证用户身份。该步骤中，商业票据质押或转让给电子票据管理系统的过程也可以作为一次交易过程，因此，票据发行请求也可以携带该第一用户的签名信息。在生成第二区块时，电子票据管理系统也可以对票据发行请求的事件信息、原始票据信息、第一票据账户和该签名信息进行特征值计算，得到区块主体特征值，进而将该区块主体特征值、第一区块的区块头特征值等信息存储至第二区块的区块头；电子票据系统还可将票据发行请求的事件信息、原始票据信息、第一票据账户和该签名信息均存储至第二区块的区块主体。以下票据交易过程中所交互的消息同理，也可以携带发送用户对该消息的签名信息。
在实际场景中，区块生成过程可以由票据管理系统中的服务器在区块链上完成，从而记录本次票据发行事件。
204、向第一用户发送发行成功消息，发行成功消息携带第一票据账户。
在实际场景中，该步骤可以由电子票据管理系统中的服务器将发行成功消息发送至网关，再由网关将发行成功消息发送至第一用户，以使第一用户接收到发行成功消息时，能够通过发行成功消息携带的票据账户对应的查看账户信息。
基于上述发行过程，参见图6，本发明实施例提供了一种票据发行流程图。该票据发行流程中，可获取用户在电子票据管理系统中所输入的原始票据信息，并通过步骤202的查询商业票据信息的过程，对该原始票据信息进行审核，如果审核通过，则可以将本次发行事件写入区块，从而完成发行过程，如果审核不通过，则确定发行失败，可以通知用户重新启动发行过程。
上述内容是电子票据的发行过程，在票据交易过程中，还涉及到票据转让、票据贴现等过程，下面对票据交易过程进行描述：
205、当接收到所述第一用户的票据交易请求时，如果票据交易请求为全额票据交易请求，基于与第一用户和第二用户之间的消息交互，进行票据交易。
该票据交易请求是指用户基于所持有的电子票据与其他用户进行交易的请求。如，该票据交易请求为票据转让请求或票据贴现请求。该票据交易请求还可以携带请求交易的交易资产信息以及第一用户对该票据交易请求的签名信息，该交易资产信息用于指示第一用户本次交易中所要交易的资产金额，该签名信息可以由电子票据管理系统在本次交易成功时存储至区块链，以用于后续取证交易信息时验证第一用户的身份。第二用户是指电子票据管理系统内除第一用户以外的某一用户，该二用户可以根据第一用户确定，如，可根据第一用户在发起票据交易请求时填写的第二用户的用户标识进行确定。
该步骤中，当电子票据管理系统接收到该票据交易请求时，可以通过票据交易请求所携带的第一票据账户以及票据交易请求携带的交易资产信息，确定票据交易请求的类型。例如，票据交易请求的类型可以采取以下方法进行确定：电子票据管理系统可以根据票据交易请求携带的第一票据账户，查询到第一票据账户对应的资产信息，并将该资产信息对应的资产金额与票据交易请求携带 的交易资产信息对应的交易资产金额进行比较，如果二者相等，则确定票据交易请求的类型的全额票据交易请求，进而可以基于与第一用户和第二用户之间的消息交互，进行票据交易。
在确定票据交易请求的类型后，电子票据管理系统即可以进行票据交易的过程。该票据交易过程可以具体为：电子票据管理系统向第二用户发送第一签收请求消息，该第一签收请求消息用于指示签收第一票据账户；当接收到第二用户的第一签收确认消息时，可以确定票据交易成功；当接收到第二用户的第一签收拒绝消息时，可以确定票据交易失败。
其中，第一签收请求消息还可以携带第一票据账户。基于第一签收请求中携带的第一票据账户，第二用户可以通过该第一票据账户查看第一票据账户的账户信息等，从而能够对所要签收的第一票据账户进行核对。该第一签收确认消息可以携带第二用户对第一签收确认消息的签名信息，该签名信息可以由电子票据管理系统在本次交易成功时存储至区块链，以用于后续取证交易信息时验证第二用户的身份。上述具体过程中，当第二用户接收到第一签收请求时，可以自行选择是否签收，如果确定签收，则可以将第一签收确认消息发送至电子票据管理系统。上述票据交易流程可以应用于票据转让流程，当票据交易请求为票据贴现请求时，第二用户还可以在签收之前或之后的任一时刻通过线下转账给第一用户，以完成贴现流程。
需要说明的是，为了方便在交易成功时第二用户签收的过程，当电子票据管理系统接收到票据交易请求后，可以在账户表中为第二用户生成对应的第二票据账户，该第二票据账户用于标识为第二用户签收的电子票据，此时，该第二票据账户的账户信息中的票据持有人信息可以为第二用户的用户标识，账户信息中的其他信息可以暂时不进行设置，或者设为默认值。
当然，为使本次交易合法进行，当电子票据管理系统接收到票据交易请求时，可根据票据交易请求携带的票据账户，校验票据交易请求与票据账户是否匹配，如果匹配，则继续本次交易，如果不匹配，则结束本次交易。
以上校验过程中，电子票据管理系统可以根据票据账户的账户信息中的至少一项信息进行校验。例如，可根据票据账户的账户信息中的资产信息，校验票据交易请求所携带的交易资产信息与该资产信息是否匹配。举例说明，如果交易资产信息的资产金额不大于该资产信息的资产金额，说明该票据交易请求合理，确定票据交易请求与票据账户匹配，否则确定二者不匹配。又例如，可根据票据账户的账户信息中的到期日，校验票据交易请求的请求时间与该到期日是否匹配。举例说明，如果该票据交易请求的请求时间不晚于到期日，说明该票据交易请求合理，可确定票据交易请求与票据账户匹配，否则确定二者不匹配。另外，电子票据管理系统还可以根据票据账户的账户信息中的账户状态进行校验，当账户状态为正常持有状态时，可确定票据交易请求与票据账户匹配，当账户状态为正常持有状态之外的账户状态时，可确定二者不匹配。当然，为了进一步提高本次交易的合理性，也可以在上述信息全部与票据交易请求匹配时，才确定票据交易请求与票据账户对应，否则，确定票据交易请求与该票据账户不匹配。
对于票据交易请求时票据贴现请求的情况，为了提高资产流通效率、并最大程度保证第一用户的利益，电子票据管理系统也可以在进行交易的步骤前为第一用户发起票据竞价。票据竞价过程为：当确定票据交易请求为票据贴现请求时，电子票据管理系统向该电子票据管理系统中各个用户发送第一票据账户 对应的票据竞价消息，并根据竞价反馈信息，将对第一票据账户竞价最高的用户作为第二用户。
在票据竞价的方案中，电子票据管理系统可以基于票据贴现请求携带的第一票据账户，生成票据竞价消息，该票据竞价消息携带第一票据账户，可以包括第一用户的用户标识、第一票据账户的账户信息中的资产信息和到期日。进而，电子票据管理系统可以采用推送等方式将票据竞价消息发送至各个用户。电子票据管理系统可以在本次票据竞价过程中获取每个用户对该票据竞价消息的反馈信息，该反馈信息至少包括用户承诺贴现的金额信息，使得电子票据管理系统可以将其中承诺贴现金额最高的用户作为第二用户。当然，票据竞价过程理应设置有竞价时间，该竞价时间可以由第一用户或电子票据管理系统进行设置，但不能晚于到期日。
在实际场景中，用户可以通过客户端将该票据交易请求发送至电子票据管理系统中的网关，由网关将该票据交易请求发送至票据管理系统中的服务器，使得服务器基于该票据交易请求为用户提供交易服务。当然，在票据竞价过程中，也可以由网关发起票据竞价，并确定出第二用户，进而将第二用户的用户标识和第一用户的票据交易请求发送至服务器。
206、当票据交易成功时，对账户表中的票据账户进行更新，并在区块链上生成用于记录第一用户的票据交易的区块以及用于记录第二用户票据交易的区块。
本发明实施例中，为了明确记录交易过程，电子票据管理系统可在票据交易成功时，对账户表中的交易双方的票据账户进行更新。又为了毫无争议地记录每次交易，避免恶意用户抵赖或篡改交易，电子票据管理系统还可生成用于记录票据交易的区块。本发明实施例对更新票据账户和生成区块的具体过程不做限定。例如：当票据交易成功时，电子票据管理系统可对账户表中的第一票据账户和第二用户的第二票据账户进行更新，并在区块链上生成第三区块和第四区块。其中，第三区块用于记录第一用户的本次票据交易事件，第四区块用于记录第二用户的本次票据签收事件。
其中，在更新票据账户时，以票据交易请求为票据转让请求为例，电子票据管理系统可将第一票据账户的账户信息的票据状态修改为已转让状态，从而表明该第一票据账户所标识的电子票据已转让，并将已生成的第二票据账户的账户信息中的资产信息设置为原第一票据账户对应的资产信息(若还未生成第二票据账户，也可以此时生成)，将第二票据账户的账户信息中的账户状态为正常持有状态。
该生成区块的过程与生成第二区块的过程同理，该第三区块的区块主体中可以存储票据交易请求的事件信息、第一票据账户、第一用户对票据交易请求的签名信息，该第三区块的区块头中可以存储上一个区块的区块头特征值和第三区块的区块主体特征值等；该第四区块的区块主体中可以存储第一签收确认消息的事件信息、第二票据账户、第二用户对第一签收确认消息的签名信息，第四区块的区块头中可以存储上一个区块的区块头特征值和该第四区块的区块主体特征值。
对于该步骤206中涉及的票据账户更新过程以及区块生成过程，均可以由电子票据管理系统中的服务器完成。
207、向第二用户发送交易成功消息。
基于上述任一种方式票据交易成功后，电子票据管理系统可以向第二用户 发送对应的交易成功消息，该交易成功消息可以携带交易后的第二用户对应的第二票据账户，或第二用户对应的第四票据账户，使得第二用户能够查看已签收的票据账户。当然，电子票据管理系统还可以向第一用户发送对应的交易成功消息，该交易成功消息可以携带交易后的第一票据账户，或第一票据账户和第三票据账户，使得第一票据账户查看已交易的第一票据账户、或者存有剩余资产的第三票据账户。
在实际场景中，可以由电子票据管理系统中的服务器将该交易成功消息发送至网关，再由网关将该交易成功消息发送至用户所在客户端。
基于上述交易过程，若以票据交易请求为票据转让请求为例，参见图7，本发明实施例提供了一种票据转让流程图。该转让流程中，票据管理系统在接收到第一用户的票据转让请求时，对该第一用户的票据转让请求进行校验，若校验通过，则生成第二用户的第二票据账户，并将票据签收请求发送至第二用户，若第二用户同意签收，则票据管理系统分别更新第一用户和第二用户的票据账户，并生成记录本次交易信息的区块，若第二用户拒绝签收，则票据管理系统将签收拒绝消息更新至第一票据账户。
若上述交易过程以票据交易请求为票据贴现请求为例，参见图8，本发明实施例提供了一种票据贴现流程图。该贴现流程中，票据管理系统在接收到第一用户的票据贴现请求时，发起票据竞价，待确定了第二用户后，对第二用户进行校验，若校验通过，则为第二用户生成第二票据账户，并将票据签收请求发送至第二用户，若第二用户同意签收，则票据管理系统分别更新第一用户和第二用户的票据账户，并生成用于记录本次交易信息的区块，若第二用户拒绝签收，则票据管理系统将签收拒绝消息更新至第一票据账户。
事实上，为了丰富交易方式、提高资产流通效率，电子票据管理系统既支持用户交易其电子票据对应的全部资产，也支持用户交易该电子票据的部分资产(如，某用户持有的电子票据对应的资产金额较大，可以与其他用户交易部分资产，使得更多用户可以在资产能力范围内与该用户进行交易)。
因此，以上步骤205-207为本发明实施例的在进行全额票据交易时的相关步骤，除了上述全额票据交易请求的情况，还有以下可能情况：当电子票据管理系统接收到第一用户的票据交易请求时，如果票据交易请求为部分票据交易请求，可基于部分票据交易请求中携带的交易资产信息，在账户表中，生成与第一用户对应的第三票据账户，进而向第二用户发送第二签收请求消息，该第二签收请求消息用于指示签收部分第一票据账户。
在确定票据交易请求的类型时，还可以根据票据交易请求所携带的第一票据账户以及票据交易请求携带的交易资产信息进行确定。例如，可以采取以下方法进行确定：如果资产信息对应的资产金额大于交易资产信息对应的交易资产金额，则可确定该票据交易请求为部分票据交易请求，为了方便交易成功时交易双方的签收过程，电子票据管理系统可以在账户表中生成第一用户对应的第三票据账户，此时，该第三票据账户的账户信息中的票据持有人信息可以为第一用户的用户标识，其他信息可以暂时不进行设置。之后，电子票据管理系统可以向第二用户发送第二签收请求消息，该第二签收请求消息携带第一票据账户以及交易资产信息，以使第二用户核对所要签收的部分第一票据账户。
对于票据交易请求是部分票据交易请求的情况，电子票据管理系统可以采用如下方式更新票据账户并生成区块：当电子票据管理系统接收到第二用户的第二签收确认消息时，在账户表中更新第一票据账户、第三票据账户和第二用 户的第四票据账户，并在区块链上生成第六区块和第七区块，该第六区块用于记录第一用户的本次票据交易事件，该第七区块用于记录第二用户的本次票据签收事件。
其中，第二签收确认消息可以携带第二用户对该第二签收确认消息的签名信息，该签名信息可以由票据交易系统在本次交易成功时存储至区块链，以用于后续取证交易信息时验证第二用户的身份。
以第一用户的部分票据交易请求携带的交易资产信息为80、第一票据账户的资产信息为100为例，当电子票据管理系统接收到第二用户的第二签收确认消息时，确定该第二用户确认签收80的资产，因此，电子票据管理系统可以将第一票据账户的资产信息修改为0、账户状态修改为已转让状态，将第三票据账户的资产信息更新为20、账户状态更新为正常持有状态，将第四票据账户(可以在接收到部分票据交易请求时为第二用户生成并设置)的资产信息更新为80、账户状态更新为正常持有状态。
在区块生成过程中，第六区块的区块主体中可以存储部分票据交易请求的事件信息、第一票据账户和第三票据账户、第一用户对部分票据交易请求的签名信息，第六区块的区块头中可以存储上一个区块的区块头特征值和该第六区块的区块主体特征值；第七区块的区块主体中可以存储第二签收确认消息的事件信息、第四票据账户、第二用户对第二签收确认消息的签名信息，第七区块的区块头中可以存储上一个区块的区块头特征值和该第七区块的区块主体特征值。
当然，第二用户有可能拒绝签收部分第一票据账户，在该情况下，本发明实施例对电子票据管理系统的处理方式不做具体限定。例如：当电子票据管理系统接收到第二用户的第二签收拒绝消息时，从账户表中删除第三票据账户。举例说明，由于交易失败，电子票据管理系统保持原有的第一票据账户即可。当然，如果已生成第四票据账户，电子票据管理系统也可以从账户表中删除该第四票据账户。
基于上述部票据拆分过程，参见图9，本发明实施例提供了一种票据拆分流程图。该拆分流程中，以发起方的票据账户为A，发起方的剩余票据账户为B，接收方的票据账户为C为例进行说明，当电子票据管理系统确定该票据交易请求为全额票据交易请求时，可以将A中的全部资产金额转入C；当电子票据管理系统确定该票据交易请求为部分票据交易请求时，可以生成B，并向接收方用户发送票据签收请求，若接收方用户同意签收，则将A中与交易资产信息对等的资产金额转入C，将A中交易后的剩余资产金额转入B，若接收方用户拒绝签收，则保持A的资产金额不变即可，并将接收方的签收拒绝消息更新至A。
上述的票据交易过程均是涉及到用户之间的交互，而实际的票据交易过程还可以涉及到由电子票据管理系统为第一用户完成兑付过程。该票据兑付流程为：当电子票据管理系统检测到第一票据账户达到兑付期限时，向第一用户发送票据兑付请求，如果第一用户确认进行兑付，则返回兑付确认消息，当接收到第一用户的兑付确认消息时，可为第一用户兑付第一票据账户对应的资产，当兑付过程完成时，对账户表中的第一票据账户进行更新，并基于兑付确认消息和上一个区块的区块头特征值，生成第五区块，进而向第一用户发送兑付成功消息。
其中，该兑付确认消息可以携带第一用户对该兑付确认消息的签名信息，该签名信息可以由票据交易系统在本次兑付成功时存储至区块链，以用于后续取证交易信息时验证第一用户的身份。
参见图10A，本发明实施例提供了一种票据兑付流程图，在兑付过程中，电子票据管理系统可以定时检测各个票据账户的到期日，根据到期日确定当前日期是否匹配兑付期限(不限于到期日当天或到期日的前十天)，如果匹配，则确定第一票据账户达到兑付期限，电子票据管理系统可以向第一用户发送票据兑付请求，该票据兑付请求携带第一票据账户。当第一用户接收到票据兑付请求时，可以核对第一票据账户的账户信息，并向电子票据管理系统发送兑付确认消息。当电子票据管理系统接收到兑付确认消息时，可以直接为第一用户兑付当前第一票据账户对应的资产金额，兑付成功后，第一用户转让给电子票据管理系统的商业票据将归电子票据管理系统所有。或者，在第一用户将商业票据质押给电子票据管理系统的情况下，电子票据管理系统可以先根据第一票据账户从区块链中查询到原始票据信息，并根据原始票据信息中的票据标识，查询到商业票据的实际欠款人，向该实际欠款人索要资产，并将索要的资产兑付给第一用户。当兑付成功后，电子票据管理系统可以在账户表中将第一票据账户的账户信息中的票据状态修改为已兑付状态，并生成第五区块，该第五区块的区块主体中可以存储兑付确认消息的事件信息、第一票据账户、第一用户对兑付确认消息的签名信息，该第五区块的区块头中可以存储上一个区块的区块头特征值和该第五区块的区块主体特征值。
需要说明的是，在兑付过程启动时，为了避免系统出错，电子票据管理系统也可以进行校验过程，例如，当电子票据管理系统检测到第一票据账户达到兑付期限时，校验第一票据账户是否满足兑付条件，如果是，则继续本次交易，如果否，则结束本次交易。兑付条件可以包括但不限于：第一票据账户的账户信息中的账户状态为正常持有状态、资产信息不为0或到期日不早于当前日期。
另外，还要说明的是，在电子票据管理系统处理交易的过程中，均可能接收到任一用户对待签收票据账户的签收拒绝消息或者对待兑付票据账户的兑付拒绝消息，在以上用户拒绝的情况下，为了明确记录本次交易失败的事件，电子票据管理系统也可以对应该待签收票据账户或待兑付票据账户进行记录，也即是：当电子票据管理系统接收到任一用户对待签收票据账户的签收拒绝消息时，将用户的签收拒绝消息更新至账户表中的待签收票据账户；或，当电子票据管理系统接收到任一用户对待兑付票据账户的兑付拒绝消息时，将用户的兑付拒绝消息更新至所述账户表中的所述待兑付票据账户。该签收拒绝消息可以存储至票据账户的账户信息中的交易结果。
在实际场景中，可以由电子票据管理系统中的网关进行兑付期限的检测，并触发兑付过程，将兑付发起消息发送至服务器，当服务器接收到该兑付发起消息时，可以进行校验过程，若校验通过，则向网关发送票据兑付请求，由网关将票据兑付请求发送至第一用户所在客户端，该客户端可以将第一用户的兑付确认消息或兑付拒绝消息发送至网关，由网关将第一用户发送的消息发送至服务器，使得服务器基于该消息完成兑付过程。
本发明实施例基于第一用户的原始票据信息，可在账户表中生成与第一用户对应的第一票据账户，基于第一用户的票据发行请求、第一票据账户和区块链中第一区块的区块头特征值，可生成第二区块，经过上述过程不仅能够通过 账户表管理账户信息，而且能够基于区块链中前后区块之间的关联关系，使得区块中任一信息被篡改时都能通过下一区块而检测到，避免恶意用户篡改或抵赖所发行的电子票据，从而保证了交易信息的安全性和可靠性。
为了体现本发明实施例的票据流转过程，下面以图10B为例说明票据交易流程。该交易流程中，核心企业H购买了一级供应商N的一批货物，尚未付款，则可以通过银行票据系统开立商业票据，并由银行票据系统向一级供应商N发送商业票据签收请求，一级供应商N可以通过银行网银进行签收，从而得到一张商业票据。
进而，一级供应商N向电子票据管理系统发送票据发行请求，当电子票据管理系统中的网关接收到该票据发行请求时，可以向银行票据系统申请将一级供应商N的商业票据的持有人修改为网关，相当于一级供应商N将商业票据转让给网关，对应的，由电子票据管理系统为其发行电子票据，并将发行事件写入区块链，确定发行成功。此后，一级供应商N可以通过电子票据管理系统转让、贴现或拆分该电子票据。而且，电子票据管理系统的网关可以自动检测该电子票据的兑付期限，一旦到达兑付期限，网关可以主动发起兑付过程，从而为一级供应商N兑付电子票据对应的资产。
实际上，上述交易过程是分别基于各个用户在银行侧对的记账节点以及区块链平台侧的记账节点的票据账户进行的，如图10C所示，商业票据签收、质押商业票据、转让电子票据等等过程，均对应交易双方用户的票据账户之间的交互。
一方面，由于电子票据一旦在区块链登记上链，后续流通环节可以不依赖于原来的电子商业汇票体系，用户不必须拥有网银，也能在电子票据系统上转让或贴现电子票据，而且交易时的资产金额可以是该用户所持有的任意资产金额，进行交易的用户不限于企业用户、个人用户和银行用户等等，这使得电子票据的交易过程的限制少，因此，具有很强的流通性。另一方面，基于票据拆分过程，票据以社会化传播的形式进行交易，电子票据可由核心企业H和一级供应商N，扩张到N的商业伙伴也即是二级供应商M，从而实现了任意金额的票据切片及支付。另一方面，由于任何有电子票据资源的节点都可以成为资产流通的催化剂(如银行、核心企业、供应商等及能够接受C票交易的票据交易机构)，因而整个交易过程开放性高，驱动了资产流通效率。另一方面，利用区块链的特点，可以达到去中心化存储，且交易信息也可以多节点存储，因而有效地避免交易信息被篡改或抵赖，并且全程可追溯。
另外，本发明实施例为用户提供了自由交易电子票据的平台，当接收到第一用户的票据交易请求时，可以基于第一用户和第二用户之间的消息交互，令双方自由交易，在交易成功时，不仅可对账户表中的票据账户进行更新，而且在区块链上生成用于记录本次交易的区块，进一步保证了交易信息的安全性和可靠性。
另外，本发明实施例提供了更新票据账户和生成区块的具体过程，通过更新第一用户和第二用户分别对应的票据账户，能够合理管理交易双方的票据账户。此外，不仅可生成用于记录第一用户本次票据交易事件的第三区块，还可以生成用于记录第二用户本次票据签收事件的第四区块，因而能够合理地记录了交易双方在本次交易中的各自的角色，并且充分体现了电子票据从第一用户至第二用户的交易过程。
另外，为了丰富票据交易的方式、提高资产流通效率，本发明实施例提供 了拆分电子票据的具体方法，具体拆分过程为：当接收到票据交易请求时，确定票据交易请求的类型，如果是全额票据交易请求，则基于与第一用户和第二用户之间的消息交互，进行票据交易；如果是部分票据交易请求，则基于部分票据交易请求中携带的交易资产信息，生成第一用户对应的第三票据账户，当交易成功时，原有的第一票据账户中的交易资产可转入第二用户的第四票据账户，而剩余资产可以转入第三票据账户，进而可以将交易信息存储至区块链，不仅完整地记录了原有电子票据已交易，并拆分为两个新的电子票据的过程，而且保证了交易信息的安全性。
另外，本发明实施例提供了当用户拒绝签收部分第一票据账户中的交易资产时，电子票据管理系统的简便处理方法，采用该方法可通过删除第三票据账户，保持了原有的第一票据账户的账户信息。
另外，为了丰富票据交易的方式、提高资产流通效率，并且尽可能保证持票用户的利益，当票据交易请求为贴现交易请求时，可以为该用户向电子票据管理系统的各个用户发送票据竞价消息，并将竞价最高的用户作为与第一用户进行交易的第二用户。
另外，本发明实施例还可以智能地检测第一票据账户是否到达兑付期限，并当第一票据账户到达兑付期限时，主动为第一用户兑付资产，从而智能且人性化地为第一用户管理电子票据。
另外，为了方便后续取证交易信息、防止恶意用户抵赖或篡改交易信息，票据交易过程中所交互的消息还携带由消息发送用户对消息进行签名得到的签名信息，从而在取证时可以根据用户的签名信息公正有效地验证用户身份。
另外，为了确保用户提供的原始票据信息的准确性，本发明实施例还可以根据原始票据信息中的票据标识，查询对应的商业票据信息，当这两个信息匹配时，才为第一用户发行电子票据。
另外，为了避免用户发起不合理的交易请求，确保每次交易合法进行，本发明实施例还还可以在接收到票据交易请求时，校验票据账户的账户信息与票据交易请求是否匹配，或者，在检测到票据账户达到兑付期限时进行校验。
另外，即使用户拒绝签收或兑付票据账户，本发明实施例也可以将签收拒绝消息或兑付拒绝消息存储至对应的票据账户，从而明确记录本次失败的交易，防止恶意用户抵赖。
图11是本发明实施例提供的一种电子票据管理装置的框图。参见图11，该装置具体包括：
接收模块1101，用于接收第一用户的票据发行请求，票据发行请求携带原始票据信息；
账户生成模块1102，用于基于原始票据信息，生成与第一用户对应的第一票据账户，并将第一票据账户的账户信息存储至电子票据管理系统中的账户表；
区块生成模块1103，用于基于票据发行请求、第一票据账户以及电子票据管理系统中区块链中第一区块的区块头特征值，生成第二区块，第一区块为区块链上第二区块的上一个区块，第二区块用于记录第一用户的票据发行事件；
发送模块1104，用于向第一用户发送发行成功消息，发行成功消息携带第一票据账户。
本发明实施例通过基于第一用户的原始票据信息，不仅在账户表中生成与 第一用户对应的第一票据账户，而且基于第一用户的票据发行请求、第一票据账户和区块链中第一区块的区块头特征值，生成第二区块，不仅能够通过账户表管理账户信息，而且能够基于区块链中前后区块之间的关联关系，使得区块中任一信息被篡改时都能通过下一区块而检测到，避免恶意用户篡改或抵赖所发行的电子票据，从而保证了交易信息的安全性和可靠性。
在一种可能实现方式中，基于图11的装置组成，参见图12，该装置还包括：交易模块1105和账户更新模块1106，
交易模块1105，用于当接收到第一用户的票据交易请求时，基于与第一用户和第二用户之间的消息交互，进行票据交易，票据交易请求携带第一票据账户；
账户更新模块1106，用于当票据交易成功时，对账户表中的票据账户进行更新，并在区块链上生成用于记录第一用户的票据交易的区块以及用于记录第二用户票据交易的区块；
发送模块1104，用于向第二用户发送交易成功消息。
在一种可能实现方式中，发送模块1104，用于向第二用户发送第一签收请求消息，第一签收请求消息用于指示第二用户签收第一票据账户；
交易模块1105，用于当接收到第二用户的第一签收确认消息时，确定票据交易成功；当接收到第二用户的第一签收拒绝消息时，确定票据交易失败。
在一种可能实现方式中，账户更新模块1106，用于当票据交易成功时，对账户表中的第一票据账户和第二用户的第二票据账户进行更新；
区块生成模块1103，用于在区块链上生成第三区块和第四区块，第三区块用于记录第一用户的本次票据交易事件，第四区块用于记录第二用户的本次票据签收事件。
在一种可能实现方式中，交易模块1105用于：当接收到第一用户的票据交易请求时，如果票据交易请求为全额票据交易请求，基于与第一用户和第二用户之间的消息交互，进行票据交易。
在一种可能实现方式中，账户生成模块1102，用于当接收到第一用户的票据交易请求时，如果票据交易请求为部分票据交易请求，基于部分票据交易请求中携带的交易资产信息，在账户表中，生成与第一用户对应的第三票据账户；发送模块1104，用于向第二用户发送第二签收请求消息，第二签收请求消息用于指示第二用户签收部分第一票据账户；账户更新模块1106，用于当接收到第二用户的第二签收确认消息时，对账户表中的第一票据账户、第三票据账户和第二用户的第四票据账户进行更新；区块生成模块1103，用于在区块链上生成第六区块和第七区块，第六区块用于记录第一用户的本次票据交易事件，第七区块用于记录第二用户的本次票据签收事件。
在一种可能实现方式中，账户更新模块1106还用于：当接收到第二用户的第二签收拒绝消息时，从账户表中删除第三票据账户。
在一种可能实现方式中，票据交易请求为票据转让请求或票据贴现请求。
在一种可能实现方式中，发送模块1104，还用于票据交易请求为票据贴现请求时，向电子票据管理系统中各个用户发送第一票据账户对应的票据竞价消息；交易模块1105，还用于将对第一票据账户竞价最高的用户作为第二用户。
在一种可能实现方式中，基于图11的装置组成，参见图13，该装置还包括：兑付模块1107，该兑付模块1107用于：当检测到第一票据账户达到兑付期限时，向第一用户发送票据兑付请求；当接收到第一用户的兑付确认消息时， 为第一用户兑付第一票据账户对应的资产；当兑付过程成功时，在账户表中更新第一票据账户，基于兑付确认消息和上一个区块的区块头特征值，生成第五区块；向第一用户发送兑付成功消息。
在一种可能实现方式中，账户更新模块1106，用于根据票据交易的交易流程，对账户表中第一票据账户的账户信息中的账户状态进行修改；其中，账户状态包括已转让状态、已贴现状态、已兑付状态和正常持有状态。
在一种可能实现方式中，票据交易过程中所交互的消息还携带由消息发送用户对消息进行签名得到的签名信息。
在一种可能实现方式中，基于图11的装置组成，参见图14，该装置还包括：
查询模块1108，用于根据原始票据信息中的票据标识，查询票据标识对应的商业票据信息；
账户生成模块1102，还用于如果商业票据信息与原始票据信息匹配，执行基于原始票据信息，生成与第一用户对应的第一票据账户的步骤。
在一种可能实现方式中，基于图11的装置组成，参见图15，装置还包括：
校验模块1109，用于当接收到票据交易请求时，根据票据交易请求携带的票据账户，校验票据交易请求与票据账户是否匹配，如果是，则继续本次交易，如果否，则结束本次交易；或，
校验模块1109，还用于当检测到第一票据账户达到兑付期限时，校验第一票据账户是否满足兑付条件，如果是，则继续本次交易，如果否，则结束本次交易。
在一种可能实现方式中，账户更新模块1106，还用于当接收到任一用户对待签收票据账户的签收拒绝消息时，将用户的签收拒绝消息更新至账户表中的待签收票据账户；或，
账户更新模块1106，还用于当接收到任一用户对待兑付票据账户的兑付拒绝消息时，将用户的兑付拒绝消息更新至账户表中的待兑付票据账户。
上述所有可选技术方案，可以采用任意结合形成本发明的可选实施例，在此不再一一赘述。
需要说明的是：上述实施例提供的电子票据管理装置在管理电子票据时，仅以上述各功能模块的划分进行举例说明，实际应用中，可以根据需要而将上述功能分配由不同的功能模块完成，即将装置的内部结构划分成不同的功能模块，以完成以上描述的全部或者部分功能。另外，上述实施例提供的电子票据管理装置与电子票据管理方法实施例属于同一构思，其具体实现过程详见方法实施例，这里不再赘述。
图16是本发明实施例提供的一种电子票据管理装置1600的框图。例如，装置1600可以被提供为一服务器。参照图16，装置1600包括处理组件1622，其进一步包括一个或多个处理器，以及由存储器1632所代表的存储器资源，用于存储可由处理部件1622的执行的指令，例如应用程序。存储器1632中存储的应用程序可以包括一个或一个以上的每一个对应于一组指令的模块。此外，处理组件1622被配置为执行指令，以执行上述实施例中电子票据管理系统执行的方法。
装置1600还可以包括一个电源组件1626被配置为执行装置1600的电源 管理，一个有线或无线网络接口1650被配置为将装置1600连接到网络，和一个输入输出(I/O)接口1658。装置1600可以操作基于存储在存储器1632的操作系统，例如Windows Server TM，Mac OS X TM，Unix TM，Linux TM，FreeBSD TM或类似。
在示例性实施例中，还提供了一种包括指令的非临时性计算机可读存储介质，例如包括指令的存储器，上述指令可由服务器中的处理器执行以完成上述实施例中的电子票据管理方法。例如，所述非临时性计算机可读存储介质可以是ROM、随机存取存储器(RAM)、CD-ROM、磁带、软盘和光数据存储设备等。
本发明实施例还提供了一种存储介质，所述存储介质中存储有至少一条指令、至少一段程序、代码集或指令集，所述至少一条指令、所述至少一段程序、所述代码集或指令集由所述处理器加载并执行以实现上述实施例中的电子票据管理方法。
上述本发明实施例序号仅仅为了描述，不代表实施例的优劣。
本领域普通技术人员可以理解实现上述实施例的全部或部分步骤可以通过硬件来完成，也可以通过程序来指令相关的硬件完成，的程序可以存储于一种计算机可读存储介质中，上述提到的存储介质可以是只读存储器，磁盘或光盘等。
以上仅为并不用以限制本发明实施例，凡在本发明实施例的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明实施例的保护范围之内。

Claims (46)

  1. 一种电子票据管理方法，其中，所述方法应用于电子票据管理系统，所述方法包括：
    接收第一用户的票据发行请求，所述票据发行请求携带原始票据信息；
    基于所述原始票据信息，生成与所述第一用户对应的第一票据账户，并将所述第一票据账户的账户信息存储至所述电子票据管理系统中的账户表；
    基于所述票据发行请求、所述第一票据账户以及所述电子票据管理系统中区块链中第一区块的区块头特征值，生成第二区块，所述第一区块为所述区块链上所述第二区块的上一个区块，所述第二区块用于记录所述第一用户的票据发行事件；
    向所述第一用户发送发行成功消息，所述发行成功消息携带所述第一票据账户。
  2. 根据权利要求1所述的方法，其中，所述向所述第一用户发送发行成功消息之后，所述方法还包括：
    当接收到所述第一用户的票据交易请求时，基于与所述第一用户和第二用户之间的消息交互，进行票据交易，所述票据交易请求携带所述第一票据账户；
    当票据交易成功时，对所述账户表中的票据账户进行更新，并在所述区块链上生成用于记录所述第一用户的票据交易的区块以及用于记录所述第二用户票据交易的区块；
    向所述第二用户发送交易成功消息。
  3. 根据权利要求2所述的方法，其中，所述基于与所述第一用户和第二用户之间的消息交互，进行票据交易，包括：
    向所述第二用户发送第一签收请求消息，所述第一签收请求消息用于指示所述第二用户签收所述第一票据账户；
    当接收到所述第二用户的第一签收确认消息时，确定票据交易成功；
    当接收到所述第二用户的第一签收拒绝消息时，确定票据交易失败。
  4. 根据权利要求2所述的方法，其中，所述当票据交易成功时，对所述账户表中的票据账户进行更新，包括：
    当票据交易成功时，对所述账户表中的所述第一票据账户和所述第二用户的第二票据账户进行更新；
    所述在所述区块链上生成用于记录所述第一用户的票据交易的区块以及用于记录所述第二用户票据交易的区块，包括：
    在所述区块链上生成第三区块和第四区块，所述第三区块用于记录所述第一用户的本次票据交易事件，所述第四区块用于记录所述第二用户的本次票据签收事件。
  5. 根据权利要求2所述的方法，其中，所述当接收到所述第一用户的票据交易请求时，基于与所述第一用户和第二用户之间的消息交互，进行票据交易，包括：
    当接收到所述第一用户的票据交易请求时，如果所述票据交易请求为全额票据交易请求，基于与所述第一用户和第二用户之间的消息交互，进行票据交易。
  6. 根据权利要求2所述的方法，其中，所述当接收到所述第一用户的票据交易请求时，基于与所述第一用户和第二用户之间的消息交互，进行票据交易，包括：
    当接收到所述第一用户的票据交易请求时，如果所述票据交易请求为部分票据交易请求，基于所述部分票据交易请求中携带的交易资产信息，在所述账户表中，生成与所述第一用户对应的第三票据账户；
    向所述第二用户发送第二签收请求消息，所述第二签收请求消息用于指示所述第二用户签收部分所述第一票据账户；
    相应地，所述当票据交易成功时，对所述账户表中的票据账户进行更新，包括：
    当接收到所述第二用户的第二签收确认消息时，对所述账户表中的所述第一票据账户、所述第三票据账户和所述第二用户的第四票据账户进行更新；
    所述在所述区块链上生成用于记录所述第一用户的票据交易的区块以及用于记录所述第二用户票据交易的区块，包括：
    在所述区块链上生成第六区块和第七区块，所述第六区块用于记录所述第一用户的本次票据交易事件，所述第七区块用于记录所述第二用户的本次票据签收事件。
  7. 根据权利要求6所述的方法，其中，所述方法还包括：
    当接收到所述第二用户的第二签收拒绝消息时，从所述账户表中删除所述第三票据账户。
  8. 根据权利要求2所述的方法，其中，所述票据交易请求为票据转让请求或票据贴现请求。
  9. 根据权利要求8所述的方法，其中，所述基于与所述第一用户和第二用户之间的消息交互，进行票据交易之前，所述方法还包括：
    所述票据交易请求为票据贴现请求时，向所述电子票据管理系统中各个用户发送所述第一票据账户对应的票据竞价消息；
    将对所述第一票据账户竞价最高的用户作为所述第二用户。
  10. 根据权利要求1所述的方法，其中，所述向所述第一用户发送发行成功消息之后，所述方法还包括：
    当检测到所述第一票据账户达到兑付期限时，向所述第一用户发送票据兑付请求；
    当接收到所述第一用户的兑付确认消息时，为所述第一用户兑付所述第一票据账户对应的资产；
    当兑付过程成功时，在所述账户表中更新所述第一票据账户，并基于所述兑付确认消息和上一个区块的区块头特征值，生成第五区块；
    向所述第一用户发送兑付成功消息。
  11. 根据权利要求2-10任一项所述的方法，其中，所述方法还包括：
    根据票据交易的交易流程，对所述账户表中所述第一票据账户的账户信息中的账户状态进行修改；
    其中，所述账户状态包括已转让状态、已贴现状态、已兑付状态和正常持有状态。
  12. 根据权利要求1-10任一项所述的方法，其中，票据交易过程中所交互的消息还携带由消息发送用户对所述消息进行签名得到的签名信息。
  13. 根据权利要求1-10任一项所述的方法，其中，所述接收第一用户的票据发行请求之后，所述方法还包括：
    根据所述原始票据信息中的票据标识，查询所述票据标识对应的商业票据信息；
    如果所述商业票据信息与所述原始票据信息匹配，执行所述基于所述原始票据信息，生成与所述第一用户对应的第一票据账户的步骤。
  14. 根据权利要求2-10任一项所述的方法，其中，所述方法还包括：
    当接收到票据交易请求时，根据所述票据交易请求携带的票据账户，校验所述票据交易请求与所述票据账户是否匹配，如果是，则继续本次交易，如果否，则结束本次交易；或，
    当检测到所述第一票据账户达到所述兑付期限时，校验所述第一票据账户是否满足兑付条件，如果是，则继续本次交易，如果否，则结束本次交易。
  15. 根据权利要求2-10任一项所述的方法，其中，所述方法还包括：
    当接收到任一用户对待签收票据账户的签收拒绝消息时，将所述用户的签收拒绝消息更新至所述账户表中的所述待签收票据账户，或，
    当接收到任一用户对待兑付票据账户的兑付拒绝消息时，将所述用户的兑付拒绝消息更新至所述账户表中的所述待兑付票据账户。
  16. 一种电子票据管理装置，其中，所述装置包括：
    接收模块，用于接收第一用户的票据发行请求，所述票据发行请求携带原始票据信息；
    账户生成模块，用于基于所述原始票据信息，生成与所述第一用户对应的第一票据账户，并将所述第一票据账户的账户信息存储至电子票据管理系统中的账户表；
    区块生成模块，用于基于所述票据发行请求、所述第一票据账户以及所述电子票据管理系统中区块链中第一区块的区块头特征值，生成第二区块，所述第一区块为所述区块链上所述第二区块的上一个区块，所述第二区块用于记录所述第一用户的票据发行事件；
    发送模块，用于向所述第一用户发送发行成功消息，所述发行成功消息携带所述第一票据账户。
  17. 根据权利要求16所述的装置，其中，所述装置还包括：交易模块和账 户更新模块，
    所述交易模块，用于当接收到所述第一用户的票据交易请求时，基于与所述第一用户和第二用户之间的消息交互，进行票据交易，所述票据交易请求携带所述第一票据账户；
    所述账户更新模块，用于当票据交易成功时，对所述账户表中的票据账户进行更新，并在所述区块链上生成用于记录所述第一用户的票据交易的区块以及用于记录所述第二用户票据交易的区块；
    所述发送模块，用于向所述第二用户发送交易成功消息。
  18. 根据权利要求17所述的装置，其中，
    所述发送模块，用于向所述第二用户发送第一签收请求消息，所述第一签收请求消息用于指示所述第二用户签收所述第一票据账户；
    所述交易模块，用于当接收到所述第二用户的第一签收确认消息时，确定票据交易成功；当接收到所述第二用户的第一签收拒绝消息时，确定票据交易失败。
  19. 根据权利要求17所述的装置，其中，
    所述账户更新模块，用于当票据交易成功时，对所述账户表中的所述第一票据账户和所述第二用户的第二票据账户进行更新；
    所述区块生成模块，用于在所述区块链上生成第三区块和第四区块，所述第三区块用于记录所述第一用户的本次票据交易事件，所述第四区块用于记录所述第二用户的本次票据签收事件。
  20. 根据权利要求17所述的装置，其中，所述交易模块用于：
    当接收到所述第一用户的票据交易请求时，如果所述票据交易请求为全额票据交易请求，基于与所述第一用户和第二用户之间的消息交互，进行票据交易。
  21. 根据权利要求17所述的装置，其中，
    所述账户生成模块，用于当接收到所述第一用户的票据交易请求时，如果所述票据交易请求为部分票据交易请求，基于所述部分票据交易请求中携带的交易资产信息，在所述账户表中，生成与所述第一用户对应的第三票据账户；
    所述发送模块，用于向所述第二用户发送第二签收请求消息，所述第二签收请求消息用于指示所述第二用户签收部分所述第一票据账户；
    所述账户更新模块，用于当接收到所述第二用户的第二签收确认消息时，对所述账户表中的所述第一票据账户、所述第三票据账户和所述第二用户的第四票据账户进行更新；
    所述区块生成模块，用于在所述区块链上生成第六区块和第七区块，所述第六区块用于记录所述第一用户的本次票据交易事件，所述第七区块用于记录所述第二用户的本次票据签收事件。
  22. 根据权利要求18所述的装置，其中，所述账户更新模块还用于：
    当接收到所述第二用户的第二签收拒绝消息时，从所述账户表中删除所述第三票据账户。
  23. 根据权利要求17所述的装置，其中，所述票据交易请求为票据转让请求或票据贴现请求。
  24. 根据权利要求23所述的装置，其中，
    所述发送模块，还用于所述票据交易请求为票据贴现请求时，向所述电子票据管理系统中各个用户发送所述第一票据账户对应的票据竞价消息；
    所述交易模块，还用于将对所述第一票据账户竞价最高的用户作为所述第二用户。
  25. 根据权利要求16所述的装置，其中，所述装置还包括：兑付模块，所述兑付模块用于：
    当检测到所述第一票据账户达到兑付期限时，向所述第一用户发送票据兑付请求；
    当接收到所述第一用户的兑付确认消息时，为所述第一用户兑付所述第一票据账户对应的资产；
    当兑付过程成功时，在所述账户表中更新所述第一票据账户，
    基于所述兑付确认消息和上一个区块的区块头特征值，生成第五区块；
    向所述第一用户发送兑付成功消息。
  26. 根据权利要求17-25任一项所述的装置，其中，
    所述账户更新模块，用于根据票据交易的交易流程，对所述账户表中所述第一票据账户的账户信息中的账户状态进行修改；
    其中，所述账户状态包括已转让状态、已贴现状态、已兑付状态和正常持有状态。
  27. 根据权利要求16-25任一项所述的装置，其中，票据交易过程中所交互的消息还携带由消息发送用户对所述消息进行签名得到的签名信息。
  28. 根据权利要求16-25任一项所述的装置，其中，所述装置还包括：
    查询模块，用于根据所述原始票据信息中的票据标识，查询所述票据标识对应的商业票据信息；
    所述账户生成模块，还用于如果所述商业票据信息与所述原始票据信息匹配，执行所述基于所述原始票据信息，生成与所述第一用户对应的第一票据账户的步骤。
  29. 根据权利要求17-25任一项所述的装置，其中，所述装置还包括：
    校验模块，用于当接收到票据交易请求时，根据所述票据交易请求携带的票据账户，校验所述票据交易请求与所述票据账户是否匹配，如果是，则继续本次交易，如果否，则结束本次交易；或，
    所述校验模块，还用于当检测到所述第一票据账户达到所述兑付期限时，校验所述第一票据账户是否满足兑付条件，如果是，则继续本次交易，如果否，则结束本次交易。
  30. 根据权利要求17-25任一项所述的装置，其中，
    所述账户更新模块，还用于当接收到任一用户对待签收票据账户的签收拒绝消息时，将所述用户的签收拒绝消息更新至所述账户表中的所述待签收票据账户；或，
    所述账户更新模块，还用于当接收到任一用户对待兑付票据账户的兑付拒绝消息时，将所述用户的兑付拒绝消息更新至所述账户表中的所述待兑付票据账户。
  31. 一种用于电子票据管理的装置，其中，包括:一个或多个处理器、存储器，所述存储器用于存储至少一条指令、至少一段程序、代码集或指令集，所述至少一条指令、所述至少一段程序、所述代码集或指令集由所述处理器加载并执行以下操作：
    接收第一用户的票据发行请求，所述票据发行请求携带原始票据信息；
    基于所述原始票据信息，生成与所述第一用户对应的第一票据账户，并将所述第一票据账户的账户信息存储至电子票据管理系统中的账户表；
    基于所述票据发行请求、所述第一票据账户以及所述电子票据管理系统中区块链中第一区块的区块头特征值，生成第二区块，所述第一区块为所述区块链上所述第二区块的上一个区块，所述第二区块用于记录所述第一用户的票据发行事件；
    向所述第一用户发送发行成功消息，所述发行成功消息携带所述第一票据账户。
  32. 根据权利要求32所述的装置，其中，所述处理器加载所述至少一条指令、所述至少一段程序、所述代码集或指令集执行以下操作：
    当接收到所述第一用户的票据交易请求时，基于与所述第一用户和第二用户之间的消息交互，进行票据交易，所述票据交易请求携带所述第一票据账户；
    当票据交易成功时，对所述账户表中的票据账户进行更新，并在所述区块链上生成用于记录所述第一用户的票据交易的区块以及用于记录所述第二用户票据交易的区块；
    向所述第二用户发送交易成功消息。
  33. 根据权利要求32所述的装置，其中，所述处理器加载所述至少一条指令、所述至少一段程序、所述代码集或指令集执行以下操作：
    向所述第二用户发送第一签收请求消息，所述第一签收请求消息用于指示所述第二用户签收所述第一票据账户；
    当接收到所述第二用户的第一签收确认消息时，确定票据交易成功；
    当接收到所述第二用户的第一签收拒绝消息时，确定票据交易失败。
  34. 根据权利要求32所述的装置，其中，所述处理器加载所述至少一条指令、所述至少一段程序、所述代码集或指令集执行以下操作：
    当票据交易成功时，对所述账户表中的所述第一票据账户和所述第二用户的第二票据账户进行更新；
    在所述区块链上生成第三区块和第四区块，所述第三区块用于记录所述第一用户的本次票据交易事件，所述第四区块用于记录所述第二用户的本次票据 签收事件。
  35. 根据权利要求32所述的装置，其中，所述处理器加载所述至少一条指令、所述至少一段程序、所述代码集或指令集执行以下操作：
    当接收到所述第一用户的票据交易请求时，如果所述票据交易请求为全额票据交易请求，基于与所述第一用户和第二用户之间的消息交互，进行票据交易。
  36. 根据权利要求32所述的装置，其中，所述处理器加载所述至少一条指令、所述至少一段程序、所述代码集或指令集执行以下操作：
    当接收到所述第一用户的票据交易请求时，如果所述票据交易请求为部分票据交易请求，基于所述部分票据交易请求中携带的交易资产信息，在所述账户表中，生成与所述第一用户对应的第三票据账户；
    向所述第二用户发送第二签收请求消息，所述第二签收请求消息用于指示所述第二用户签收部分所述第一票据账户；
    相应地，所述处理器加载所述至少一条指令、所述至少一段程序、所述代码集或指令集还执行以下操作：
    当接收到所述第二用户的第二签收确认消息时，对所述账户表中的所述第一票据账户、所述第三票据账户和所述第二用户的第四票据账户进行更新；
    在所述区块链上生成第六区块和第七区块，所述第六区块用于记录所述第一用户的本次票据交易事件，所述第七区块用于记录所述第二用户的本次票据签收事件。
  37. 根据权利要求36所述的装置，其中，所述处理器加载所述至少一条指令、所述至少一段程序、所述代码集或指令集执行以下操作：
    当接收到所述第二用户的第二签收拒绝消息时，从所述账户表中删除所述第三票据账户。
  38. 根据权利要求32所述的装置，其中，所述票据交易请求为票据转让请求或票据贴现请求。
  39. 根据权利要求38所述的装置，其中，所述处理器加载所述至少一条指令、所述至少一段程序、所述代码集或指令集执行以下操作：
    所述票据交易请求为票据贴现请求时，向所述电子票据管理系统中各个用户发送所述第一票据账户对应的票据竞价消息；
    将对所述第一票据账户竞价最高的用户作为所述第二用户。
  40. 根据权利要求31所述的装置，其中，所述处理器加载所述至少一条指令、所述至少一段程序、所述代码集或指令集执行以下操作：
    当检测到所述第一票据账户达到兑付期限时，向所述第一用户发送票据兑付请求；
    当接收到所述第一用户的兑付确认消息时，为所述第一用户兑付所述第一票据账户对应的资产；
    当兑付过程成功时，在所述账户表中更新所述第一票据账户，并基于所述 兑付确认消息和上一个区块的区块头特征值，生成第五区块；
    向所述第一用户发送兑付成功消息。
  41. 根据权利要求32-40任一项所述的装置，其中，所述处理器加载所述至少一条指令、所述至少一段程序、所述代码集或指令集执行以下操作：
    根据票据交易的交易流程，对所述账户表中所述第一票据账户的账户信息中的账户状态进行修改；
    其中，所述账户状态包括已转让状态、已贴现状态、已兑付状态和正常持有状态。
  42. 根据权利要求31-40任一项所述的装置，其中，票据交易过程中所交互的消息还携带由消息发送用户对所述消息进行签名得到的签名信息。
  43. 根据权利要求31-40任一项所述的装置，其中，所述处理器加载所述至少一条指令、所述至少一段程序、所述代码集或指令集执行以下操作：根据所述原始票据信息中的票据标识，查询所述票据标识对应的商业票据信息；
    如果所述商业票据信息与所述原始票据信息匹配，执行所述基于所述原始票据信息，生成与所述第一用户对应的第一票据账户的步骤。
  44. 根据权利要求32-40任一项所述的装置，其中，所述处理器加载所述至少一条指令、所述至少一段程序、所述代码集或指令集执行以下操作：
    当接收到票据交易请求时，根据所述票据交易请求携带的票据账户，校验所述票据交易请求与所述票据账户是否匹配，如果是，则继续本次交易，如果否，则结束本次交易；或，
    当检测到所述第一票据账户达到所述兑付期限时，校验所述第一票据账户是否满足兑付条件，如果是，则继续本次交易，如果否，则结束本次交易。
  45. 根据权利要求32-40任一项所述的装置，其中，所述处理器加载所述至少一条指令、所述至少一段程序、所述代码集或指令集执行以下操作：
    当接收到任一用户对待签收票据账户的签收拒绝消息时，将所述用户的签收拒绝消息更新至所述账户表中的所述待签收票据账户，或，
    当接收到任一用户对待兑付票据账户的兑付拒绝消息时，将所述用户的兑付拒绝消息更新至所述账户表中的所述待兑付票据账户。
  46. 一种存储介质，其中，所述存储介质中存储有至少一条指令、至少一段程序、代码集或指令集，所述至少一条指令、所述至少一段程序、所述代码集或指令集由所述处理器加载并执行以实现如权利要求1至15中任一项所述的电子票据管理方法。
PCT/CN2018/078171 2017-03-10 2018-03-06 电子票据管理方法、装置及存储介质 WO2018161903A1 (zh)

Priority Applications (4)

Application Number Priority Date Filing Date Title
EP18763957.0A EP3594884A4 (en) 2017-03-10 2018-03-06 METHOD OF MANAGING ELECTRONIC INVOICES, DEVICE AND STORAGE MEDIUM
KR1020197022822A KR102277998B1 (ko) 2017-03-10 2018-03-06 전자 어음 관리 방법, 장치 및 기록매체
JP2019526479A JP7108611B2 (ja) 2017-03-10 2018-03-06 電子手形管理方法及び装置並びに記憶媒体
US16/384,349 US10977632B2 (en) 2017-03-10 2019-04-15 Electronic bill management method, apparatus, and storage medium

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN201710142464.X 2017-03-10
CN201710142464.XA CN106952094B (zh) 2017-03-10 2017-03-10 电子票据管理方法及装置

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US16/384,349 Continuation US10977632B2 (en) 2017-03-10 2019-04-15 Electronic bill management method, apparatus, and storage medium

Publications (1)

Publication Number Publication Date
WO2018161903A1 true WO2018161903A1 (zh) 2018-09-13

Family

ID=59467165

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2018/078171 WO2018161903A1 (zh) 2017-03-10 2018-03-06 电子票据管理方法、装置及存储介质

Country Status (6)

Country Link
US (1) US10977632B2 (zh)
EP (1) EP3594884A4 (zh)
JP (1) JP7108611B2 (zh)
KR (1) KR102277998B1 (zh)
CN (1) CN106952094B (zh)
WO (1) WO2018161903A1 (zh)

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2020057002A1 (zh) * 2018-09-18 2020-03-26 深圳壹账通智能科技有限公司 基于区块链的发票数据共享系统以及方法
US10956903B2 (en) 2019-07-31 2021-03-23 Advanced New Technologies Co., Ltd. Obtaining a blockchain-based, real-name, electronic bill
TWI723783B (zh) * 2019-07-31 2021-04-01 開曼群島商創新先進技術有限公司 基於區塊鏈的票據實名領取方法、裝置及電子設備
WO2021117515A1 (ja) * 2019-12-13 2021-06-17 株式会社日立製作所 電子資産管理方法、及び電子資産管理装置
US11228439B2 (en) * 2019-01-02 2022-01-18 Jiaping Wang Scale out blockchain with asynchronized consensus zones

Families Citing this family (54)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN106952094B (zh) * 2017-03-10 2018-09-04 腾讯科技（深圳）有限公司 电子票据管理方法及装置
GB201707788D0 (en) * 2017-05-15 2017-06-28 Nchain Holdings Ltd Computer-implemented system and method
CN107424073A (zh) * 2017-07-17 2017-12-01 杭州复杂美科技有限公司 一种跨链数字债权交易的方法
CN107527203A (zh) * 2017-07-24 2017-12-29 湖南搜云网络科技股份有限公司 数字资产的权利转让方法、中央服务器及存储介质
CN107491964A (zh) * 2017-07-24 2017-12-19 湖南搜云网络科技股份有限公司 数字资产的兑换方法、中央服务器及存储介质
CN107480964B (zh) * 2017-07-24 2023-09-22 湖南搜云网络科技股份有限公司 数字资产的定向转让方法、中央服务器及存储介质
CN107423981B (zh) * 2017-08-04 2021-12-10 苏州缓流科技有限公司 基于区块链技术的移动终端浏览器支付方法
CN107480978B (zh) * 2017-08-04 2021-12-10 苏州缓流科技有限公司 基于区块链技术的代付款方法
CN107491948B (zh) * 2017-08-04 2021-12-10 苏州缓流科技有限公司 基于区块链技术的转账支付方法
CN107392769B (zh) * 2017-08-04 2021-12-10 苏州缓流科技有限公司 基于区块链技术的代收支付方法
CN107423973B (zh) * 2017-08-04 2021-12-10 苏州缓流科技有限公司 基于区块链技术的用户移动终端上被动扫码的支付方法
CN107730165A (zh) * 2017-09-19 2018-02-23 前海云链科技(深圳)有限公司 一种电子物流单据管理方法及装置
CN107483498A (zh) * 2017-09-22 2017-12-15 中国联合网络通信集团有限公司 基于区块链的学历认证方法及系统
CN109560916A (zh) * 2017-09-25 2019-04-02 航天信息股份有限公司 一种电子发票的发放方法、领用方法及相关装置
CN108023893A (zh) * 2017-12-18 2018-05-11 王松山 一种区块链数据认证系统的方法
CN109976969A (zh) * 2017-12-27 2019-07-05 航天信息股份有限公司 一种电子发票信息的监控方法、装置、设备及介质
CN108256860A (zh) * 2018-01-03 2018-07-06 山东富瑞英泽资产管理股份有限公司 基于电子信息管理的商业结算专用凭证拆分支付方法
CN108768648B (zh) * 2018-03-15 2021-03-23 兴业数字金融服务（上海）股份有限公司 一种层层加密的区块链事件链安全存证实现方法及系统
US11233792B2 (en) 2018-05-02 2022-01-25 Mastercard International Incorporated Method and system for enhanced login credential security via blockchain
CN108629684A (zh) * 2018-05-09 2018-10-09 众安信息技术服务有限公司 用于控制信用拆分流转的方法、装置及可读存储介质
CN108764720A (zh) * 2018-05-28 2018-11-06 魏巧萍 一种区块链债券发行购买转让系统
CN109035015A (zh) * 2018-06-26 2018-12-18 广东邮政邮件快件服务有限公司 一种基于区块链的邮票交易方法
CN109035019B (zh) * 2018-07-11 2023-06-16 平安科技（深圳）有限公司 票据交易方法、系统、计算机设备和存储介质
CN109191219B (zh) * 2018-08-13 2023-09-26 深圳市智税链科技有限公司 关于电子票据的数据处理方法、装置、存储介质和设备
CN110428292B (zh) * 2018-08-16 2021-05-11 深圳市智税链科技有限公司 电子票据生成方法、装置、存储介质和计算机设备
CN109241772B (zh) * 2018-09-07 2023-05-16 深圳市智税链科技有限公司 发票区块链记录方法、装置、区块链网关服务器和介质
CN109325759B (zh) * 2018-09-17 2023-09-19 简单汇信息科技(广州)有限公司 在线开立方法、管理平台、装置、系统及存储介质
CN109286556B (zh) * 2018-09-25 2021-10-08 武汉配行天下科技有限公司 一种免注册的高效信息传递与文件签收方法
WO2020085226A1 (ja) * 2018-10-22 2020-04-30 パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカ 制御方法、コンテンツ管理システム、プログラム、及び、データ構造
CN110263579B (zh) * 2018-11-16 2021-05-11 腾讯科技（深圳）有限公司 一种数据处理方法、系统及相关设备
CN109615516B (zh) * 2018-12-05 2021-04-16 腾讯科技（深圳）有限公司 资源转移方法、装置、电子设备及存储介质
CN111027971B (zh) 2018-12-07 2023-08-22 深圳市智税链科技有限公司 在区块链网络中确定记账节点的方法、代理节点和介质
JP7093737B2 (ja) * 2019-03-05 2022-06-30 株式会社日立製作所 決済システム及び決済方法
CN111091429B (zh) * 2019-03-06 2024-03-22 深圳市智税链科技有限公司 电子票据标识分配方法及装置、电子票据生成系统
CN109934590B (zh) * 2019-03-21 2023-07-18 深圳市迅雷网络技术有限公司 一种基于区块链的数据处理方法、装置、电子设备及介质
CN110147992B (zh) * 2019-04-29 2023-08-04 创新先进技术有限公司 基于区块链的账单生成方法及装置和电子设备
US11049115B2 (en) 2019-07-31 2021-06-29 Advanced New Technologies Co., Ltd. Blockchain-based bill write-off method, apparatus, electronic device, and storage medium
CN110458677A (zh) * 2019-07-31 2019-11-15 阿里巴巴集团控股有限公司 基于区块链的票据核销方法及装置、电子设备、存储介质
US10789628B2 (en) 2019-07-31 2020-09-29 Alibaba Group Holding Limited Blockchain-based bill number allocation method, apparatus and electronic device
CN110458631B (zh) * 2019-07-31 2020-11-10 创新先进技术有限公司 基于区块链的票据号码分配方法、装置及电子设备
CN110442631A (zh) * 2019-08-07 2019-11-12 北京艾摩瑞策科技有限公司 关于区块链上的知识付费关联数据处理方法及其装置
CN110417917B (zh) * 2019-08-26 2020-09-29 京东数字科技控股有限公司 用于票据流转的方法、系统、计算机设备和介质
CN110633963B (zh) * 2019-09-16 2023-12-12 腾讯科技（深圳）有限公司 电子票据处理方法、装置、计算机可读存储介质和设备
CN110659906B (zh) * 2019-09-20 2022-06-24 腾讯科技（深圳）有限公司 票据信息处理方法、相关设备及介质
CN110598457B (zh) * 2019-09-24 2023-11-24 腾讯科技（深圳）有限公司 一种票据处理方法、装置、处理设备及计算机存储介质
CN112711565B (zh) * 2019-10-25 2024-04-12 航天信息股份有限公司 一种基于区块链的票单管理方法、系统、装置及存储介质
CN111275462A (zh) * 2020-01-22 2020-06-12 腾讯科技（深圳）有限公司 一种基于区块链网络的票据验证方法、装置及存储介质
CN111259053A (zh) * 2020-02-03 2020-06-09 中国银联股份有限公司 一种账单查询的方法及装置
JP7224653B2 (ja) * 2020-02-13 2023-02-20 株式会社モールサービス 電子チケット管理システム、電子チケット管理方法及び電子チケット管理プログラム
CN111445251B (zh) * 2020-04-16 2024-04-12 中国银行股份有限公司 一种重要空白凭证的处理方法、系统及区块链平台
CN111784517A (zh) * 2020-06-24 2020-10-16 杭州溪塔科技有限公司 基于区块链的联票管理方法、系统、电子设备及存储介质
WO2022036505A1 (zh) * 2020-08-17 2022-02-24 深圳技术大学 大宗商品交易信息共享方法、系统及存储介质
CN111935324B (zh) * 2020-10-14 2021-03-30 深圳华工能源技术有限公司 适用于配用电系统节能领域的区块链技术应用方法及系统
CN112258176A (zh) * 2020-11-03 2021-01-22 天津理工大学 一种基于区块链的信用支付流转方法及系统

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN105976232A (zh) * 2016-06-24 2016-09-28 深圳前海微众银行股份有限公司 资产交易方法和装置
US20160330034A1 (en) * 2015-05-07 2016-11-10 Blockstream Corporation Transferring ledger assets between blockchains via pegged sidechains
CN106452785A (zh) * 2016-09-29 2017-02-22 财付通支付科技有限公司 区块链网络、分支节点及区块链网络应用方法
CN106952094A (zh) * 2017-03-10 2017-07-14 腾讯科技（深圳）有限公司 电子票据管理方法及装置

Family Cites Families (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6304857B1 (en) * 1998-06-08 2001-10-16 Microsoft Corporation Distributed electronic billing system with gateway interfacing biller and service center
KR20020003852A (ko) * 2001-12-18 2002-01-15 이계철 데이터 통신망을 이용한 폐쇄형 전자 어음 거래 시스템 및그 방법
JP2003256651A (ja) * 2002-03-06 2003-09-12 Shinkin Central Bank 申請データの認証サービス方法
KR100512151B1 (ko) * 2004-09-07 2005-09-05 한국슈퍼체크 주식회사 전자어음 매매중개 시스템 및 방법
WO2014049700A1 (ja) * 2012-09-26 2014-04-03 株式会社日立システムズ 自動請求書発行システム
SE542966C2 (en) * 2015-07-10 2020-09-22 Strawpay AB Methods and computer programs for efficient payments using digital promissory notes
US20170017954A1 (en) * 2015-07-14 2017-01-19 Fmr Llc Point-to-Point Transaction Guidance Apparatuses, Methods and Systems
US10402792B2 (en) * 2015-08-13 2019-09-03 The Toronto-Dominion Bank Systems and method for tracking enterprise events using hybrid public-private blockchain ledgers
CN106127578A (zh) * 2016-06-20 2016-11-16 深圳市淘淘谷信息技术有限公司 一种用区块链来表现有价证券流通的方法
CN106412037A (zh) * 2016-09-19 2017-02-15 中国银联股份有限公司 基于区块链结构的安全性电子文件处理系统及方法
CN107066893B (zh) * 2017-02-28 2018-11-09 腾讯科技（深圳）有限公司 区块链中账户信息的处理方法和装置

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20160330034A1 (en) * 2015-05-07 2016-11-10 Blockstream Corporation Transferring ledger assets between blockchains via pegged sidechains
CN105976232A (zh) * 2016-06-24 2016-09-28 深圳前海微众银行股份有限公司 资产交易方法和装置
CN106452785A (zh) * 2016-09-29 2017-02-22 财付通支付科技有限公司 区块链网络、分支节点及区块链网络应用方法
CN106952094A (zh) * 2017-03-10 2017-07-14 腾讯科技（深圳）有限公司 电子票据管理方法及装置

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See also references of EP3594884A4

Cited By (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2020057002A1 (zh) * 2018-09-18 2020-03-26 深圳壹账通智能科技有限公司 基于区块链的发票数据共享系统以及方法
US11228439B2 (en) * 2019-01-02 2022-01-18 Jiaping Wang Scale out blockchain with asynchronized consensus zones
US10956903B2 (en) 2019-07-31 2021-03-23 Advanced New Technologies Co., Ltd. Obtaining a blockchain-based, real-name, electronic bill
TWI723783B (zh) * 2019-07-31 2021-04-01 開曼群島商創新先進技術有限公司 基於區塊鏈的票據實名領取方法、裝置及電子設備
US11210660B2 (en) 2019-07-31 2021-12-28 Advanced New Technologies Co., Ltd. Obtaining a blockchain-based, real-name, electronic bill
WO2021117515A1 (ja) * 2019-12-13 2021-06-17 株式会社日立製作所 電子資産管理方法、及び電子資産管理装置
JP7316921B2 (ja) 2019-12-13 2023-07-28 株式会社日立製作所 電子資産管理方法、及び電子資産管理装置

Also Published As

Publication number Publication date
CN106952094B (zh) 2018-09-04
EP3594884A4 (en) 2020-12-09
JP2019537798A (ja) 2019-12-26
EP3594884A1 (en) 2020-01-15
US10977632B2 (en) 2021-04-13
JP7108611B2 (ja) 2022-07-28
KR20190099076A (ko) 2019-08-23
CN106952094A (zh) 2017-07-14
US20190244186A1 (en) 2019-08-08
KR102277998B1 (ko) 2021-07-15

Similar Documents

Publication Publication Date Title
WO2018161903A1 (zh) 电子票据管理方法、装置及存储介质
US11222316B2 (en) Real time virtual draft system and method
KR101837166B1 (ko) 블록체인 내의 블록별로 발란스 데이터베이스를 관리하여 통화를 발행 및 지급 결제하는 방법과 이를 이용한 서버
US10742398B2 (en) Bespoke programmable crypto token
US20220309477A1 (en) Method for issuing, redeeming, refunding, settling and revoking electronic voucher by using utxo-based protocol, and server employing same
JP5186790B2 (ja) 電子マネー取引方法、及び電子マネーシステム
WO2019015474A1 (zh) 用于提高票据交易安全性的管理方法、装置及系统
JP2023174862A (ja) ブロックチェーン依存動作セットのためのシステム及び方法
CN110226177A (zh) 使用基于utxo的协议提供支付网关服务的方法及利用其的服务器
CN108510276B (zh) 数据处理方法、装置和系统
KR101837167B1 (ko) Utxo 기반 프로토콜에서 머클 트리 구조를 사용하여 통화를 발행 및 지급 결제하는 방법과 이를 이용한 서버
CN105874495A (zh) 使用令牌确保数据传送风险的系统和方法
CN112037068A (zh) 资源转移方法、系统、装置、计算机设备和存储介质
WO2020233236A1 (zh) 一种应用于区块链的可消耗凭证的验证方法和装置
CN118101216A (zh) 在区块链网络上通信、存储和处理数据的基于区块链的系统和方法
CN110874742A (zh) 一种基于区块链和智能合约的支付方法及装置
CN110941840B (zh) 一种数据处理方法、系统及终端
JP6721724B2 (ja) 支払い主体の拡張を促進する方法およびデバイス
KR101849918B1 (ko) Utxo 기반 프로토콜을 사용하여 통화를 발행 및 지급 결제하는 방법과 이를 이용한 서버
CN109146478A (zh) 在区块链网络中用于操作数字凭证的方法、装置及介质
WO2021121030A1 (zh) 一种资源转移的方法及结账终端、服务器节点
KR20220076486A (ko) 블록체인 트랜잭션들을 위한 콜-백 메커니즘들
Malladi Towards Formal Modeling and Analysis of UPI Protocols
KR102171395B1 (ko) 블록체인 기반의 원리금 수취증서 제공 방법
US20220122177A1 (en) Blockchain-based transaction

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 18763957

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 2019526479

Country of ref document: JP

Kind code of ref document: A

ENP Entry into the national phase

Ref document number: 20197022822

Country of ref document: KR

Kind code of ref document: A

NENP Non-entry into the national phase

Ref country code: DE

WWE Wipo information: entry into national phase

Ref document number: 2018763957

Country of ref document: EP

ENP Entry into the national phase

Ref document number: 2018763957

Country of ref document: EP

Effective date: 20191010