Method and apparatus for mitigating bill financing fraud

Abstract

Disclosed herein are a method, device, and apparatus for mitigating bill financing fraud, including a computer program stored on a computer-readable medium. The method comprises: receiving a first transaction from a first user, the first transaction comprising a first commitment value for a bill and a first certificate, the first commitment value being generated based on a first token corresponding to the first user; verifying the first certificate; receiving a second transaction from a second user, the second transaction comprising the first token, a second commitment value for the bill, and a second certificate, 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 certificate; receiving a third transaction from a third user, the third transaction comprising the second token and a third certificate; determining that the second token is valid and verifying the third certificate.

Description

Technical Field

[0001] This specification relates generally to computer technology and, more particularly, to methods and apparatus for mitigating bill financing fraud. Background Art

[0002] Bill financing is a way for businesses to borrow against their accounts receivable, including, for example, accounts receivable from customers. Bill financing helps businesses improve cash flow, pay employees and suppliers, and reinvest in operations and growth sooner than if they had to wait until customers paid their balances in full.

[0003] One of the risks associated with bill financing is fraud. For example, some businesses may commit fraud by unilaterally creating counterfeit bills and attempting to borrow money using them. Others may commit fraud by borrowing the same bill multiple times from multiple funding providers or investors. This type of fraudulent activity is difficult to detect and mitigate. Summary of the Invention

[0004] In one aspect, a computer-implemented method for mitigating bill financing fraud includes: receiving a first transaction from a first user, the first transaction including a first commitment value of a bill and a first proof for proving that the first user is the issuer of the bill, the first commitment value being generated based on a first token corresponding to the first user; verifying the first proof; receiving a second transaction from a second user, the second transaction including a first token corresponding to the first user, a second commitment value of the bill, and a second proof for proving that the second user is the recipient of the bill, 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 a 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 bill financing fraud.

[0005] On the other hand, a device for mitigating bill financing fraud includes: one or more processors; one or more computer-readable memories coupled to the one or more processors and having instructions stored thereon, the instructions being executable by the one or more processors to: receive a first transaction from a first user, the first transaction including a first commitment value of a bill and a first proof for proving that the first user is the issuer of the bill, the first commitment value being generated based on a first token corresponding to the first user; verify the first proof; receive a second transaction from a second user, the second transaction including a first token corresponding to the first user, a second commitment value of the bill, and a second proof for proving that the second user is the recipient of the bill, the second commitment value being generated based on a second token corresponding to the second user; determine that the first token is valid and verify the second proof; receive 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; determine that the second token is valid and verify the third proof to determine that there is no bill financing fraud.

[0006] In another aspect, a non-transitory computer-readable medium stores instructions that, when executed by a processor of a device, cause the device to perform a method for mitigating bill financing fraud. The method includes: receiving a first transaction from a first user, the first transaction including a first commitment value for a bill and a first certificate proving that the first user is the issuer of the bill, the first commitment value being generated based on a first token corresponding to the first user; verifying the first certificate; receiving a second transaction from a second user, the second transaction including a first token corresponding to the first user, a second commitment value for the bill, and a second certificate proving that the second user is the recipient of the bill, 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 certificate; receiving a third transaction from a third user, the third transaction including a second token corresponding to the second user and a third certificate generated by the third user; determining that the second token is valid and verifying the third certificate to determine that there is no bill financing fraud. BRIEF DESCRIPTION OF THE DRAWINGS

[0007] The accompanying drawings, which are incorporated in and constitute a part of this document, illustrate embodiments. In the following description of the designated figures, like numerals in different figures represent the same or similar elements unless otherwise indicated.

[0008] Figure 1 is a schematic diagram of a blockchain system according to an embodiment.

[0009] Figure 2 is a schematic diagram of a computing device for implementing a node in a blockchain system according to an embodiment.

[0010] Figure 3 is a flow chart of a method for mitigating bill financing fraud according to an embodiment.

[0011] Figure 4 is a flow chart of a method for mitigating bill financing fraud according to an embodiment.

[0012] Figure 5 is a block diagram of an apparatus for mitigating bill financing fraud according to an embodiment. DETAILED DESCRIPTION

[0013] Embodiments of this specification provide methods and devices for mitigating bill financing fraud. These methods and devices can utilize a blockchain system to verify bills submitted by users. Counterfeit bills can be detected, and fraudulent attempts to borrow money using such counterfeit bills can be prevented. These methods and devices can also implement a protocol for determining whether a bill has already been used for bill financing. If a bill is determined to have been used for bill financing, the method and device can prevent further financing attempts using the same bill. These methods and devices can further implement a protocol for protecting user privacy. In this way, the method and device can use a blockchain system to verify bills without revealing the specific contents of the bill to the public.

[0014] Embodiments disclosed herein have one or more technical advantages. In some embodiments, the methods and devices require users to submit proof in order to verify the bills they submit. This allows the methods and devices to detect counterfeit bills and prevent fraudulent attempts to borrow money using counterfeit bills. In some embodiments, the methods and devices support the use of a blockchain system to verify bills. This allows the methods and devices to store bills in a data structure that is resistant to tampering and manipulation by malicious parties. In some embodiments, these methods and devices also support a protocol that uses a blockchain system to calculate a commitment value for the bill to be verified. The calculated commitment value for the bill can be associated with a token and a random value. The token can be used to invalidate the commitment value if it is leaked by the user. This prevents double financing using the same bill. The random value can be used to introduce additional randomness to further protect user privacy. This allows the methods and devices to verify bills using a blockchain system without disclosing any private information to the public.

[0015] Blockchain systems, also known as distributed ledger systems (DLSs) or consensus systems, enable participating parties to store data securely and immutably. Without reference to any specific use case, blockchain systems can include any DLS and can be used in public, private, and consortium blockchain networks. Public blockchain networks are open to all entities to use the system and participate in the consensus process. Private blockchain networks are designed for specific entities, with read and write permissions centrally controlled. Consortium blockchain networks are designed for a select group of entities, who control the consensus process and include an access control layer.

[0016] Blockchain systems are implemented using peer-to-peer (P2P) networks, where nodes communicate directly with each other, i.e., without the need for a fixed central server. Each node in a P2P network can initiate communication with another node in the P2P network. Blockchain systems maintain one or more blockchains.

[0017] A blockchain is a data structure that stores data, such as transactions, in a way that prevents malicious parties from tampering with and manipulating the data. Transactions stored in this manner are immutable and can be subsequently verified. A blockchain consists of one or more blocks. Each block is connected to the previous block by including a cryptographic hash of the block immediately preceding it. Each block may also include a timestamp, its own cryptographic hash, and one or more transactions. Transactions that have typically been verified by nodes in a blockchain system can be hashed and encoded into a data structure such as a Merkle tree. In a Merkle tree, the data at the leaf nodes of the tree is hashed, and all hashes in each branch of the tree are connected at the root of that branch. This process continues along the tree until it reaches the root of the entire tree, where hashes representing all the data in the tree are stored. Hash values ​​purported to represent transactions stored in the tree can be quickly verified by determining whether they are consistent with the tree's structure.

[0018] A blockchain system includes a network of computing nodes that manage, update, and maintain one or more blockchains. The network can be a public blockchain network, a private blockchain network, or a consortium blockchain network. For example, many entities, such as hundreds, thousands, or even millions of entities, can operate in a public blockchain network, with each entity operating at least one node in the public blockchain network. Thus, a public blockchain network can be considered a public network with respect to participating entities. Sometimes, a majority of entities (nodes) must sign each block for it to be valid and added to the blockchain network. Exemplary public blockchain networks include specialized peer-to-peer payment networks that utilize a distributed ledger known as a blockchain.

[0019] Typically, a public blockchain network supports public transactions. Public transactions are shared by all nodes within the public blockchain network and stored in a global blockchain. The global blockchain is a blockchain that is replicated across all nodes, and all nodes are in full consensus with respect to the global blockchain. To achieve consensus (e.g., agreeing to add a block to the blockchain), a consensus protocol is implemented within the public blockchain network. Examples of consensus protocols include Proof of Work (PoW) (e.g., implemented in some cryptocurrency networks), Proof of Stake (PoS), and Proof of Authority (PoA).

[0020] Typically, a private blockchain network is provided to a specific entity, which centrally controls read and write permissions. This entity controls which nodes can participate in the blockchain network. For this reason, private blockchain networks are often referred to as permissioned networks, which restrict who is allowed to participate and the extent of their participation (e.g., only in certain transactions). Various types of access control mechanisms can be used (e.g., existing participants vote on the addition of new entities, and regulators can control admission).

[0021] Typically, a consortium blockchain network is private between participating entities. In a consortium blockchain network, the consensus process is controlled by a set of authorized nodes, one or more of which are operated by the respective entity (e.g., a financial institution, an insurance company). For example, a consortium consisting of ten (10) entities (e.g., financial institutions, insurance companies) can operate a consortium blockchain network, and each entity can operate at least one node in the consortium blockchain network. Therefore, a consortium blockchain network can be considered a private network with respect to the participating entities. In some examples, each entity (node) must sign each block in order for the block to be valid and added to the blockchain. In some examples, at least a subset of the entities (nodes) (e.g., at least 7 entities) must sign each block in order for the block to be valid and added to the blockchain.

[0022] Figure 1 FIG2 shows a schematic diagram of a blockchain system 100 according to an embodiment. Figure 1 , the blockchain system 100 may include a plurality of nodes, such as nodes 102-110, configured to operate on a blockchain 120. Nodes 102-110 may form a network 112, such as a peer-to-peer (P2P) network. Each of nodes 102-110 may be a computing device, such as a computer or computer system, configured to store a copy of the blockchain 120, or may be software, such as a process or application, running on a computing device. Each of nodes 102-110 may have a unique identifier.

[0023] The blockchain 120 may include, for example, Figure 1The data blocks B1-B5 in the block B1-B5 are recorded in a growing list.

[0024] 1. Each of the blocks B1-B5 can include a timestamp, a cryptographic hash of the previous block, and the current block’s data.

[0025] The data may be transactions such as currency transactions. Figure 1 As shown, block B5 may include a timestamp, a cryptographic hash value of block B4, and the transaction data of block B5. Furthermore, for example, a hash operation may be performed on the previous block to generate a cryptographic hash value of the previous block. The hash operation can convert inputs of varying lengths into encrypted outputs of fixed length using a hash algorithm such as SHA-256.

[0026] Nodes 102-110 can be configured to perform operations on blockchain 120. For example, when a node (e.g., node 102) wants to store new data on blockchain 120, the node can generate a new block to be added to blockchain 120 and broadcast the new block to other nodes in network 112, such as nodes 104-110. Based on the legitimacy of the new block, for example, the validity of its signature and transactions, the other nodes can determine to accept the new block, so that node 102 and the other nodes can add the new block to their respective copies of blockchain 120. As this process is repeated, more and more blocks of data can be added to blockchain 120.

[0027] Figure 2 FIG. 1 shows a block chain system for implementing a node (e.g., node 102 ( Figure 1 )) is a schematic diagram of a computing device 200. Figure 2 , computing device 200 may include a communication interface 202 , a processor 204 , and a memory 206 .

[0028] The communication interface 202 can facilitate communication between the computing device 200 and other nodes (eg, nodes 104-110) in the network. Figure 1 )) between devices. In some embodiments, the communication interface 202 is configured to support one or more communication standards, such as Internet standards or protocols, integrated services digital network (ISDN) standards, and the like. In some embodiments, the communication interface 202 may include one or more of the following: a local area network (LAN) card, a cable modem, a satellite modem, a data bus, a cable, a wireless communication channel, a radio-based communication channel, a cellular communication channel, an Internet Protocol (IP)-based communication device, or other communication devices 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, or a hybrid public / private cloud infrastructure.

[0029] Processor 204 may include one or more dedicated processing units, application specific integrated circuits (ASICs), field programmable gate arrays (FPGAs), or various other types of processors or processing units. Processor 204 is coupled to memory 206 and is configured to execute instructions stored in memory 206.

[0030] The memory 206 can store processor-executable instructions and data, such as the blockchain 120 ( Figure 1 ). Memory 206 may include any type of volatile or non-volatile memory device or combination thereof, 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 storage, flash memory, or a magnetic or optical disk. When instructions in memory 206 are executed by processor 204, computing device 200 may perform operations on blockchain 120.

[0031] Figure 3 FIG2 illustrates a flow chart of a method 300 for mitigating bill financing fraud according to an embodiment. Figure 3 , multiple users can use the blockchain (e.g., blockchain 120 ( Figure 1 )) have accounts. Blockchains can 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, etc.

[0032] To illustrate, Figure 3 The following depicts three users: a seller, a buyer, and a bank. Assume that the seller is interested in obtaining bill financing from a bank. The seller might attempt to obtain this financing by claiming to have outstanding invoices issued to the buyer. Sellers may issue bills for a variety of reasons, including, for example, past or future services rendered or products sold to the buyer. If the seller does have outstanding bills issued to the buyer, the bank might be willing to provide bill financing to the seller if the seller agrees to use the outstanding bills to obtain financing. However, the bank might want to ensure that the bills actually exist and have not already been used to obtain financing from other institutions. Therefore, before agreeing to provide bill financing to the seller, the bank might require the seller to prove the validity of the bills.

[0033] In some embodiments, the bank may be willing to accept the validity of the note if the seller and buyer can confirm the validity of the note based on method 300 described in detail below.

[0034] At step 302, the seller may generate a digital invoice. The digital invoice may be in a variety of formats, including, for example, a standardized format agreed upon by blockchain users. The digital invoice may contain data fields, including, for example, the seller's identity or identifier, the buyer's identity or identifier, a description of the product or service provided, the amount due, payment terms (or method of payment), etc.

[0035] The seller may also generate a commitment value recorded on the blockchain in step 302. In some embodiments, the seller may calculate the commitment value CM_INVOICE by considering at least a portion of the bill's information, the seller's information, and the seller's information. In some embodiments, CM_INVOICE may be calculated based on a one-way function. Those skilled in the art will appreciate that the function g:D→R is one-way. Given a random element x∈R, 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, making the function effectively impossible to invert. Therefore, the function is called "one-way." Hash functions, such as SHA256, are examples of one-way functions.

[0036] For example, in some embodiments, CM_INVOICE can be calculated as the hash value of (PK_SELLER, PK_BUYER, INVOICE_DIGEST, TN, R), where PK_SELLER and PK_BUYER represent the public keys of the seller and buyer, respectively, and INVOICE_DIGEST represents the hash value of the digital note, or the hash value of one or more parts of the digital note. TN can represent a token generated by the seller, which can be used to prevent the seller from obtaining financing multiple times using the digital note (i.e., preventing double financing). In some embodiments, TN can include a random number. However, it should be understood that TN can also include an alphanumeric value, and in some embodiments, TN can include a serial number. R can represent a random factor generated by the seller to further protect the information contained in PK_SELLER, PK_BUYER, and INVOICE_DIGEST. In some embodiments, R can be a random number or a random alphanumeric value.

[0037] In step 302, the seller can also generate a zero-knowledge proof, denoted as SELLER'S_PROOF. Zero-knowledge proof refers to a technique that allows a prover to prove to a verifier that a statement is true without revealing any information beyond the validity of the statement itself. In step 302, the seller is the prover, who can prove to the blockchain or a smart contract executed on the blockchain (acting as a verifier) ​​that the seller is the true issuer of the bill in question. The seller can attempt to prove this by indicating: (1) the CM_INVOICE format is correct, and (2) the seller is indeed the seller itself.

[0038] In an embodiment, to prove that the format of CM_INVOICE is correct, the seller can prove to the blockchain that the commitment value of (PK_SELLER, PK_BUYER, INVOICE_DIGEST, TN, R) is CM_INVOICE. In an embodiment, to prove that the seller is the seller, the seller can prove to the blockchain that the seller has the seller's private key, or prove to the blockchain that PK_SELLER = h(SK_SELLER), where SK_SELLER represents a private key known only to the seller, and h() is a hash function used to calculate the public key based on the private key.

[0039] In some embodiments, the seller and the blockchain may agree to implement zero-knowledge proof technology, such as zero-knowledge succinct non-interactive argument of knowledge (zk-SNARK). The seller can prove to the blockchain that the seller knows a private input w such that, for a public input x, a specific relationship between x and w holds. In some embodiments, this relationship can be defined as an arithmetic circuit. In some embodiments, the arithmetic circuit can be defined based on a polynomial equation that can be evaluated based on x and w. In some embodiments, based on the arithmetic circuit and one or more security parameters established for the zero-knowledge proof, a proof key and a verification key can be generated during a setup phase. Those skilled in the art will appreciate that the setup phase can be performed by a trusted party or by multiple independent parties collaborating using multi-party computation.

[0040] In some embodiments, the seller may set x to CM_INVOICE and w to a value generated based on PK_SELLER, PK_BUYER, INVOICE_DIGEST, TN, R, and SK_SELLER. For example, w can be generated by concatenating PK_SELLER, PK_BUYER, INVOICE_DIGEST, TN, R, and SK_SELLER. In this way, the seller can use the private input and public input along with the proof key to generate SELLER'S_PROOF to prove to the blockchain that the seller possesses the private input w. In some embodiments, the blockchain can verify SELLER'S_PROOF using the public input and the verification key generated during the setup phase. In some embodiments, if the blockchain accepts the seller's proof that the seller possesses the private input w, the blockchain can accept the seller's claim as true.

[0041] At step 304, the seller may submit a transaction to the blockchain, with the transaction payload containing {CM_INVOICE, SELLER'S_PROOF}. For illustration purposes, this transaction may be referred to as an "ISSUE_INVOICE" transaction.

[0042] In step 306, the blockchain may check SELLER'S_PROOF to determine whether the seller possesses the private input w. In some embodiments, the blockchain may utilize one or more smart contracts executed on the blockchain to implement this determination. A smart contract may be a computer protocol executed in the form of computer code that is incorporated into the blockchain to facilitate, verify, or enforce the negotiation or performance of a contract. For example, a blockchain user may program the agreed terms into a smart contract using a programming language such as C++, Java, Solidity, or Python, and when the terms are met, the smart contract may automatically execute on the blockchain, for example, executing a transaction. For another example, a smart contract may include multiple subroutines or functions, each of which may be a series of program instructions that performs a dedicated task. A smart contract may be an operational code that executes completely or partially without human interaction.

[0043] In some embodiments, a smart contract can be incorporated into the blockchain to determine whether the SELLER'S_PROOF is acceptable. The smart contract can use public inputs and a verification key to verify the SELLER'S_PROOF. If the SELLER'S_PROOF fails verification, the smart contract may refuse to allow the seller to proceed. On the other hand, if the SELLER'S_PROOF passes verification, the smart contract can determine that the SELLER'S_PROOF is acceptable and proceed to record the CM_INVOICE in the pool of invoices submitted by the seller. In some embodiments, the pool of invoices submitted by the seller can be constructed as a Merkle tree T_INVOICE, and the CM_INVOICE can be recorded at a leaf node of the Merkle tree T_INVOICE.

[0044] At step 308, the seller may proceed to request verification of the digital invoice generated by the seller. In some embodiments, the seller may privately send the digital invoice, along with the values ​​of TN and R, to the buyer via an off-chain communication channel. The seller may also send the buyer a CM_INVOICE. Alternatively or additionally, the buyer may reconstruct the CM_INVOICE based on the digital invoice and the values ​​of TN and R received from the seller.

[0045] In step 310, the buyer can check the digital invoice to determine whether it is valid. If, for example, the seller misreported the outstanding amount or forged the invoice, the buyer can invalidate the digital invoice. If the buyer determines that the CM_INVOICE is not recorded in the pool of invoices submitted by the seller, or that the recorded CM_INVOICE does not match the promised value of (PK_SELLER, PK_BUYER, INVOICE_DIGEST, TN, R), the buyer can also invalidate the digital invoice. In this way, if the seller attempts to bypass steps 304-306, or attempts to change the digital invoice or change the value of TN or the value of R, such attempts can be detected by the buyer, who can then invalidate the digital invoice and prevent fraud.

[0046] If the buyer determines that the digital note is valid, the buyer can proceed to generate a buyer-verified commitment value to be recorded on the blockchain. In some embodiments, the buyer can calculate the buyer-verified commitment value CM_BV_INVOICE as:

[0047] COMMITMENT(PK_SELLER, PK_BUYER, INVOICE_DIGEST, TN', R').

[0048] In some embodiments, CM_BV_INVOICE can be calculated based on the same one-way function used by the seller to calculate CM_INVOICE. Notably, while the values ​​of PK_SELLER, PK_BUYER, and INVOICE_DIGEST may be the same, the buyer may be responsible for generating new TN' and new R'. This allows the buyer to calculate a commitment value that differs from the seller's, effectively preventing unauthorized users from linking the two commitment values ​​together, and thus preventing unauthorized users from linking the seller and buyer together.

[0049] In step 310, the buyer can also generate a zero-knowledge proof, denoted as BUYER'S_PROOF. The buyer can generate BUYER'S_PROOF to prove to the blockchain that the buyer is the true recipient of the bill. The buyer can attempt to prove this by indicating: (1) the CM_INVOICE format is correct, (2) the CM_INVOICE is recorded in the bill pool submitted by the seller, (3) the CM_BV_INVOICE format is correct, and (4) the buyer is indeed the buyer.

[0050] In an embodiment, to prove that the format of CM_INVOICE is correct, the buyer can prove to the blockchain that the buyer knows the values ​​of PK_SELLER, PK_BUYER, INVOICE_DIGEST, TN, and R, and prove that the committed value of (PK_SELLER, PK_BUYER, INVOICE_DIGEST, TN, R) is CM_INVOICE. In an embodiment, to prove that CM_INVOICE is recorded in the pool of bills submitted by the seller, the buyer can prove to the blockchain that CM_INVOICE is a valid leaf node in the Merkle tree T_INVOICE. In an embodiment, to prove that the format of CM_BV_INVOICE is correct, the buyer can prove to the blockchain that the committed value of (PK_SELLER, PK_BUYER, INVOICE_DIGEST, TN', R') is CM_BV_INVOICE. In an embodiment, to prove that the buyer is indeed the buyer, the buyer can prove to the blockchain that the buyer possesses the buyer's private key, or prove that PK_BUYER = h(SK_BUYER), where SK_BUYER represents the private key, which is known only to the buyer.

[0051] In some embodiments, the buyer and the blockchain may agree to implement the aforementioned zero-knowledge proof techniques. For example, the buyer can prove to the blockchain that the buyer knows a secret input w such that, for a public input x, a specific relationship between x and w holds. In some embodiments, this relationship can be defined as an arithmetic circuit, which can be defined based on a polynomial equation that can be evaluated based on x and w. In some embodiments, a proof key and a verification key can be generated during the setup phase based on the arithmetic circuit and one or more security parameters established for the zero-knowledge proof. In some embodiments, the buyer can set x to a value containing TN and CM_BV_INVOICE, and set w to a value generated based on PK_SELLER, PK_BUYER, INVOICE_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 possesses the secret input w. In some embodiments, if the blockchain accepts the buyer's proof of possession of the secret input w, the blockchain can accept the buyer's claim as true.

[0052] In step 312, the buyer can send the values ​​of TN' and R' to the seller so that the seller can later obtain financing from the bank using the buyer's validated note. In step 314, the buyer can submit a transaction to the blockchain with a payload containing {TN, CM_BV_INVOICE, BUYER'S_PROOF}. For illustrative purposes, this transaction will be referred to as the "BUYER_VALIDATED_INVOICE" transaction.

[0053] In step 316, the blockchain can use a smart contract to check whether the TN contained in the payload has been used or consumed. In some embodiments, the smart contract can maintain a used token list on the blockchain to record used tokens. If the TN contained in the payload is listed in the used token list, the smart contract can refuse to proceed because the seller is attempting to obtain financing multiple times using the same digital instrument. On the other hand, if the TN contained in the payload is not listed in the used token list, the smart contract can proceed to verify whether the buyer's proof is acceptable. The smart contract can use the public input and verification key to verify the buyer's proof. If the buyer's proof passes verification, the smart contract can determine that the buyer's proof is acceptable and proceed to record the CM_BV_INVOICE in the buyer-verified instrument pool. In some embodiments, the buyer-verified instrument pool can be constructed as a Merkle tree T_BV_INVOICE, and the CM_BV_INVOICE can be recorded in a leaf node of the Merkle tree T_BV_INVOICE. The smart contract may also add the TN to the used token list to indicate that the TN has been used, thereby invalidating the TN for future use.

[0054] At step 318, the seller can proceed to request bill financing from the bank. In some embodiments, the seller can privately send the digital bill and the values ​​of TN' and R' to the bank via an off-chain communication channel. The seller can also calculate the value of CM_BV_INVOICE and send the CM_BV_INVOICE to the bank. Alternatively or additionally, the bank can reconstruct the CM_BV_INVOICE based on the digital bill and the values ​​of TN' and R' received from the seller.

[0055] At step 320, the bank can determine whether the digital bill is valid. For example, if the digital bill is not verified by the buyer, the bank can invalidate the digital bill. The bank can make this determination by determining whether CM_BV_INVOICE is recorded in the buyer-verified bill pool (e.g., in the Merkle tree T_BV_INVOICE). If CM_BV_INVOICE is not recorded in the buyer-verified bill pool, the bank can determine that the digital bill is invalid and refuse to allow the seller to proceed further. On the other hand, if CM_BV_INVOICE is recorded in the buyer-verified bill pool, the bank can determine that the digital bill is valid. The bank can then proceed to decide whether to provide bill financing to the seller.

[0056] In some embodiments, the bank can also determine whether the TN' provided by the seller has already been used. In some embodiments, the bank can call a smart contract executed on the blockchain to confirm whether TN' is listed in a list of used tokens. If TN' is listed in the list of used tokens, the bank can refuse to proceed because the seller is attempting to obtain financing using the same digital instrument multiple times. If TN' is not listed in the list of used tokens, the bank can proceed to determine whether to provide the seller with bill financing.

[0057] It should be understood that a bank may consider various factors when determining whether to provide bill financing to a seller. Such factors may include, for example, the size of the bill, the seller's credit score and credit history, the bank's prior dealings with the seller, and the like. Other factors may include, for example, the buyer's credit score and the bank's prior dealings with the buyer.

[0058] If the bank decides to reject the seller's bill financing request, the bank can privately communicate this decision to the seller through an off-chain communication channel. In this case, the seller can choose to repeat step 318 and request bill financing from a different funding provider. On the other hand, if the bank decides to provide bill financing to the seller, the bank can continue to generate a zero-knowledge proof in step 320, denoted as BANK'S_PROOF, to prove to the blockchain that the bank has verified the validity of the seller's request for bill financing. The bank can attempt to prove this by indicating that: (1) the CM_BV_INVOICE format is correct, and (2) the CM_BV_INVOICE is recorded in the bill pool verified by the buyer.

[0059] In an embodiment, to prove that the format of CM_BV_INVOICE is correct, the bank can prove to the blockchain that the bank knows the values ​​of PK_SELLER, PK_BUYER, INVOICE_DIGEST, TN', and R', and prove that the committed value of (PK_SELLER, PK_BUYER, INVOICE_DIGEST, TN', R') is CM_BV_INVOICE. In an embodiment, to prove that CM_BV_INVOICE is recorded in the buyer's verified bill pool, the bank can prove to the blockchain that CM_BV_INVOICE is a valid leaf node in the Merkle tree T_BV_INVOICE.

[0060] In some embodiments, the bank and the blockchain may agree to implement the aforementioned zero-knowledge proof technique. For example, the bank may prove to the blockchain that it knows a secret input w such that, for a public input x, a specific relationship between x and w holds. In some embodiments, this relationship may be defined as an arithmetic circuit, which may be defined based on a polynomial equation that can be evaluated based on x and w. In some embodiments, a proof key and a verification key may be generated during the setup phase based on the arithmetic circuit and one or more security parameters established for the zero-knowledge proof. In some embodiments, the bank may set x to TN' and w to a value generated based on PK_SELLER, PK_BUYER, INVOICE_DIGEST, R', and CM_BV_INVOICE. In this manner, the bank may generate BANK'S_PROOF to prove to the blockchain that it possesses the secret input w. In some embodiments, if the blockchain accepts the bank's proof of possession of the secret input w, the blockchain may accept the bank's claim as true.

[0061] At step 322, the bank may submit a transaction to the blockchain, with the transaction payload containing {TN', BANK'S_PROOF}. For illustration purposes, this transaction may be referred to as an "ISSUE_FINANCING" transaction.

[0062] At step 324, the blockchain can use a smart contract to check whether the TN' contained in the payload has been used. In some embodiments, the smart contract can check whether the TN' is listed in a list of used tokens. If the TN' is listed in the list of used tokens, the smart contract can refuse to proceed because the seller is attempting to obtain financing multiple times using the same digital instrument. If the TN' is not listed in the list of used tokens, the smart contract can proceed to verify whether the BANK'S_PROOF is acceptable. The smart contract can use the public input and verification key to verify the BANK'S_PROOF. If the BANK'S_PROOF can be verified, the smart contract can determine that the BANK'S_PROOF is acceptable and invalidate the TN' (e.g., by adding the TN' to the list of used tokens), and report to the bank at step 326 that no fraud was detected based on the received transaction so that the bank can continue to issue the instrument financing to the seller.

[0063] It should be understood that while the above example uses a used token list to record all used tokens, this embodiment is provided by way of example only and is not intended to be limiting. In some embodiments, one used token list can be used to record used tokens generated by the seller, and a different used token list can be used to record used tokens generated by the buyer. It should be understood that other types of data structures can also be used to record used tokens. Furthermore, it should be understood that the above declarations of functions, variables, and transactions are presented by way of example only and are not intended to be limiting.

[0064] Notably, by requiring users to confirm the validity of an instrument, method 300 can prevent double financing of invalid instruments. Method 300 can also mitigate fraudulent activity where sellers may create counterfeit instruments and attempt to use them to borrow money. Method 300 can further protect privacy by using commitment values ​​to conceal user identities, amounts due, payment terms, and other information related to the instrument. Method 300 can also ensure that transactions recorded on the blockchain cannot be linked to unrelated users, thereby preventing unrelated users from knowing the users associated with these transactions. Furthermore, in some embodiments, if a user wishes to further conceal the "ISSUE_INVOICE" transaction number, "BUYER_VALIDATED_INVOICE" transaction number, or "ISSUE_FINANCING" transaction number submitted to the blockchain, the user can choose to submit such transactions using a disposable anonymous blockchain identity.

[0065] Figure 4 A flowchart of a method 400 for mitigating bill financing fraud according to an embodiment is shown. The method 400 may be executed by one or more nodes in a blockchain system, for example, the blockchain system 100 ( Figure 1 ) in the blockchain system 100. The nodes 102-110 in the blockchain system 100 can perform operations on the blockchain, such as the blockchain 120 ( Figure 1 ). The blockchain 120 may be implemented as the blockchain in the above example.

[0066] At step 402, 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 ( Figure 3 ), the seller is the issuer of the note and is attempting to obtain financing using the note. The first transaction may include the above-mentioned "ISSUE_INVOICE" transaction ( Figure 3 ), which may include a first commitment value of the note, such as CM_INVOICE, and a first proof, such as SELLER'S_PROOF.

[0067] At step 404, node 102 may determine whether the first proof is acceptable and, in response to determining that the first proof is unacceptable, report that fraud has been detected. 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 authentic issuer of the bill. In some embodiments, the first user may attempt to prove to node 102 that the first commitment value of the bill is correctly formatted and that the first user is indeed the first user. In some embodiments, if the first user proves to node 102 that the first user possesses the aforementioned specific private information, node 102 may accept the first proof. In some embodiments, if node 102 determines that the first proof is unacceptable, node 102 may report that suspected fraud has been detected. On the other hand, if node 102 determines that the first proof is acceptable, then, at step 406, node 102 may record the first commitment value in a first bill pool, which in the above-described embodiments is referred to as the seller-submitted bill pool. In some embodiments, the first bill pool may include a first Merkle tree, such as T_INVOICE, and recording the first commitment value in the first bill pool may include recording the first commitment value in a leaf node of the first Merkle tree T_INVOICE.

[0068] At step 408, node 102 may receive a second transaction submitted by a second user. The second user may be, for example, a buyer ( Figure 3 ), the buyer is the recipient of the bill. The second transaction may include the above-mentioned "BUYER_VALIDATED_INVOICE" transaction ( Figure 3 ), which may include a first token generated by a first user, such as TN, a second commitment value of the bill, such as CM_BV_INVOICE, and a second proof, such as BUYER'S_PROOF.

[0069] In step 410, node 102 may determine whether the first token is valid and whether the second proof is acceptable. In response to determining that the first token is invalid or the second proof is unacceptable, node 102 may report that fraud has been 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 bill. In some embodiments, the second user may attempt to prove to node 102 that the first commitment value is correctly formatted and recorded in the first bill pool. The second user may also attempt to prove to node 102 that the second commitment value is correctly formatted and that the second user is indeed the second user itself. In some embodiments, if the second user can prove to node 102 that the second user possesses the above-mentioned specific private information, node 102 may accept the second proof.

[0070] In some embodiments, if node 102 determines that the first token is invalid or the second proof is unacceptable, node 102 may report that suspected fraud has been detected. On the other hand, if node 102 determines that the first token is valid and the second proof is acceptable, then in step 412, node 102 may record the second commitment value in a second bill pool, which is referred to as a buyer-verified bill pool in the above embodiments. In some embodiments, the second bill pool may include a second Merkle tree, such as T_BV_INVOICE, and recording the second commitment value in the second bill pool may include recording the second commitment value on a leaf node of the second Merkle tree T_BV_INVOICE. Node 102 may also invalidate the first token. In some embodiments, node 102 may invalidate the first token by adding the first token to a used token list.

[0071] At step 414, node 102 may receive a third transaction submitted by a third user. The third user may be, for example, a bank ( Figure 3 ), which is a funding provider that has received a request to provide bill financing to the first user. The third transaction may include the above-mentioned "ISSUE_FINANCING" transaction ( Figure 3 ), which may include a second token generated by a second user, such as TN', and a third proof generated by a third user, such as BANK'S_PROOF.

[0072] In step 416, node 102 may determine whether the second token is valid and whether the third proof is acceptable. In response to determining that the second token is invalid or the third proof is unacceptable, node 102 may report that fraud has been detected. In some embodiments, node 102 may determine whether the second token is valid by determining whether the second token is listed in a list of used tokens. In some embodiments, the third proof may be a zero-knowledge proof generated by a third user to prove that the third user has verified the validity of the request to provide bill financing to the first user. In some embodiments, the third user may attempt to prove to node 102 that the second commitment value of the bill is correctly formatted and recorded in the second bill pool. In some embodiments, if the third user proves to node 102 that the third user possesses the specific private information described above, node 102 may accept the third proof.

[0073] In some embodiments, if node 102 determines that the second token is invalid or the third proof is unacceptable, node 102 may report that suspected fraud has been detected. On the other hand, if node 102 determines that the second token is valid and the third proof is acceptable, node 102 may invalidate the second token and report to the third user in step 418 that no fraud has been detected based on the received transaction. In some embodiments, node 102 may invalidate the second token by adding it to a list of used tokens. The third user may continue to issue bill financing to the first user.

[0074] Figure 5 is a block diagram of a bill financing fraud mitigation apparatus 500 according to an embodiment. The apparatus 500 may be implemented as a software process and may correspond to the method 400 ( Figure 4 ). refer to Figure 5 , the apparatus 500 may include a receiving module 502 , a determining module 504 , a recording module 506 and a reporting module 508 .

[0075] The receiving module 502 may receive a first transaction submitted by a first user. The first transaction may include the above-mentioned "ISSUE_INVOICE" transaction ( Figure 3 ), which may include a first commitment value of a note generated by a first user (eg, CM_INVOICE) and a first proof generated by the first user (eg, SELLER'S_PROOF). The receiving module 502 may provide the received transaction to the determining module 504.

[0076] Determination module 504 may determine whether the first proof is acceptable. In response to determining that the first proof is unacceptable, determination module 504 may request reporting module 510 to report that fraud has been detected. Otherwise, determination module 504 may provide the first commitment value to recording module 508, which may record the first commitment value in the first ticket pool.

[0077] The receiving module 502 may receive a second transaction submitted by a second user. The second transaction may include the above-mentioned "BUYER_VALIDATED_INVOICE" transaction ( Figure 3 ), which may include a first token generated by the first user, such as TN, a second commitment value of the bill generated by the second user, such as CM_BV_INVOICE, and a second proof generated by the second user, such as BUYER'S_PROOF. The receiving module 502 may provide the received transaction to the determining module 504.

[0078] The determination module 504 can determine whether the first token is valid and whether the second proof is acceptable. In response to determining that the first token is invalid or the second proof is unacceptable, the determination module 504 can request the reporting module 510 to report that fraud has been detected. Otherwise, the determination module 504 can provide the second commitment value to the recording module 508, which can record the second commitment value in the second ticket pool and record the first token as used, thereby invalidating the first token.

[0079] The receiving module 502 may receive a third transaction submitted by a third user. The third transaction may include the above-mentioned "ISSUE_FINANCING" transaction ( Figure 3 ), which may include a second token generated by a second user, such as TN′, and a third proof generated by a third user, such as BANK'S_PROOF. The receiving module 502 may provide the received transaction to the determining module 504.

[0080] Determination module 504 can determine whether the second token is valid and whether the third proof is acceptable. In response to determining that the second token is invalid or the third proof is unacceptable, determination module 504 can request reporting module 510 to report that fraud has been detected. Otherwise, determination module 504 can request recording module 508 to record the second token as used, thereby invalidating the second token. Determination module 504 can also request reporting module 510 to report to the third user based on the received transaction that no fraud has been detected, so that the third user can continue to issue bill financing to the first user.

[0081] Each of the above modules can be implemented as software, or hardware, or a combination of software and hardware. For example, each of the above modules can be implemented using a processor, and the memory executes the instructions stored in the memory. Moreover, for example, each of the above modules can 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, microcontrollers, microprocessors or other electronic components to perform the described method. Further, for example, each of the above modules can be implemented by using a computer chip or entity, or by using a product with a specific function. In an embodiment, device 500 can be a computer, and the computer can be a personal computer, a laptop computer, a cellular phone, a camera phone, a smart phone, a personal digital assistant, a media player, a navigation device, an email transceiver, a game console, a tablet computer, a wearable device or any combination of these devices.

[0082] For the implementation process of the functions and roles of each module in the apparatus 500, reference may be made to the corresponding steps in the above method. For the sake of simplicity, the details are omitted here.

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

[0084] A computer-readable storage medium may be a tangible device that can 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 computer-readable storage media 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 encoding device (e.g., a punched card in a groove or a raised structure with instructions recorded thereon), and any suitable combination of the foregoing.

[0085] The computer-readable program instructions for performing the above method can be assembly instructions, instruction set architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, state setting data, or source code or object code written in any combination of one or more programming languages, including object-oriented programming languages ​​and traditional procedural programming languages. The computer-readable program instructions can be executed entirely on a computing device as a standalone software package, or partially executed on a first computing device and partially executed on a second computing device away from the first computing device. In the latter case, the second remote computing device can be connected to the first computing device through any type of network including a local area network (LAN) or a wide area network (WAN).

[0086] 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, executed via the processor of the computer or other programmable data processing apparatus, create means for implementing the above-described methods.

[0087] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functions and operations that may be implemented according to the devices, methods and computer program products of various embodiments of the present invention. In this regard, the boxes in the flowchart or block diagram can represent segments or portions of software programs, codes, which include one or more executable instructions for implementing a specific function. It should also be noted that in some optional embodiments, the functions mentioned in the boxes may not occur in the order shown in the figures. For example, two boxes shown in succession can actually be executed substantially simultaneously, or the boxes can sometimes be executed in the opposite order, depending on the functions involved. It should also be noted that each box in the diagram and / or flowchart and the combination of boxes in the diagram and flowchart can be implemented by a hardware-based system for a special purpose that performs a specified function or action, or by a combination of hardware and computer instructions for a special purpose.

[0088] It should be understood that certain features of the disclosure described in the context of different embodiments for the sake of clarity may also be provided in combination in a single embodiment. Conversely, various features of the disclosure described in the context of a single embodiment for the sake of brevity may also be provided individually or in any suitable subcombination, or as appropriate in any other described embodiment of the disclosure. Unless otherwise stated, certain features described in the context of various embodiments are not essential features of those embodiments.

[0089] Although the present disclosure has been described in conjunction with specific embodiments, many alternatives, modifications and variations will be apparent to those skilled in the art. It is therefore intended that the following claims encompass all such alternatives, modifications and variations that fall within the scope of the claims.

Claims

1. A computer-implemented method for mitigating bill financing fraud, comprising: receiving a first transaction from a first user, the first transaction including a first commitment value of a bill and a first certificate proving that the first user is the issuer of the bill, the first commitment value being generated based on a first token corresponding to 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 of the bill, and a second proof proving that the second user is a recipient of the bill, 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 and a third certificate 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 bill financing fraud.

2. The method according to claim 1, wherein The method is executed by one or more nodes in the blockchain system.

3. The method according to claim 1 or 2, further comprising one of the following: In response to determining that the first certification is unacceptable, reporting that fraud has been detected; responsive to determining that the first token is invalid or the second proof is unacceptable, reporting detection of the fraud; or Responsive to determining that the second token is invalid or the third proof is unacceptable, reporting detection of the fraud.

4. The method according to claim 1 or 2, further comprising: In response to determining that the first proof is acceptable, recording the first commitment value of the bill in a first bill pool; In response to determining that the first token is valid and the second proof is acceptable, recording the second commitment value of the ticket in a second pool of tickets and invalidating the first token.

5. The method according to claim 1 or 2, further comprising: In response to determining that the second token is valid and the third proof is acceptable, the second token is invalidated and no fraud is reported.

6. The method according to claim 1 or 2, wherein: The first proof, the second proof, and the third proof are zero-knowledge proofs.

7. The method according to claim 1 or 2, wherein: The first user is the issuer of the bill, and the first certificate is a certificate generated by the first user to prove that the first user is the issuer of the bill.

8. The method according to claim 1 or 2, wherein: The second user is the recipient of the ticket, and the second proof is a proof generated by the second user to prove that the second user is the recipient of the ticket.

9. The method according to claim 1 or 2, wherein: The third user is a fund provider that has received a request to provide bill financing to the first user, and the third certificate is a certificate generated by the third user to prove that the third user has verified the validity of the request to provide bill financing to the first user.

10. The method according to claim 1 or 2, wherein: The first commitment value is generated by the first user using a first random value, and the second commitment value is generated by the second user using a second random value, so as to disassociate the first commitment value from the second commitment value.

11. The method according to claim 1 or 2, wherein: The first commitment value and the second commitment value are generated based on information of at least a portion of the ticket, information of the first user, information of the second user, and a one-way function.

12. The method according to claim 1 or 2, wherein: Whether the first token or the second token is valid is determined based on whether the first token or the second token is listed in a used token list.

13. A device 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, wherein the instructions are executable by the one or more processors to perform the method of any one of claims 1 to 12.

14. An apparatus for mitigating bill financing fraud, the apparatus comprising a plurality of modules for executing the method of any one of claims 1 to 12, the plurality of modules comprising: a receiving module configured to receive a first transaction from a first user, a second transaction from a second user, and a third transaction from a third user, wherein the first transaction includes a first commitment value of a bill and a first certificate proving that the first user is the issuer of the bill, the first commitment value being generated based on a first token corresponding to the first user; the second transaction includes the first token corresponding to the first user, a second commitment value of the bill, and a second certificate proving that the second user is the recipient of the bill, the second commitment value being generated based on a second token corresponding to the second user; and the third transaction includes the second token corresponding to the second user and a third certificate generated by the third user; A determination module is configured to verify the first certificate; determine that the first token is valid and verify the second certificate; and determine that the second token is valid and verify the third certificate to determine that there is no bill financing fraud. 15 . A non-transitory computer-readable medium having instructions stored therein, which, when executed by a processor of a device, cause the device to perform the method of claim 1 .

Images