CN114830159A - Method and apparatus for mitigating bill financing fraud - Google Patents

Abstract

A method, apparatus, and device, including a computer program stored on a computer readable medium, for mitigating ticket financing fraud. The method comprises the following steps: receiving a first transaction from a first user, the first transaction including a first commitment value and a first proof of a ticket, the first commitment value generated based on a first token; verifying the first proof; receiving a second transaction from a second user, the second transaction including the first token, a second commitment value, and a second proof, the second commitment value generated based on a second token and an authentication file generated by the second user; determining that the first token is valid and verifying the second proof; receiving a third transaction from a third user, the third transaction comprising the second token and a third proof; determining that the second token is valid and verifying the third proof to determine that there is no ticket financing fraud.

Description

Method and apparatus for mitigating bill financing fraud

Technical Field

This specification relates generally to computer technology and, more particularly, to methods and apparatus for mitigating ticket financing fraud.

Background

Ticket financing is one way for businesses to borrow accounts receivable (including, for example, accounts receivable by customers). The financing of the instrument helps the business improve cash flow, pay employees and suppliers, and may reinvest on operations and growth earlier than if the business had to wait until the customer paid the balance in full.

One of the risks associated with the financing of a ticket is fraud. For example, some businesses may commit fraud by unilaterally making counterfeit tickets and attempting to borrow money using such tickets. Some businesses implement fraud by colluding with others. Some businesses may implement fraud by borrowing money from multiple funds providers or investors multiple times with the same instrument. Such fraudulent activity is difficult to detect and mitigate.

Disclosure of Invention

In one aspect, a computer-implemented method for mitigating ticket financing fraud comprises: receiving a first transaction from a first user, the first transaction including a first commitment value for a ticket and a first proof for proving that the first user is an issuer of the ticket, the first commitment value generated based on a first token corresponding to the first user; verifying the first proof; receiving a second transaction from a second user, wherein the second transaction comprises a first token corresponding to the first user, a second commitment value of the ticket, and a second certificate for proving that the second user authenticates the ticket, and the second commitment value is generated based on a second token corresponding to the second user and an authentication file generated by the second user; determining that the first token is valid and verifying the second proof; receiving a third transaction from a third user, the third transaction including a second token corresponding to the second user and a third proof generated by the third user; the second token is determined to be valid and the third proof is verified to determine that there is no instrument financing fraud.

In another aspect, a computer-implemented method for mitigating ticket financing fraud comprises: receiving a first transaction from a first user, the first transaction including a first commitment value for a ticket and a first proof for proving that the first user is an issuer of the ticket, the first commitment value generated based on a first token corresponding to the first user; verifying the first proof; receiving a second transaction from a second user, wherein the second transaction comprises a first token corresponding to the first user, a second commitment value of the ticket, and a second proof for proving that the second user is a receiver of the ticket, and the second commitment value is generated based on a second token corresponding to the second user; determining that the first token is valid and verifying the second proof; receiving a third transaction from a third user, wherein the third transaction comprises a second token corresponding to the second user, a third commitment value of the ticket, and a third proof for proving that the third user has approved and authenticated the ticket, and the third commitment value is generated based on a third token corresponding to the third user and an authentication file generated by the third user; determining that the second token is valid and verifying the third proof; receiving a fourth transaction from a fourth user, the fourth transaction including a third token corresponding to the third user and a fourth proof generated by the fourth user; and validating the third token to verify the fourth proof to determine that there is no instrument financing fraud.

In another aspect, an apparatus for mitigating ticket financing fraud comprises: one or more processors; one or more computer-readable memories coupled to the one or more processors and having instructions stored thereon that are executable by the one or more processors to: receiving a first transaction from a first user, the first transaction including a first commitment value for a ticket and a first proof for proving that the first user is an issuer of the ticket, the first commitment value generated based on a first token corresponding to the first user; verifying the first proof; receiving a second transaction from a second user, wherein the second transaction comprises a first token corresponding to the first user, a second commitment value of the ticket, and a second certificate for proving that the second user authenticates the ticket, and the second commitment value is generated based on a second token corresponding to the second user and an authentication file generated by the second user; determining that the first token is valid and verifying the second proof; receiving a third transaction from a third user, the third transaction including a second token corresponding to the second user and a third proof generated by the third user; the second token is determined to be valid and the third proof is verified to determine that there is no instrument financing fraud.

In yet another aspect, a non-transitory computer-readable medium having instructions stored therein, which when executed by a processor of a device, cause the device to perform a method for mitigating ticket financing fraud. The method comprises the following steps: receiving a first transaction from a first user, the first transaction including a first commitment value for a ticket and a first proof for proving that the first user is an issuer of the ticket, the first commitment value generated based on a first token corresponding to the first user; verifying the first proof; receiving a second transaction from a second user, wherein the second transaction comprises a first token corresponding to the first user, a second commitment value of the ticket, and a second certificate for proving that the second user authenticates the ticket, and the second commitment value is generated based on a second token corresponding to the second user and an authentication file generated by the second user; determining that the first token is valid and verifying the second proof; receiving a third transaction from a third user, the third transaction including a second token corresponding to the second user and a third proof generated by the third user; the second token is determined to be valid and the third proof is verified to determine that there is no instrument financing fraud.

Drawings

The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments. In the following description with reference to the drawings, the same numbers in different drawings represent the same or similar elements, unless otherwise indicated.

Fig. 1 is a schematic diagram of a blockchain system according to an embodiment.

Fig. 2 is a schematic diagram of a computing device for implementing a node in a blockchain system, according to an embodiment.

Fig. 3 is a flow diagram of a method for mitigating ticket financing fraud, under an embodiment.

Fig. 4 is a flow diagram of a method for mitigating ticket financing fraud, under an embodiment.

Fig. 5 is a flow diagram of a method for mitigating ticket financing fraud, under an embodiment.

Fig. 6 is a flow diagram of a method for mitigating ticket financing fraud, under an embodiment.

FIG. 7 is a block diagram of an apparatus for mitigating ticket financing fraud, according to an embodiment.

Detailed Description

Embodiments of the present specification provide methods and apparatus for mitigating ticket financing fraud. The method and apparatus may utilize a blockchain system to validate tickets submitted by a user. Counterfeit tickets can be detected and fraudulent attempts to borrow money using such counterfeit tickets can be prevented. The method and apparatus may also implement a protocol to determine whether multiple users are in collusion with each other. The method and apparatus may further implement a protocol to determine whether a ticket has been used for ticket financing. If it is determined that a ticket has been used for ticket financing, the method and apparatus may prevent other financing attempts using the same ticket. The method and apparatus may further implement a protocol that protects user privacy. In this manner, the method and apparatus can validate tickets using a blockchain system without revealing the specific content of the ticket to the public.

The embodiments disclosed in this specification have one or more technical effects. In some embodiments, the methods and apparatus require a user to submit a proof in order to validate a ticket submitted by the user. Thus, the method and apparatus can detect counterfeit notes and prevent fraudulent attempts to borrow money using counterfeit notes. In some embodiments, the methods and apparatus support validating tickets using a blockchain system. Thus, the method and apparatus may store the ticket in a data structure that may prevent tampering and manipulation by malicious parties. In some embodiments, the methods and apparatus also support a protocol that can determine whether multiple users are in collusion with each other. Thus, the method and apparatus may use data logging on a blockchain system to detect and prevent collusion. In some embodiments, the methods and apparatus also support a protocol that can calculate a commitment value for a ticket to be validated using a blockchain system. The commitment value (commitment value) computed for the ticket may be associated with a token (token) and a random value. The token may be used to invalidate the commitment value after it is revealed by the user. Thus, the method and apparatus can prevent double financing using the same instrument. The random value may be used to introduce additional randomness to further protect user privacy. Thus, the method and apparatus can validate tickets using a blockchain system without revealing any private information to the public.

A blockchain system, also known as a Distributed Ledger System (DLS) or consensus system, can allow participating parties to store data securely and non-tamperproof. Without reference to any particular use case, the blockchain system may include any DLS and may be used for public, private, and federated blockchain networks. The public blockchain network is open to all entities to use the system and participate in the consensus process. The private blockchain network is provided for a specific entity which centrally controls read and write permissions. A federated blockchain network is provided for a selected group of entities that controls the consensus process, and the federated blockchain network includes an access control layer.

The blockchain system is implemented using a peer-to-peer (P2P) network in which nodes communicate directly with each other, e.g., without the need for a fixed central server. Each node in the P2P network may initiate communication with another node in the P2P network. The blockchain system maintains one or more blockchains.

Blockchains are data structures that store data, such as transactions, in a manner that prevents malicious parties from tampering with and manipulating the data. Transactions stored in this manner may be immutable and subsequently verified. A block chain includes one or more blocks. Each block is connected to the immediately preceding block by a cryptographic hash value (cryptographical hash) comprising the immediately preceding block. Each tile may also include a timestamp, its own cryptographic hash value, and one or more transactions. Transactions that have typically been verified by nodes of a blockchain system may be hashed and encoded into a data structure such as a merkel (Merkle) tree. In the merkel tree, data at leaf nodes of the tree is hashed, and all hash values in each branch of the tree may be joined at the root of that branch. This process continues down the tree until the root of the entire tree, where hash values representing all the data in the tree are stored. A hash value purporting to have transactions stored in the tree may be quickly verified by determining whether it is consistent with the structure of the tree.

The blockchain system includes a network of computing nodes that manage, update, and maintain one or more blockchains. The network may be a public blockchain network, a private blockchain network, or a federated blockchain network. For example, many entities, such as hundreds, thousands, or even millions of entities, may operate in a public blockchain network, and each entity operates at least one node in the public blockchain network. Thus, a public blockchain network may be considered a public network with respect to participating entities. Sometimes, most entities (nodes) must sign each chunk in order for the chunk to be valid and added to the blockchain of the blockchain network. Exemplary public blockchain networks include peer-to-peer (peer-to-peer) payment networks that utilize distributed ledgers referred to as blockchains.

Typically, public blockchain networks may support open transactions. The open transaction is shared by all nodes within the public blockchain network and stored in the global blockchain. A global blockchain is a blockchain that is replicated across all nodes, and all nodes are in a fully-consensus state with respect to the global blockchain. To achieve consensus (e.g., agree to add blocks to a blockchain), a consensus protocol is implemented in a public blockchain network. Examples of consensus protocols include proof of work (POW) (e.g., implemented in some cryptocurrency networks), proof of rights (POS), and proof of authority (POA).

Typically, a private blockchain network may be provided for a particular entity that centrally controls read and write permissions. The entity controls which nodes can participate in the blockchain network. Thus, private blockchain networks are often referred to as licensed networks, which limit who is allowed to participate in the network, as well as the extent to which they participate (e.g., only in certain transactions). Various types of access control mechanisms may be used (e.g., existing participants voting to add a new entity, and regulatory authorities may control admission).

Typically, a federated blockchain network is private between the participating entities. In a federated blockchain network, the consensus process is controlled by a set of authorized nodes, one or more of which are operated by respective entities (e.g., financial institutions, insurance companies). For example, a federation of ten (10) entities (e.g., financial institutions, insurance companies) may operate a federated blockchain network, and each entity may operate at least one node in the federated blockchain network. Thus, a federated blockchain network can be considered a private network with respect to participating entities. In some examples, each entity (node) must sign each chunk in order for the chunk to be valid and added to the chain of chunks. In some examples, at least a subset of the entities (nodes) (e.g., at least 7 entities) must sign each tile in order for the tile to be valid and added to the tile chain.

Fig. 1 shows a schematic diagram of a blockchain system 100 according to an embodiment. Referring to fig. 1, a blockchain system 100 may include a plurality of nodes, such as node 102 and 110, configured to operate on a blockchain 120. Nodes 102-110 may form a network 112, such as a point-to-point (P2P) network. Each of nodes 102 and 110 may be a computing device, such as a computer or computer system, configured to store a copy of block chain 120, or may be software, such as a process or application, running on the computing device. Each of the nodes 102 and 110 may have a unique identifier.

Blockchain 120 may include a record growth list in the form of data chunks, such as chunks B1-B5 in fig. 1. Each of tiles B1-B5 may include a timestamp, a cryptographic hash value of a previous tile, and data of the current tile, which may be a transaction such as a monetary transaction. For example, as shown in fig. 1, chunk B5 may include a timestamp, a cryptographic hash value for chunk B4, and transaction data for chunk B5. Further, for example, a hash operation may be performed on a previous chunk to generate a cryptographic hash value for the previous chunk. The hash operation may convert inputs of various lengths into fixed-length encrypted outputs by a hash algorithm, such as SHA-256.

Node 102-110 may be configured to perform operations on blockchain 120. For example, when a node (e.g., node 102) wants to store new data onto blockchain 120, the node may generate a new block to be added to blockchain 120 and broadcast the new block to other nodes in network 112, such as node 104 and 110. Based on the validity of the new tile, e.g., its signature and transaction validity, other nodes may determine to accept the new tile so that node 102 and other nodes may add the new tile to their respective copies of blockchain 120. As the process is repeated, more and more data chunks may be added to blockchain 120.

Fig. 2 illustrates a schematic diagram of a computing device 200 for implementing a node (e.g., node 102 (fig. 1)) in a blockchain system, according to an embodiment. Referring to fig. 2, computing device 200 may include a communication interface 202, a processor 204, and a memory 206.

The communication interface 202 may facilitate communication between the computing device 200 and devices implementing other nodes in a network, such as node 104 and 110 (FIG. 1). In some embodiments, the communication interface 202 is configured to support one or more communication standards, such as an internet standard or protocol, an Integrated Services Digital Network (ISDN) standard, and so on. In some embodiments, the communication interface 202 may include one or more of the following: a Local Area Network (LAN) card, cable modem, satellite modem, data bus, cable, wireless communication channel, radio-based communication channel, cellular communication channel, Internet Protocol (IP) based communication device, or other communication device for wired and/or wireless communication. In some embodiments, the communication interface 202 may be based on a public cloud infrastructure, a private cloud infrastructure, a hybrid public/private cloud infrastructure.

The processor 204 may include one or more special-purpose processing units, Application Specific Integrated Circuits (ASICs), Field Programmable Gate Arrays (FPGAs), or various other types of processors or processing units. The processor 204 is coupled to the memory 206 and is configured to execute instructions stored in the memory 206.

Memory 206 may store processor-executable instructions and data, such as a copy of blockchain 120 (fig. 1). The memory 206 may include any type or combination of volatile or non-volatile memory devices, such as Static Random Access Memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic memory, flash memory, or a magnetic or optical disk. When the instructions in memory 206 are executed by processor 204, computing device 200 may perform operations on blockchain 120.

Fig. 3 illustrates a flow diagram of a method 300 for mitigating ticket financing fraud, in accordance with an embodiment. Referring to fig. 3, multiple users may own accounts on a blockchain, such as blockchain 120 (fig. 1). Blockchains may be implemented to support various types of users or parties, including, for example, individuals, businesses, banks, financial institutions, hospitals, and other types of companies, organizations, and the like.

For illustration, three users are depicted in FIG. 3. Including sellers, banks, and trusted users known as authorities (authorities). Assume that the seller is interested in obtaining a financing of a bill from a bank. The seller may attempt to obtain this financing by claiming to have an open instrument issued to the buyer (and possibly the user of the blockchain, as will be described below with reference to FIG. 4). The seller may instrument for various reasons, including, for example, services offered in the past or in the future or products sold to the buyer. If the seller does have an open ticket to the buyer, the bank may be willing to provide ticket financing to the seller if the seller agrees to use the open ticket to obtain financing. However, banks may wish to ensure that tickets do exist and have not been used to obtain financing from other institutions. Thus, a bank may require a seller to prove the validity of a ticket before the bank agrees to provide the seller with the financing of the ticket.

In some embodiments, if the seller is able to request that an authority confirm the validity of the ticket based on the method 300 described in detail below, the bank may be willing to accept the validity of the ticket. In some embodiments, the authority may be a trusted user, such as a government agency or customs officer. The authority may also be a trusted user on behalf of a governmental agency or customs officials.

At step 302, the seller may generate a digital ticket. The digital ticket may take a variety of formats including, for example, a standardized format agreed to by users of the blockchain. The digital ticket may contain data fields including, for example, an identity or identifier of the seller, an identity or identifier of the buyer, a description of the product or service offered, an amount due, payment terms (or payment method), and the like.

The seller may also generate a commitment value recorded on the blockchain at step 302. In some embodiments, the seller may calculate the commitment value CM _ INVOMICE by considering at least a portion of the information of the ticket itself, the seller information, and the seller information. In some embodiments, CM _ INVOICE may be calculated based on a one-way function. One of ordinary skill in the art will appreciate that the function

Is unidirectional, if, given a random element

It is difficult to calculate y ∈ D to obtain g (y) ═ x. In other words, it is difficult to calculate the input variable value of the one-way function from the output variable value of the one-way function, so that the function cannot be inverted in practice, and thus the function is referred to as "one-way". Hash functions, such as SHA256, are examples of one-way functions.

For example, in some embodiments, CM _ INVOLICE may be computed as a hash of (PK _ SELLER, PK _ BUYER, INVOLICE _ DIGEST, TN, R), where PK _ SELLER and PK _ BUYER represent the public keys of the SELLER and BUYER, respectively, and INVOLICE _ DIGEST represents a hash of the digital ticket, or a hash of one or more portions of the digital ticket. The TN may represent a token generated by the seller that may be used to prevent the seller from using the digital ticket multiple times to obtain financing (i.e., prevent double financing). In some embodiments, the TN may comprise a random number. However, it should be understood that a TN may also include alphanumeric values, and in some embodiments, a TN may include a serial number. R may represent a vendor-generated random factor to further protect the information contained in PK _ SELLER, PK _ BUYER, and INVOIICE _ DIGEST. In some embodiments, R may be a random number or a random alphanumeric value.

In step 302, the SELLER may also generate a zero knowledge PROOF, denoted as SELLER' S _ PROOF. Zero knowledge proof refers to a technique that allows a prover to prove a claim to a verifier without revealing any information beyond the validity of the claim itself. At step 302, the seller is a prover that can prove to the blockchain or to an intelligent contract (as a verifier) executing on the blockchain that the seller is the true issuer of the ticket in question. The seller may attempt to prove this by indicating: (1) the CM _ INVOLICE format is correct and (2) the seller is indeed the seller itself.

In an embodiment, to prove that the CM _ INVOLICE format is correct, the vendor may prove to the blockchain that (PK _ SELLER, PK _ BUYER, INVOLICE _ DIGEST, TN, R) the commitment value is CM _ INVOLICE. In an embodiment, to prove that the SELLER is the SELLER itself, the SELLER may prove to the block chain that the SELLER owns the SELLER's private key, or that PK _ SELLER ═ h (SK _ SELLER) is the block chain, where SK _ SELLER represents a private key known only to the SELLER, and h () is a hash function used to compute the public key from the private key.

In some embodiments, the vendor and blockchain may agree to implement Zero Knowledge proof techniques, such as Zero-Knowledge concise Non-Interactive proof of Knowledge (abbreviated zk-SNARK) and the like. The seller may prove to the blockchain that the seller knows the private input w, such that a particular relationship holds between the public inputs x, and w. In some embodiments, the relationship may be defined as an arithmetic circuit (arithmetric circuit). In some embodiments, the arithmetic circuitry may be defined based on a polynomial equation that may be evaluated based on x and w. In some embodiments, the attestation key and the verification key may be generated during a setup phase based on the arithmetic circuitry and one or more security parameters established for zero-knowledge attestation. One of ordinary skill in the art will appreciate that the setup phase may be performed by a trusted party or by multiple independent parties collaborating using multi-party computations.

In some embodiments, the vendor may set x to CM _ INVOLICE and w to values generated based on PK _ SELLER, PK _ BUYER, INVOLICE _ DIGEST, TN, R, and SK _ SELLER. For example, w can be generated by connecting PK _ SELLER, PK _ BUYER, INVOICE _ DIGEST, TN, R, and SK _ SELLER together. In this way, the vendor can generate SELLER' S _ PROOF using the private and public inputs and the attestation key to prove to the blockchain that the vendor possesses the private input w. In some embodiments, the blockchain may use the common input and the verification key generated during the setup phase to verify SELLER' S _ PROOF. In some embodiments, the blockchain may accept the seller's declaration as true if the blockchain is certified by the seller that the seller owns the private input w.

At step 304, the SELLER may submit a transaction to the blockchain, the load (payload) of the transaction containing { CM _ INVOME, SELLER' S _ PROOF }. For purposes of illustration, this transaction may be referred to as an "ISSUE _ INVOIC" transaction.

At step 306, the blockchain may verify SELLER' S _ PROOF to determine if the SELLER possesses the private input w. In some embodiments, the blockchain may utilize one or more intelligent contracts executed on the blockchain to implement the determination. An intelligent contract may be a computer protocol executed in the form of computer code that is incorporated into a blockchain to facilitate, verify, or perform negotiation or fulfillment of a contract. For example, users of the blockchain may program agreed-upon terms into smart contracts using a programming language such as C + +, Java, Solidity, Python, etc., and when the terms are met, the smart contracts may be automatically executed in the blockchain, e.g., to perform transactions. As another example, a smart contract may include a plurality of subroutines or functions, each of which may be a series of program instructions that perform a specific task. An intelligent contract may be an operation code that executes without human interaction, in whole or in part.

In some embodiments, intelligent contracts may be incorporated into blockchains to determine whether SELLER' S _ PROOF is acceptable. The smart contract may use the common input and the authentication key to authenticate the SELLER' S _ PROOF. If SELLER' S _ PROOF fails verification, the smart contract may refuse to have the SELLER proceed. On the other hand, if SELLER 'S _ PROOF can pass verification, then the intelligent contract can determine that SELLER' S _ PROOF is acceptable and continue to record CM _ INVOICE in the pool of tickets submitted by the SELLER. In some embodiments, the pool of tickets submitted by the seller may be structured as the Mercker tree T _ INVOLICE, and CM _ INVOLICE may be recorded on the leaf nodes of the Mercker tree T _ INVOLICE.

At step 308, the seller may proceed to require an authority to validate the digital ticket generated by the seller. In some embodiments, the seller may send the digital ticket and the value of TN and the value of R privately to an authority through an off-channel communication channel. The vendor may also send CM _ INVOMICE to the authority. Alternatively or additionally, the authority may reconstruct CM _ INVOMICE from the digital ticket and the values of TN and R received from the seller.

At step 310, the authority may check the digital ticket to determine if the digital ticket is valid. For example, the authority may compare the outstanding amount declared in the digital ticket to a record maintained or accessible by the authority. For example, if the seller is an exporter and a digital ticket is issued for a product exported to a overseas buyer, the authority may compare the digital ticket to records maintained by customs officials to determine if there is a difference in product description and amount due. The authority may also compare the digital ticket to other types of records including, for example, tax records, financial disclosures, and the like.

In some embodiments, the authority may invalidate the digital ticket if the authority determines that CM _ INVOMICE is not recorded in the SELLER's submitted ticket pool, or that the recorded CM _ INVOMICE does not match the commitment value of (PK _ SELLER, PK _ BUYER, INVOMICE _ DIGEST, TN, R). In this manner, if the seller attempts to bypass step 304 and 306, or attempts to change the digital ticket or change the value of TN or R, such an attempt may be detected by the authority, who may then invalidate the digital ticket and prevent fraud. On the other hand, if the authority determines that the digital ticket is valid, the authority may proceed to generate the certified commitment value to record on the blockchain. In some embodiments, the authority may calculate the certified commitment value, CM _ CERT _ INVOICE, as: COMMITTENT (PK _ SELLER, PK _ BUYER, INVOICE _ DIGEST, CERT _ DIGEST, TN ', R').

In some embodiments, CM _ CERT _ INVOLICE may be computed based on the same one-way function used by the vendor to compute CM _ INVOLICE, where the values of PK _ SELLER, PK _ BUYER, and INVOLICE _ DIGEST are the same. CERT DIGEST may represent a hash value of one or more authentication files generated by an authority. The certification documentation may take a variety of formats including, for example, a standardized format established by a government agency or customs officer for providing certification. The authority may also generate a new TN 'and a new R'. In this manner, the authority may calculate a commitment value that is different from the commitment value calculated by the seller, effectively preventing unrelated users from joining the two commitment values together, and thus preventing unrelated users from joining the seller and the authority together.

In step 310, the AUTHORITY may also generate a zero knowledge PROOF, denoted as AUTHORITY' S _ PROOF. The AUTHORITY may generate an AUTHORITY' S _ PROOF to prove to the blockchain that the AUTHORITY has reviewed and authenticated the ticket provided by the vendor. The authority may attempt to prove this by noting: (1) CM _ INVOLOIC is in correct format, (2) CM _ INVOLOIC is recorded in a ticket pool submitted by the seller, and (3) CM _ CERT _ INVOLOIC is in correct format.

In an embodiment, to prove that the CM _ INVOLICE format is correct, the authority may prove to the blockchain that the authority knows the values of PK _ SELLER, PK _ BUYER, INVOLICE _ DIGEST, TN, and R and that the commitment value of (PK _ SELLER, PK _ BUYER, INVOLICE _ DIGEST, TN, R) is CM _ INVOLICE. In an embodiment, to prove that CM _ INVOMICE is recorded in a ticket pool submitted by a vendor, an authority may prove to the blockchain that CM _ INVOMICE is a valid leaf node in the Mercker tree T _ INVOMICE. In an embodiment, to prove that the CM _ CERT _ INVOEICE format is correct, the vendor may prove to the blockchain that the commitment value of (PK _ SELLER, PK _ BUYER, INVOECE _ DIGEST, CERT _ DIGEST, TN ', R') is CM _ CERT _ INVOECE.

In some embodiments, the authority and blockchain may agree to implement the zero-knowledge proof technique described above. For example, the authority may prove to the blockchain that the authority knows the private input w, such that a particular relationship holds between x, and w for the public input. In some embodiments, the relationship may be defined as an arithmetic circuit, which may be defined based on a polynomial equation that may be evaluated based on x and w. In some embodiments, the attestation key and the verification key may be generated during a setup phase based on the arithmetic circuitry and one or more security parameters established for zero-knowledge attestation. In some embodiments, the authority may set x to a value containing TN and CM _ CERT _ INVOLICE, and set w to a value generated based on PK _ SELLER, PK _ BUYER, INVOLICE _ DIGEST, CERT _ DIGEST, R, TN ', R', and CM _ INVOLICE. In this way, the AUTHORITY may generate an AUTHORITY' S _ PROOF to prove to the blockchain that the AUTHORITY possesses the private input w. In some embodiments, if the blockchain is authorized to certify that the authority has private input w, the blockchain may accept the assertion of the authority as true.

At step 312, the authority may send the authentication file and the values of TN 'and R' to the seller so that the seller may then use the authentication file to obtain financing from the bank. At step 314, the AUTHORITY may submit a transaction to the blockchain, the payload of the transaction containing { TN, CM _ CERT _ INVOICE, AUTHORITY' S _ PROOF }. For purposes of illustration, this transaction may be referred to as an "AUTHORITY _ CERTIFIED _ INVOICE" transaction. In some embodiments, the authority may have a public trusted identity registered on the blockchain. In these embodiments, the authority may sign the transaction and payload using the authority's private signing key.

At step 316, the blockchain may utilize the intelligent contract to verify the identity of the authority (e.g., based on the signature the authority uses to sign the transaction) and check whether the TN contained in the load has been used or consumed. In some embodiments, the smart contract may maintain a list of tokens used on the blockchain to record the tokens used. If the TN contained in the payload is listed in the used token list, the smart contract may refuse to proceed because the seller is trying to obtain financing multiple times using the same digital ticket. On the other hand, if the TN contained in the load is not listed in the used-token list, the smart contract may proceed to verify that AUTHORITY' S _ PROOF is acceptable. The smart contract may use the public input and the authentication key to authenticate the authorshoof. If the AUTHORITY 'S _ PROOF can be verified, the intelligent contract can determine that AUTHORITY' S _ PROOF is acceptable and continue to record CM _ CERT _ INVOME in the authoritatively authenticated ticket pool. In some embodiments, an authoritatively authenticated ticket pool may be constructed as a Mercker tree T _ CERT _ INVOICE and CM _ CERT _ INVOICE may be recorded on leaf nodes of the Mercker tree T _ CERT _ INVOICE. The smart contract may also add a TN to the used token list to indicate that the TN has been used, thus invalidating the TN for future use.

At step 318, the seller may proceed to request financing of the instrument from the bank. In some embodiments, the seller may send the digital ticket, the authentication file, and the values of TN 'and R' privately to the bank through an off-channel communication channel. The vendor may also calculate the value of CM _ CERT _ INVOMICE and send the value of CM _ CERT _ INVOMICE to the bank. Alternatively or additionally, the bank may reconstruct CM _ CERT _ INVOICE from the digital ticket, the authentication file, and the values of TN 'and R' received from the seller.

At step 320, the bank may determine whether the digital ticket and authentication document are valid. For example, if the digital ticket is not authoritatively authenticated, the bank may invalidate the digital ticket. The bank may make this determination by determining whether CM _ CERT _ INVOMICE is recorded in an authoritatively authenticated ticket pool (e.g., in the Mercker tree T _ CERT _ INVOMICE). If CM _ CERT _ INVOMICE is not recorded in the authoritatively authenticated ticket pool, the bank can confirm that the digital ticket is invalid and refuse the seller to proceed. On the other hand, if CM _ CERT _ INVOICE is recorded in an authoritatively authenticated ticket pool, the bank may determine that the digital ticket is valid. The bank may then proceed to decide whether to provide the seller with the instrument financing. Since the CM _ CERT _ INVOMICE is generated at least in part from the authentication file, the bank can only find the CM _ CERT _ INVOMICE in the authoritatively authenticated ticket pool if the bank receives the true authentication file from the seller. In this way, any attempt by the seller to produce a false authentication document is detected, and such fraudulent activity can be prevented.

In some embodiments, the bank may also determine whether the TN' provided by the seller has been used. In some embodiments, the bank may invoke a smart contract executing on the blockchain to confirm whether TN' is listed in the used token list. If TN' is listed in the used token list, the bank may refuse to proceed because the seller is trying to obtain financing multiple times using the same digital ticket. If TN' is not listed in the used token list, the bank may proceed to decide whether to provide the seller with the instrument financing.

It should be appreciated that a bank may consider various factors in determining whether to provide a seller with a financing of a ticket. Such factors may include, for example, the size of the instrument, the seller's credit score and credit history, previous transactions by the bank with the seller, and so forth. Other factors may include, for example, the credit score of the buyer and previous transactions by the bank with the buyer.

If the bank decides to deny the seller's request for financing of the instrument, the bank may communicate the decision privately to the seller through a linked communication channel, in which case the seller may choose to repeat step 318 and request financing of the instrument from a different funding provider. On the other hand, if the BANK decides to provide the seller with the instrument financing, the BANK may continue to generate a zero knowledge PROOF, denoted BANK 'S _ PROOF, at step 320 to prove to the blockchain that the BANK has verified the validity of the seller' S requirements to provide the instrument financing. The bank may attempt to prove this by noting: (1) CM _ CERT _ INVOLICE is in the correct format, (2) CM _ CERT _ INVOLICE is recorded in a ticket pool for authoritative certification.

In an embodiment, to prove that the CM _ CERT _ INVOEICE format is correct, the bank may prove to the blockchain that the bank knows the values of PK _ SELLER, PK _ BUYER, INVOECE _ DIGEST, CERT _ DIGEST, TN 'and R' and that the commitment value of (PK _ SELLER, PK _ BUYER, INVOECE _ DIGEST, CERT _ DIGEST, TN ', R') is CM _ CERT _ INVOECE. In an embodiment, to prove that CM _ CERT _ INVOICE is recorded in an authoritatively authenticated ticket pool, a bank may prove to the blockchain that CM _ CERT _ INVOICE is a valid leaf node in the Mercker tree T _ CERT _ INVOICE.

In some embodiments, the bank and blockchain may agree to implement the zero-knowledge proof technique described above. For example, a bank may prove to the blockchain that the bank knows the private input w, such that a particular relationship holds between x, and w for the public input. In some embodiments, the relationship may be defined as an arithmetic circuit, which may be defined based on a polynomial equation that may be evaluated based on x and w. In some embodiments, the attestation key and the verification key may be generated during a setup phase based on the arithmetic circuitry and one or more security parameters established for zero-knowledge attestation. In some embodiments, the bank may set x to TN 'and w to values generated based on PK _ SELLER, PK _ BUYER, INVOEICE _ DIGEST, CERT _ DIGEST, R', and CM _ CERT _ INVOEICE. In this way, the BANK can generate BANK' S _ pro to prove to the blockchain that the BANK owns the private input w. In some embodiments, if the blockchain is certified by the bank that the bank owns the private input w, the blockchain may accept the bank's declaration as true.

At step 322, the BANK may submit a transaction to the blockchain, the load of the transaction containing { TN ', BANK' S _ PROOF }. For purposes of illustration, this transaction may be referred to as an "ISSUE _ FINANCING" transaction.

At step 324, the blockchain may use the smart contract to check whether TN' contained within the load has been used. In some embodiments, the smart contract may check whether TN' is listed in the used token list. If TN' is listed in the used token list, the smart contract may refuse to proceed because the seller is trying to obtain financing multiple times using the same digital ticket. If TN 'is not listed in the used token list, the intelligent contract may continue to verify that BANK' S _ PROOF is acceptable. The smart contract may use the public input and the authentication key to authenticate BANK' S _ pro. If BANK 'S _ PROOF can be verified, the smart contract may determine that BANK' S _ PROOF is acceptable and invalidate the TN '(e.g., by adding the TN' to a list of used tokens) and report to the BANK that fraud was not detected based on the received transaction at step 326 so that the BANK may continue to issue ticket financing to the seller.

It should be appreciated that while the above example uses a list of used tokens to record all used tokens, such an embodiment is provided as an example only and is not meant to be limiting. In some embodiments, used tokens generated by a seller may be recorded using one list of used tokens, and used tokens generated by an authority may be recorded using a different list of used tokens. It should be understood that other types of data structures may be used to record used tokens. Further, it should be understood that the above statements of functions, variables, and transactions are presented as examples only and are not meant to be limiting.

Notably, by requiring the user to confirm the validity of the ticket, the method 300 can avoid double financing of invalid tickets. The method 300 may also mitigate fraudulent activities where sellers may make counterfeit tickets and attempt to borrow money using such tickets. The method 300 may further protect privacy by hiding the user identity, amount due, payment terms, and other ticket related information using commitment values. The method 300 may also ensure that transactions recorded on the blockchain cannot be linked by unrelated users, thereby preventing unrelated users from being aware of users related to such transactions. Further, in some embodiments, if the user wants to further hide the number of the "ISSUE _ INVOICE" transaction or the number of the "ISSUE _ FINANCING" transaction that the user submitted to the blockchain, the user may choose to submit such transactions using the one-time anonymous blockchain identity.

It should also be noted that the method 300 may be extended to allow the buyer to confirm the validity of the digital ticket generated by the seller. For example, if the seller misreads the outstanding amount or counterfeit tickets, the buyer can check and invalidate the digital tickets.

Fig. 4 illustrates a flow diagram of a method 400 for mitigating ticket financing fraud, in accordance with an embodiment. For illustration purposes, 4 users are depicted in FIG. 4, including sellers, buyers, banks, and trusted users referred to as authorities. Assuming that the seller is interested in obtaining financing of the instrument from the bank, the bank may require the seller to prove the validity of the instrument before the bank agrees to provide financing of the instrument to the seller. In some embodiments, if the seller can request that the buyer and authority confirm the validity of the ticket based on the method 400 described in detail below, the bank may be willing to accept the validity of the ticket.

At step 402, the SELLER may generate digital tickets, commitment value CM _ INVOME and zero PROOF of knowledge SELLER' S _ PROOF as described above. CM _ INVOLICE can be computed as a hash of (PK _ SELLER, PK _ BUYER, INVOLICE _ DIGEST, TN, R), where PK _ SELLER and PK _ BUYER represent the public keys of the SELLER and BUYER, respectively, and INVOLICE _ DIGEST represents a hash of the digital ticket, or a hash of one or more portions of the digital ticket. The TN may represent a token generated by the seller that may be used to prevent the seller from using the digital ticket multiple times to obtain financing (i.e., prevent double financing). R may represent a vendor-generated random factor to further protect the information contained in PK _ SELLER, PK _ BUYER, and INVOIICE _ DIGEST.

At step 404, the vendor may submit an "ISSUE _ INVOLICE" transaction to the blockchain, the load of the transaction containing { CM _ INVOLICE, SELLER' S _ PROOF }. At step 406, the blockchain may verify SELLER 'S _ PROOF to determine if SELLER' S _ PROOF is acceptable. In some embodiments, the blockchain may verify SELLER' S _ PROOF using a smart contract using the common input and verification key, as described above. If SELLER' S _ PROOF fails to pass the verification, the intelligent contract may refuse to let the SELLER proceed. On the other hand, if SELLER 'S _ PROOF can pass verification, then the intelligent contract can determine that SELLER' S _ PROOF is acceptable and proceed to record CM _ INVOICE in the pool of tickets submitted by the SELLER. In some embodiments, the pool of tickets submitted by the seller may be structured as the Mercker tree T _ INVOLICE, and CM _ INVOLICE may be recorded on the leaf nodes of the Mercker tree T _ INVOLICE.

At step 408, the seller may proceed to require the buyer to validate the seller-generated digital ticket. In some embodiments, the seller may privately send the digital ticket and the value of TN and the value of R to the buyer through a down-link communication channel. The seller may also send CM _ INVOICE to the buyer. Alternatively or additionally, the buyer may reconstruct CM _ INVOIICE from the digital ticket and the values of TN and R received from the seller.

At step 410, the purchaser may examine the digital ticket to determine if the digital ticket is valid. The buyer may invalidate the digital ticket if, for example, the seller misreads the outstanding amount or a counterfeit ticket. The BUYER may also invalidate the digital ticket if the BUYER determines that CM _ INVOLICE is not recorded in the SELLER's submitted ticket pool or that the recorded CM _ INVOLICE does not match the commitment value of (PK _ SELLER, PK _ BUYER, INVOLICE _ DIGEST, TN, R). In this manner, if the seller attempts to bypass step 404 and 406, or attempts to change the digital ticket or change the value of TN or R, such attempts may be detected by the buyer, who may then invalidate the digital ticket and prevent fraud.

If the buyer determines that the digital ticket is valid, the buyer may proceed to generate a commitment value validated by the buyer for recording on the blockchain. In some embodiments, the buyer may calculate the buyer-validated commitment value, CM _ BV _ INVOICE, as:

COMMITMENT(PK_SELLER，PK_BUYER，INVOICE_DIGEST，TN’，R’)。

in some embodiments, CM _ BV _ INVOMICE may be calculated based on the same functions used by the vendor to calculate CM _ INVOMICE. It is noted that although the values of PK _ SELLER, PK _ BUYER and INVOLICE _ DIGEST may be the same, the BUYER may need to generate a new TN 'and a new R'. In this manner, the buyer may calculate a commitment value that is different from the commitment value calculated by the seller, effectively preventing unrelated users from connecting the two commitment values together, and thus preventing unrelated users from connecting the seller and buyer together.

The BUYER may also generate a zero knowledge PROOF, denoted BUYER' S _ PROOF, at step 410. The BUYER can generate BUYER' S _ PROOF to prove to the blockchain that the BUYER is the true recipient of the ticket. The buyer may attempt to prove this by indicating: (1) CM _ INVOLOIC is in the correct format, (2) CM _ INVOLOIC is recorded in the ticket pool submitted by the seller, (3) CM _ BV _ INVOLOIC is in the correct format, and (4) the buyer is indeed the buyer itself.

In an embodiment, to prove that the CM _ INVOLICE format is correct, the BUYER can prove to the blockchain that the BUYER knows that the values of PK _ SELLER, PK _ BUYER, INVOLICE _ DIGEST, TN, and R and that the commitment value of (PK _ SELLER, PK _ BUYER, INVOLICE _ DIGEST, TN, R) is CM _ INVOLICE. In an embodiment, to prove that CM _ INVOMICE is recorded in the seller's submitted instrument pool, the buyer can prove to the blockchain that CM _ INVOMICE is a valid leaf node in the Mercker tree T _ INVOMICE. In an embodiment, to prove that CM _ BV _ INVOLICE is in the correct format, the BUYER can prove to the blockchain that the commitment value of (PK _ SELLER, PK _ BUYER, INVOLICE _ DIGEST, TN ', R') is CM _ BV _ INVOLICE. In an embodiment, to prove that the BUYER is indeed the BUYER itself, the BUYER may prove to the blockchain that the BUYER owns the BUYER's private key, or that PK _ vapor ═ h (SK _ vapor), where SK _ vapor represents the private key, which is known only to the BUYER.

In some embodiments, the buyer and blockchain may agree to implement the zero-knowledge proof technique described above. For example, the buyer may prove to the blockchain that the buyer knows the private input w, such that a particular relationship holds between x, and w for the public input x. In some embodiments, the relationship may be defined as an arithmetic circuit, which may be defined based on a polynomial equation that may be evaluated based on x and w. In some embodiments, the attestation key and the verification key may be generated during a setup phase based on the arithmetic circuitry and one or more security parameters established for zero-knowledge attestation. In some embodiments, the BUYER may set x to a value containing TN and CM _ CERT _ INCOME, and w to a value generated based on PK _ SELLER, PK _ BUYER, INCOME _ DIGEST, R, TN ', R', and SK _ SELLER. In this manner, the BUYER can generate BUYER' S _ PROOF to prove to the blockchain that the BUYER owns the private input w. In some embodiments, the blockchain may accept the buyer's claim as true if the blockchain is certified by the buyer that the buyer has private input w.

At step 412, the buyer may send the value of TN 'and the value of R' to the seller, so that the seller may then use these values to request authentication from an authority. At step 414, the BUYER may submit a transaction to the blockchain, the load of the transaction containing { TN, CM _ BV _ INVOIC, BUYER' S _ PROOF }. For purposes of illustration, this transaction may be referred to as a "BUYER _ VALIDATED _ INVOLICE" transaction.

At step 416, the blockchain may use the smart contract to check whether the TN contained within the load has been used or consumed. In some embodiments, the smart contract may maintain a list of tokens used on the blockchain to record the tokens used. If the TN contained in the payload is listed in the used token list, the smart contract may refuse to proceed because the seller is trying to obtain financing multiple times using the same digital ticket. On the other hand, if the TN contained in the load is not listed in the used token list, the smart contract may proceed to verify that BUYER' S _ PROOF is acceptable. The smart contract may use the public input and the authentication key to authenticate BUYER' S _ PROOF. If BUYER 'S _ PROOF can be verified, the intelligent contract may determine that BUYER' S _ PROOF is acceptable and continue to record CM _ BV _ INVOME in the authoritatively authenticated ticket pool. In some embodiments, the buyer-validated ticket pool may be structured as the Mercker tree T _ BV _ INVOICE and CM _ BV _ INVOICE may be recorded on leaf nodes of the Mercker tree T _ BV _ INVOICE. The smart contract may also add a TN to the used token list to indicate that the TN has been used, thus invalidating the TN for future use.

At step 418, the seller may proceed to require an authority to validate the seller-generated digital ticket. In some embodiments, the seller may privately send the digital ticket, as well as the value of TN 'and the value of R' to the authority through a down-link communication channel. The vendor may also send CM _ BV _ INVOICE to the authority. Alternatively or additionally, the authority may reconstruct CM _ BV _ INVOMICE from the digital ticket and the values of TN 'and R' received from the seller.

At step 420, the authority may check the digital ticket to determine if the digital ticket is valid. In some embodiments, the authority may invalidate the digital ticket if the authority determines that CM _ BV _ INVOME is not recorded in the ticket pool validated by the BUYER, or that the recorded CM _ BV _ INVOME does not match the commitment value of (PK _ SELLER, PK _ BUYER, INVOME _ DIGEST, TN ', R'). In this manner, if the seller attempts to bypass any previous steps, or attempts to change the digital ticket or change the value of TN 'or R', such an attempt may be detected by the authority, who may then invalidate the digital ticket and prevent fraud. On the other hand, if the authority determines that the digital ticket is valid, the authority may proceed to generate the certified commitment value to record on the blockchain. In some embodiments, the authority may calculate the certified commitment value, CM _ CERT _ INVOICE, as:

COMMITMENT(PK_SELLER，PK_BUYER，INVOICE_DIGEST，CERT_DIGEST，TN”，R”)。

in some embodiments, CM _ CERT _ INVOLICE may be calculated based on the same function used by the vendor to calculate CM _ INVOLICE, where the values of PK _ SELLER, PK _ BUYER, and INVOLICE _ DIGEST are the same. CERT DIGEST may represent a hash value of one or more authentication files generated by an authority. The authentication document may take a variety of formats including, for example, a standardized format established by a governmental agency or customs officer for providing authentication. The authority may also generate a new TN "and a new R". In this manner, the authority may calculate a commitment value that is different from the commitment values calculated by the seller and the buyer, effectively preventing unrelated users from joining the three commitment values together, and thus preventing unrelated users from joining the seller, the buyer, and the authority together.

In step 420, the AUTHORITY may also generate a zero knowledge PROOF, denoted as AUTHORITY' S _ PROOF. The AUTHORITY may generate an AUTHORITY' S _ PROOF to prove to the blockchain that the AUTHORITY has reviewed and authenticated the ticket provided by the vendor. The authority may attempt to prove this by noting: (1) CM _ BV _ INVOLICE format is correct, (2) CM _ BV _ INVOLICE is recorded in the buyer's submitted ticket pool, and (3) CM _ CERT _ INVOLICE format is correct.

In an embodiment, to prove that CM _ BV _ INVOLICE format is correct, the authority may prove to the blockchain that the authority knows the values of PK _ SELLER, PK _ BUYER, INVOLICE _ DIGEST, TN ', and R' and that the commitment value of (PK _ SELLER, PK _ BUYER, INVOLICE _ DIGEST, TN ', R') is CM _ BV _ INVOLICE. In an embodiment, to prove that CM _ BV _ INVOICE is recorded in the buyer's submitted ticket pool, the authority may prove to the blockchain that CM _ BV _ INVOICE is a valid leaf node in the Mercker tree T _ BV _ INVOICE. In an embodiment, to prove that the CM _ CERT _ INVOEICE format is correct, an authority may prove to the blockchain that (PK _ SELLER, PK _ BUYER, INVOECE _ DIGEST, CERT _ DIGEST, TN ", R") the commitment value is CM _ CERT _ INVOECE.

In some embodiments, the authority and blockchain may agree to implement the zero-knowledge proof technique described above. For example, the authority may prove to the blockchain that the authority knows the private input w, such that a particular relationship holds between x, and w for the public input. In some embodiments, the relationship may be defined as an arithmetic circuit, which may be defined based on a polynomial equation that may be evaluated based on x and w. In some embodiments, the attestation key and the verification key may be generated during a setup phase based on the arithmetic circuitry and one or more security parameters established for zero-knowledge attestation. In some embodiments, the authority may set x to a value containing TN and CM _ CERT _ INVOLICE, and w to a value generated based on PK _ SELLER, PK _ BUYER, INVOLICE _ DIGEST, CERT _ DIGEST, R', TN ", R", and CM _ BV _ INVOLICE. In this way, the AUTHORITY may generate an AUTHORITY' S _ PROOF to prove to the blockchain that the AUTHORITY possesses the private input w. In some embodiments, if the blockchain is authorized to certify that the authority has private input w, the blockchain may accept the assertion of authority as true.

At step 422, the authority may send the authentication file and the values of TN "and R" to the seller so that the seller may then use the authentication file to obtain financing from the bank. At step 424, the AUTHORITY may submit an "AUTHORITY _ CERTIFIED _ INVOICE" transaction to the blockchain, the payload of the transaction containing { TN ', CM _ CERT _ INVOICE, AUTHORITY' S _ PROOF }.

At step 426, the blockchain may utilize the intelligent contract to verify the identity of the authority (e.g., based on the signature provided by the authority) and check whether the TN' contained in the load has been used or consumed. In some embodiments, a smart contract may maintain a list of tokens used on a blockchain to record the tokens used. If the TN' contained in the payload is listed in the used token list, the smart contract may refuse to proceed because the seller is trying to obtain financing multiple times using the same digital ticket. On the other hand, if the TN 'contained in the load is not listed in the used-token list, the intelligent contract may continue to verify whether the AUTHORITY' S _ PROOF is acceptable. The smart contract may use the public input and the authentication key to authenticate the authorshoof. If the AUTHORITY 'S _ PROOF can be validated, the intelligent contract may determine that AUTHORITY' S _ PROOF is acceptable and continue recording CM _ CERT _ INVOME in the authoritatively authenticated ticket pool. In some embodiments, the authoritative authenticated ticket pool may be structured as a Merck tree T _ CERT _ INVOICE and CM _ CERT _ INVOIICE may be recorded on the leaf nodes of the Merck tree T _ CERT _ INVOIICE. The smart contract may also add TN ' to the used token list to indicate that the TN ' has been used to invalidate the TN ' for future use.

At step 428, the seller may proceed to request financing of the instrument from the bank. In some embodiments, the seller may privately send the digital ticket, the authentication file, and the values of TN "and R" to the bank through a down-link communication channel. The vendor may also calculate the value of CM _ CERT _ INVOMICE and send the value of CM _ CERT _ INVOMICE to the bank. Alternatively or additionally, the bank may reconstruct CM _ CERT _ INVOICE from the digital ticket, the authentication file, and the values of TN "and R" received from the seller.

At step 430, the bank may determine whether the digital ticket and authentication document are valid. For example, if the digital ticket is not authoritatively authenticated, the bank may invalidate the digital ticket. The bank may make this determination by determining whether CM _ CERT _ INVOMICE is recorded in an authoritatively authenticated ticket pool (e.g., in the Mercker tree T _ CERT _ INVOMICE). If CM _ CERT _ INVOMICE is not recorded in the authoritatively authenticated ticket pool, the bank can confirm that the digital ticket is invalid and refuse the seller to proceed. On the other hand, if CM _ CERT _ INVOICE is recorded in an authoritatively authenticated ticket pool, the bank may determine that the digital ticket is valid. The bank may then proceed to decide whether to provide the seller with the instrument financing.

In some embodiments, the bank may also determine whether the TN "provided by the seller has been used. In some embodiments, the bank may invoke a smart contract executing on the blockchain to confirm whether the TN "is listed in the used token list. If TN "is listed in the used token list, the bank may refuse to proceed because the seller is trying to obtain financing multiple times using the same digital ticket. If TN "is not listed in the used token list, the bank may proceed to decide whether to provide the seller with the instrument financing.

If the bank decides to deny the seller's request for financing of the instrument, the bank may communicate the decision privately to the seller through a linked communication channel, in which case the seller may choose to repeat step 428 and request financing of the instrument from a different funding provider. On the other hand, if the BANK decides to provide the seller with the instrument financing, the BANK may proceed to generate a zero knowledge PROOF, denoted BANK 'S _ PROOF, at step 430 to prove to the blockchain that the BANK has verified the validity of the seller' S requirements to provide the instrument financing. The bank may attempt to prove this by noting: (1) CM _ CERT _ INVOLICE is in the correct format, (2) CM _ CERT _ INVOLICE is recorded in a ticket pool for authoritative certification.

In an embodiment, to prove that the CM _ CERT _ INVOEICE format is correct, the bank may prove to the blockchain that the bank knows that the values of PK _ SELLER, PK _ BUYER, INVOECE _ DIGEST, CERT _ DIGEST, TN ", and R" and that the commitment value of (PK _ SELLER, PK _ BUYER, INVOECE _ DIGEST, CERT _ DIGEST, TN ", R") is CM _ CERT _ INVOECE. In an embodiment, to prove that CM _ CERT _ INVOICE is recorded in an authoritatively authenticated ticket pool, a bank may prove to the blockchain that CM _ CERT _ INVOICE is a valid leaf node in the Mercker tree T _ CERT _ INVOICE.

In some embodiments, the bank and blockchain may agree to implement the zero-knowledge proof technique described above. For example, a bank may prove to the blockchain that the bank knows the private input w, such that a particular relationship holds between x, and w for the public input. In some embodiments, the relationship may be defined as an arithmetic circuit, which may be defined based on a polynomial equation that may be evaluated based on x and w. In some embodiments, the attestation key and the verification key may be generated during a setup phase based on the arithmetic circuitry and one or more security parameters established for zero-knowledge attestation. In some embodiments, the bank may set x to TN "and w to a value generated based on PK _ SELLER, PK _ BUYER, INVOEICE _ DIGEST, CERT _ DIGEST, R", and CM _ CERT _ INVOEICE. In this way, the BANK can generate BANK' S _ PROOF to prove to the blockchain that the BANK owns the private input w.

At step 432, the BANK may submit an "ISSUE _ FINANCING" transaction to the blockchain, the transaction ' S payload containing { TN ', BANK ' S _ PROOF }. At step 434, the blockchain may use the smart contract to check whether the TN "contained within the load is already in use. In some embodiments, the smart contract may check whether TN "is listed in the used token list. If TN "is listed in the used token list, the smart contract may refuse to proceed because the seller is trying to obtain financing multiple times using the same digital ticket. If TN "is not listed in the used token list, the smart contract may continue to verify that BANK' S _ PROOF is acceptable. The smart contract may use the public input and the authentication key to authenticate BANK' S _ pro. If BANK 'S _ PROOF can be verified, the smart contract may determine that BANK' S _ PROOF is acceptable and invalidate TN "(e.g., by adding TN to the list of used tokens) and report to the BANK that fraud was not detected based on the received transaction at step 436 so that the BANK may continue to issue ticket financing to the seller.

Fig. 5 illustrates a flow diagram of a method 500 for mitigating ticket financing fraud, according to an embodiment. The method 500 may be performed by one or more nodes in a blockchain system, such as nodes 102-110 in the blockchain system 100 (fig. 1). Nodes 102-110 in the blockchain system 100 may perform operations on blockchains, such as blockchain 120 (fig. 1). Blockchain 120 may be implemented as a blockchain in the above example.

At step 502, a node, such as node 102, may receive a first transaction submitted by a first user. The first user may be, for example, a seller (fig. 3) who is the issuer of the ticket and is attempting to use the ticket to obtain financing. The first transaction may include the "ISSUE _ INVOLICE" transaction described above (FIG. 3), which may include a first commitment value for a ticket, such as CM _ INVOLICE, and a first attestation, such as SELLER' S _ PROOF.

At step 504, node 102 may determine whether the first proof is acceptable and report detection of fraud in response to determining that the first proof is unacceptable. In some embodiments, the first proof may be a zero knowledge proof generated by the first user to prove that the first user is the actual issuer of the ticket. In some embodiments, the first user may attempt to prove to the node 102 that the first commitment value for the ticket is in the correct format and that the first user is indeed the first user itself. In some embodiments, if node 102 determines that the first proof is unacceptable, node 102 may report that suspected fraud was detected. On the other hand, if the node 102 determines that the first proof is acceptable, the node 102 may record the first commitment value in a first ticket pool, which is referred to in FIG. 3 as a ticket pool submitted by the seller.

At step 506, the node 102 may receive a second transaction submitted by a second user. The second user may be, for example, an authority (fig. 3) that is trusted by the blockchain system 100 to authenticate tickets issued by the first user. The second transaction may include the "AUTHORITY _ CERTIFIED _ INVOLICE" transaction described above (FIG. 3), which may include a first token generated by the first user, e.g., TN, a second commitment value for the instrument, e.g., CM _ CERT _ INVOLICE, and a second attestation, e.g., AUTHORITY' S _ PROOF.

At step 508, node 102 may determine whether the first token is valid and the second proof is acceptable. In response to determining that the first token is invalid or that the second token is unacceptable, the node 102 may report that fraud is detected. In some embodiments, node 102 may determine whether the first token is valid by determining whether the first token is listed in a list of used tokens. In some embodiments, the second proof may be a zero knowledge proof generated by the second user to prove that the second user is the recipient of the ticket. In some embodiments, if node 102 determines that the first token is invalid or that the second proof is unacceptable, node 102 may report that suspected fraud was detected. On the other hand, if the node 102 determines that the first token is valid and the second proof is acceptable, the node 102 may record the second commitment value in a second ticket pool, which is referred to in FIG. 3 as an authoritatively authenticated ticket pool. The node 102 may also invalidate the first token. In some embodiments, the node 102 may invalidate the first token by adding the first token to a list of used tokens.

At step 510, the node 102 may receive a third transaction submitted by a third user. The third user may be, for example, a bank (fig. 3), which is a funds provider that has received a request to provide a ticket financing to the first user. The third transaction may include the aforementioned "ISSUE FINANCING" transaction (fig. 3), which may include a second token, e.g., TN ', generated by the second user and a third credential, e.g., BANK' S _ PROOF, generated by a third user.

At step 512, node 102 may determine whether the second token is valid and the third proof is acceptable. In response to determining that the second token is invalid or that the third proof is unacceptable, node 102 may report that fraud is detected. In some embodiments, node 102 may determine whether the second token is valid by determining whether the second token is listed in the used token list. In some embodiments, the third proof may be a zero knowledge proof generated by the third user to prove that the third user has verified the validity of the request to provide the first user with the ticket financing. In some embodiments, if node 102 determines that the second token is invalid or that the third proof is unacceptable, node 102 may report that suspected fraud is detected. On the other hand, if the node 102 determines that the second token is valid and the third proof is acceptable, the node 102 may invalidate the second token and report to the third user that fraud was not detected based on the received transaction. In some embodiments, the node 102 may invalidate the second token by adding the second token to the list of used tokens. The third user may continue to issue ticket financing to the first user.

Fig. 6 shows a flow diagram of a method 600 for mitigating ticket financing fraud, according to an embodiment. The method 600 may be performed by one or more nodes in a blockchain system, such as node 102-110 in the blockchain system 100 (fig. 1). Nodes 102-110 in the blockchain system 100 may perform operations on blockchains, such as blockchain 120 (fig. 1). Blockchain 120 may be implemented as a blockchain in the above example.

At step 602, a node, such as node 102, may receive a first transaction submitted by a first user. The first user may be, for example, a seller (fig. 4) who is the issuer of the ticket and is attempting to use the ticket to obtain financing. The first transaction may include the "ISSUE _ INVOLICE" transaction described above (FIG. 4), which may include a first commitment value for a ticket, such as CM _ INVOLICE, and a first attestation, such as SELLER' S _ PROOF.

At step 604, node 102 may determine whether the first proof is acceptable and report detection of fraud in response to the first proof being unacceptable. On the other hand, if the node 102 determines that the first proof is acceptable, the node 102 may record the first commitment value in a first ticket pool, which is referred to in FIG. 4 as a ticket pool submitted by the seller.

At step 606, the node 102 may receive a second transaction submitted by a second user. The second user may be, for example, a buyer (fig. 4) that is a recipient of the ticket. The second transaction may include the "BUYER _ VALIDATED _ INVOLICE" transaction described above (FIG. 4), which may include a first token generated by the first user, e.g., TN, a second commitment value for the instrument, e.g., CM _ BV _ INVOLICE, and a second PROOF, e.g., BUYER' S _ PROOF.

At step 608, node 102 may determine whether the first token is valid and the second proof is acceptable. In response to determining that the first token is invalid or that the second token is unacceptable, the node 102 may report that fraud is detected. On the other hand, if the node 102 determines that the first token is valid and the second proof is acceptable, the node 102 may record the second commitment value in a second ticket pool, which is referred to in FIG. 4 as a buyer-validated ticket pool. The node 102 may also invalidate the first token. In some embodiments, the node 102 may invalidate the first token by adding the first token to a list of used tokens.

At step 610, the node 102 may receive a third transaction submitted by a third user. The third user may be, for example, an authority (fig. 4) that is trusted by the blockchain system 100 to authenticate tickets issued by the first user. The third transaction may include the "AUTHORITY _ CERTIFIED _ INVOICE" transaction described above (fig. 4), which may include a second token generated by the second user, e.g., TN ', a third commitment value for the instrument, e.g., CM _ CERT _ INVOICE, and a third PROOF, e.g., AUTHORITY' S _ PROOF.

At step 612, node 102 may determine whether the second token is valid and the third proof is acceptable. In response to determining that the second token is invalid or that the third proof is unacceptable, node 102 may report that fraud is detected. On the other hand, if the node 102 determines that the second token is valid and the third proof is acceptable, the node 102 may record a third commitment value in a third ticket pool, which is referred to in FIG. 4 as an authoritatively authenticated ticket pool. Node 102 may also invalidate the second token. In some embodiments, the node 102 may invalidate the second token by adding the second token to the list of used tokens.

At step 614, node 102 may receive a fourth transaction submitted by a fourth user. The fourth user may be, for example, a bank (fig. 4), which is a funds provider that has received a request to provide a ticket financing to the first user. The fourth transaction may include the aforementioned "ISSUE FINANCING" transaction (fig. 4), which may include a third token, e.g., TN, generated by a third user and a fourth PROOF, e.g., BANK' S _ PROOF, generated by a fourth user.

At step 616, node 102 may determine whether the third token is valid and the fourth proof is acceptable. In response to determining that the third token is invalid or that the fourth token is unacceptable, node 102 may report that fraud is detected. On the other hand, if the node 102 determines that the third token is valid and the fourth proof is acceptable, the node 102 may invalidate the third token and report to the fourth user that fraud was not detected based on the received transaction. In some embodiments, node 102 may invalidate the third token by adding the third token to the list of used tokens. The fourth user may continue to issue ticket financing to the first user.

Fig. 7 is a block diagram of a ticket financing fraud mitigation apparatus 700 according to an embodiment. Apparatus 700 may be implemented by a software process and may correspond to method 500 (fig. 5) and method 600 (fig. 6). Referring to fig. 7, apparatus 700 may include a receiving module 702, a determining module 704, a recording module 706, and a reporting module 708.

The receiving module 702 may receive a transaction submitted by a user. The transactions may include the "ISSUE _ INVOLICE" transaction, "AUTHORITY _ CERTIFIED _ INVOLICE" transaction, "BUYER _ VALIDATED _ INVOLICE" transaction, and "ISSUE _ FINANCING" transaction described above. Receiving module 702 may provide the received transaction to determining module 704.

The determination module 704 may process the transactions received as described above. If suspected fraud is detected, the determination module 704 may request the reporting module 708 to report the detected fraud. Otherwise, the determination module 704 may provide the commitment values contained in the received transaction to the recording module 706, and the recording module 706 may record the commitment values in a corresponding instrument pool as described above. In some embodiments, if the received transaction is an "ISSUE _ FINANCING" transaction and the determination module 704 does not detect fraud, the determination module 704 may request the reporting module 708 to report that fraud is not detected so that the instrument financing request submitted by the first user may be processed.

Each of the above modules may be implemented as software, or hardware, or a combination of software and hardware. For example, each of the above modules may be implemented using a processor, and the memory executes instructions stored in the memory. Also, for example, each of the above-described modules may be implemented using one or more Application Specific Integrated Circuits (ASICs), Digital Signal Processors (DSPs), Digital Signal Processing Devices (DSPDs), Programmable Logic Devices (PLDs), Field Programmable Gate Arrays (FPGAs), controllers, micro-controllers, microprocessors, or other electronic components to perform the described methods. Further, each of the above modules may be implemented by using a computer chip or an entity, or by using a product having a specific function, for example. In embodiments, the apparatus 700 may be a computer, and the computer may be a personal computer, a laptop computer, a cellular telephone, a camera phone, a smartphone, a personal digital assistant, a media player, a navigation device, an email messaging device, a gaming console, a tablet, a wearable device, or any combination of these devices.

For the implementation of the functions and roles of each module in the apparatus 700, reference may be made to the corresponding steps in the above-described method. Details are omitted here for the sake of brevity.

In some embodiments, a computer program product may include a non-transitory computer readable storage medium having computer readable program instructions stored thereon for causing a processor to perform the above-described method.

The computer readable storage medium may be a tangible device that may store instructions for use by an instruction execution device. The computer readable storage medium may be, for example, but not limited to, an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination of the foregoing. A non-exhaustive list of more specific examples of the computer-readable storage medium includes the following: a portable computer diskette, a hard disk, a Random Access Memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM), a Static Random Access Memory (SRAM), a portable compact disc read-only memory (CD-ROM), a Digital Versatile Disc (DVD), a memory stick, a floppy disk, a mechanical coding device (e.g., a punch card or a raised structure in a groove with instructions recorded thereon), and any suitable combination of the foregoing.

The computer-readable program instructions for performing the methods described above may be assembly instructions, Instruction Set Architecture (ISA) instructions, machine-related instructions, microcode, firmware instructions, state setting data, or source or object code written in any combination of one or more programming languages, including an object oriented programming language and a conventional procedural programming language. The computer-readable program instructions may execute entirely on the computing device as a stand-alone software package, or may execute partially on a first computing device and partially on a second computing device remote from the first computing device. In the latter case, the second remote computing device may be connected to the first computing device over any type of network, including a Local Area Network (LAN) or a Wide Area Network (WAN).

The computer-readable program instructions may be provided to a processor of a general purpose or special purpose computer or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the methods described above.

The flowchart and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of apparatus, methods and computer program products according to various embodiments herein. In this regard, the blocks in the flowchart or block diagrams may represent software programs, segments, or portions of code, which comprise one or more executable instructions for implementing the specified functions. It should also be noted that, in some alternative implementations, the functions noted in the block may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the diagrams and/or flowchart illustration, and combinations of blocks in the diagrams and flowchart illustration, can be implemented by special purpose hardware-based systems which perform the specified functions or acts, or combinations of special purpose hardware and computer instructions.

It is appreciated that certain features of the disclosure, which are, for clarity, described in the context of separate embodiments, may also be provided in combination in a single embodiment. Conversely, various features of the disclosure that are, for brevity, described in the context of a single embodiment, may also be provided separately or in any suitable subcombination, or as suitable in any other described embodiment of the disclosure. Unless otherwise specified, certain features described in the context of various embodiments are not essential features of those embodiments.

While the present disclosure has been described in conjunction with specific embodiments, it is evident that many alternatives, modifications, and variations will be apparent to those skilled in the art. Accordingly, the following claims are intended to embrace all such alternatives, modifications and variances which fall within the scope of the claims.

Claims (16)

1. A computer-implemented method for mitigating ticket financing fraud, the method comprising:

receiving a first transaction from a first user, the first transaction including a first commitment value for a ticket and a first proof to prove that the first user is an issuer of the ticket, the first commitment value generated based on a corresponding first token for the first user;

verifying the first proof;

receiving a second transaction from a second user, the second transaction including the first token corresponding to the first user, a second commitment value for the ticket, and a second proof for proving that the second user has authenticated the ticket, the second commitment value being generated based on a second token corresponding to the second user and an authentication file generated by the second user;

determining that the first token is valid and verifying the second proof;

receiving a third transaction from a third user, the third transaction including the second token corresponding to the second user and a third proof generated by the third user;

determining that the second token is valid and verifying the third proof to determine that there is no ticket financing fraud.

2. The method of claim 1, wherein the method is performed by one or more nodes in a blockchain system.

3. The method of claim 2, wherein the second user has a trusted identity registered on the blockchain system, the method further comprising:

verifying the trusted identity of the second user based on a signature of the second transaction by the second user.

4. The method of any preceding claim, further comprising one of:

reporting detection of fraud in response to determining that the first proof is not acceptable;

reporting detection of the fraud in response to determining that the first token is invalid or that the second proof is not acceptable; or

Reporting detection of the fraud in response to determining that the second token is invalid or that the third proof is unacceptable.

5. The method of any preceding claim, further comprising:

recording the first commitment value for the ticket in a first ticket pool in response to determining that the first proof is acceptable;

in response to determining that the first token is valid and that the second proof is acceptable, recording the second commitment value for the ticket in a second ticket pool and invalidating the first token.

6. The method of any preceding claim, further comprising:

responsive to determining that the second token is valid and that the third proof is acceptable, invalidating the second token and reporting that fraud is not detected.

7. The method of any preceding claim, wherein the first proof, the second proof, and the third proof are zero knowledge proofs.

8. The method of any preceding claim, wherein the first user is an issuer of the ticket and the first proof is a proof generated by the first user to prove that the first user is the issuer of the ticket.

9. A method as claimed in any preceding claim, wherein the second user is a trusted user and the second proof is a proof generated by the second user to prove that the second user has authenticated the ticket.

10. The method of any preceding claim, wherein the third user is a fund provider who has received a request to provide a ticket financing to the first user, and the third proof is a proof generated by the third user to prove that the third user has verified the validity of the request to provide a ticket financing to the first user.

11. The method of any preceding claim, wherein the first commitment value is generated by the first user with a first random value and the second commitment value is generated by the second user with a second random value, such that the first commitment value and the second commitment value are disassociated.

12. A computer-implemented method for mitigating ticket financing fraud, the method comprising:

receiving a first transaction from a first user, the first transaction including a first commitment value for a ticket and a first proof to prove that the first user is an issuer of the ticket, the first commitment value generated based on a corresponding first token for the first user;

verifying the first proof;

receiving a second transaction from a second user, the second transaction including the first token corresponding to the first user, a second commitment value for the ticket, and a second proof for proving that the second user is a recipient of the ticket, the second commitment value being generated based on a second token corresponding to the second user;

determining that the first token is valid and verifying the second proof;

receiving a third transaction from a third user, the third transaction including the second token corresponding to the second user, a third commitment value for the ticket, and a third proof for proving that the third user has reviewed and authenticated the ticket, the third commitment value being generated based on a third token corresponding to the third user and an authentication file generated by the third user;

determining that the second token is valid and verifying the third proof;

receiving a fourth transaction from a fourth user, the fourth transaction including the third token corresponding to the third user and a fourth proof generated by the fourth user;

determining that the third token is valid and verifying the fourth proof to determine that there is no ticket financing fraud.

13. The method of claim 12, wherein the method is performed by one or more nodes in a blockchain system, the third user having a trusted identity registered on the blockchain system, the method further comprising:

verifying the trusted identity of the third user based on the third user's signature of the third transaction.

14. An apparatus for mitigating bill financing fraud, comprising:

one or more processors;

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

15. An apparatus for mitigating bill financing fraud, the apparatus comprising a plurality of modules for performing the method of any of claims 1 to 13.

16. A non-transitory computer readable medium having stored therein instructions that, when executed by a processor of a device, cause the device to perform the method of any one of claims 1-13.

Images